feat: add Lighthouse CI workflow

[apermo]

Summary

• Add reusable-lhci.yml workflow with configurable score thresholds for accessibility, performance, SEO, and best practices
• Support for wp-env setup, custom config files, and multi-URL audits
• Document the new workflow in README.md, CLAUDE.md, and CHANGELOG.md

Test plan

• Verify workflow YAML is valid and all inputs have correct types/defaults
• Test with setup-wp-env: true in a consuming repo to confirm wp-env starts correctly
• Test with custom config-path to verify config override works
• Test threshold assertions: set a11y-threshold: 100 and confirm failure on a non-perfect page
• Verify Lighthouse report artifact is uploaded on both success and failure

Closes #17

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a new reusable GitHub Actions workflow designed to automate Lighthouse CI audits. This workflow enables developers to easily integrate web performance, accessibility, SEO, and best practices checks into their CI/CD pipelines, ensuring high-quality web applications by providing configurable thresholds and support for WordPress development environments.

Highlights

• New Lighthouse CI Workflow: Introduced reusable-lhci.yml for automated web performance, accessibility, SEO, and best practices audits.
• Configurable Audits: The workflow supports configurable score thresholds for various audit categories, wp-env integration, custom Lighthouse configuration files, and auditing multiple URLs.
• Documentation: The new workflow is thoroughly documented in README.md, CLAUDE.md, and CHANGELOG.md.

Ignored Files

• Ignored by pattern: .github/workflows/** (1)
  • .github/workflows/reusable-lhci.yml

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

---

Lighthouse scans the web, Scores reveal what needs to shine, Code now stands so bright.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[apermo]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a new reusable Lighthouse CI workflow (reusable-lhci.yml) for auditing accessibility, performance, SEO, and best practices. The changes include documentation in the README, an entry in the CHANGELOG, and a reference in CLAUDE.md. One piece of feedback was provided regarding the documentation: the example usage should pin the workflow to a version tag (e.g., @v0.4) rather than the main branch to ensure stability and follow the repository's versioning principles.

[gemini-code-assist]

The example usage for the new reusable-lhci.yml workflow pins it to the main branch. While this is consistent with other examples in this file, it's a volatile practice that can introduce breaking changes for consumers of this workflow.

According to the repository style guide, action versions should be pinned to a major version. This principle should also apply to reusable workflows to ensure stability for consumers.

Consider updating the example to use a version tag, for instance @v0.4, which would align with the new version being introduced in CHANGELOG.md.

Suggested change

	lighthouse:
	uses: apermo/reusable-workflows/.github/workflows/reusable-lhci.yml@v0.4

References

1. Action versions must be pinned to a major version (e.g., @v4). While this rule refers to actions, the principle of version pinning for stability is also a best practice for reusable workflows. ^(link)

[gemini-code-assist]

Code Review

This pull request introduces a new reusable Lighthouse CI workflow, reusable-lhci.yml, and updates the project documentation in CHANGELOG.md, CLAUDE.md, and README.md. The review feedback suggests clarifying the documentation for the urls input default value to match its JSON string type and refining the description of config-path to explicitly state that it overrides threshold inputs.

[gemini-code-assist]

The documentation for the urls input's default value could be misleading. The type is specified as string (JSON), but the default value ["http://localhost:8888"] is rendered as a YAML array. To improve clarity and align with the type definition, I recommend representing the default value as a JSON string within single quotes.

Suggested change

	| `urls` | string (JSON) | `["http://localhost:8888"]` | URLs to audit |
	| `urls` | string (JSON) | `'["http://localhost:8888"]'` | URLs to audit |

[gemini-code-assist]

The description for config-path states it "overrides thresholds," which is slightly ambiguous. To make it clearer for users, I suggest explicitly mentioning that it overrides the threshold inputs of this workflow.

Suggested change

	| `config-path` | string | `""` | Path to `.lighthouserc.js` (overrides thresholds) |
	| `config-path` | string | `""` | Path to `.lighthouserc.js` (overrides threshold inputs) |