Add Lighthouse CI to PR build workflow to produce performance reports#2813
Open
holly-cummins wants to merge 4 commits into
Open
Add Lighthouse CI to PR build workflow to produce performance reports#2813holly-cummins wants to merge 4 commits into
holly-cummins wants to merge 4 commits into
Conversation
This comment has been minimized.
This comment has been minimized.
|
🎊 PR Preview 35958d8 has been successfully built and deployed to https://quarkus-website-pr-2813-preview.surge.sh
|
This comment has been minimized.
This comment has been minimized.
Runs Lighthouse against the test server after smoke tests, scoring performance, accessibility, best practices, and SEO for key pages. Results appear as a color-coded table in the GitHub step summary and are uploaded as build artifacts. Uses npm ci with a lockfile to pin @lhci/cli dependencies. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> # Conflicts: # .github/workflows/build.yml
Keeps @lhci/cli and any future npm dependencies up to date. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Reuses the link_scope step outputs: skips when no HTML changed, tests only changed pages (capped at 5) for partial PRs, and falls back to key pages (/, /guides/, /blog/) for full checks. URLs are now passed via CLI args instead of hardcoded in lighthouserc.js. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Reads report URLs from .lighthouseci/links.json (written by the temporary-public-storage upload) and adds them to the step summary table. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
cd2c90e to
b8df7f8
Compare
Status for workflow
|
insectengine
left a comment
Collaborator
There was a problem hiding this comment.
I can't speak the technical code but I agree with the concept. ;)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

This is something I think we ought to have, independent of migration.
As far as I can tell, Lighthouse, from Google Chrome, is still the industry standard for performance and best practices tests for sites. This PR runs Lighthouse against the test server after smoke tests, scoring performance, accessibility, best practices, and SEO for key pages. Results appear as a color-coded table in the GitHub step summary and are uploaded as build artifacts.
If we go below a certain threshold it will warn. For some categories like accessibility, it will fail the build, but otherwise, people need to check the reports to see the warnings. If the reports are useful we should maybe add them to the bot comments on the PR, but maybe we should wait to see if we like them first.
As with the e2e testing, it will run everything for infra changes, and otherwise it will just run changed pages. This does create a risk that a change a to a bad page would have bad scores and error because there aren't other pages to drag average scores up. We may need to wait and see how that plays out.
I was uneasy about supply chain issues, but lhci is owned by Chrome, and this uses npm ci with a lockfile to pin @lhci/cli dependencies. So it should be ok.
Here's the report we get at the moment:

... and the full details live at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1782923375367-10880.report.html. Looking through the report, there's clearly some perf work we should be doing.
cc @insectengine