Speed up the per-PR Lighthouse audit - #20728
Conversation
The Lighthouse audit is advisory and gates nothing, but it ran at the tail of ci-pull-request.sh, so its 3-5 minutes were fully additive to the latency of buildSite -- the check people actually wait on. Extract it into its own `lighthouse` job in pull-request.yml. The job consumes the origin-bucket-metadata artifact buildSite already publishes, keeps the path filter as the identical bash regex list (no glob translation to drift), and installs only Lighthouse at the version yarn.lock resolves rather than running `make ensure`. It carries continue-on-error so a failure can't turn the run red, preserving the behavior of the `|| true` that wrapped the audit before. Also trim the audit itself. scripts/lighthouse/run-audits.mjs runs all six page/device combinations against a single shared Chrome instead of booting a cold one per audit via npx, and skips the three screenshot audits -- the report only reads the score plus FCP/LCP/TBT/CLS/SI, so the screenshots were captured, encoded, and thrown away. Measured against production: 98.7s -> 72.5s. The page list moves to scripts/lighthouse/pages.json so the runner and the renderer can't drift. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Pushing this branch triggers nothing else (both push-triggered workflows are master-only), so this exercises the new job's plumbing -- ESC secrets in a standalone job, the artifact hand-off, the path filter against three merged PRs with known file lists, the yarn.lock version extraction, and Chrome on ubuntu-latest -- without opening a PR or posting a bot comment. Delete before marking the real PR ready. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
It served its purpose: ESC secrets resolve in a standalone job with environment: testing, the buildSite -> lighthouse artifact hand-off works, the path filter matched all three merged-PR fixtures, and six audits ran in 99s on ubuntu-latest against a 36s Lighthouse install. What it couldn't reach -- the real preview URL and the comment post/update path -- needs a pull_request payload, which this PR provides. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The rest of this PR only touches .github/ and scripts/, none of which match the audit's path filter -- so without this the new job would correctly skip and prove nothing. Revert this commit before marking the PR ready. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Your site preview for commit 43530e0 is ready! 🎉 http://www-testing-pulumi-docs-origin-pr-20728-43530e0b.s3-website.us-west-2.amazonaws.com |
Lighthouse Performance ReportCommit: 51fdfb2 | Metric definitions
|
This reverts commit c3cd6b0.
Pre-merge Review — Last updated 2026-08-06T14:10:17ZTip Summary: This is an infrastructure PR. An earlier commit on this branch split the advisory Lighthouse audit into its own Review confidence:
Investigation log
🔍 Verification trail2 claims extracted · 2 verified · 0 unverifiable · 0 contradicted
🚨 Outstanding in this PRNo outstanding findings in this PR.
|
`npm install <pkg>` reifies the whole tree from whatever package.json it finds, so `npm install lighthouse@X` in the checkout root installed all 913 root dependencies rather than just Lighthouse. Running the install under an --prefix outside the checkout drops it to the 200 packages Lighthouse actually needs; symlinking the result back to ./node_modules keeps Node's resolution working for scripts/lighthouse/run-audits.mjs. Measured on ubuntu-latest, the install step goes from 39s (913 packages) to 9s (200), taking the lighthouse job from 3m00s to 2m25s. The audits are untouched: 97s before, 95s after. Also declare chrome-launcher, which run-audits.mjs imports directly but which was resolving only as a hoisted transitive dependency of lighthouse. The range matches the descriptor already keyed in yarn.lock, so the lockfile is unchanged and --frozen-lockfile still passes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
3af28aa to
5373fd8
Compare
`skipAudits: ["full-page-screenshot"]` was a no-op: that's the gatherer id for the FullPageScreenshot artifact, not an audit id, and Lighthouse drops unknown skipAudits entries silently. The artifact is also in filterResistantArtifactIds, so it runs even when no surviving audit requires it -- `disableFullPageScreenshot` is the only lever that turns it off. That's the expensive capture; screenshot-thumbnails and final-screenshot are computed from trace data and cost almost nothing. So the screenshot skip was contributing ~0 to the measured speedup, which came entirely from sharing one Chrome instance across the six audits. Verified against lighthouse 12.8.2 by resolving both configs through initializeConfig: the FullPageScreenshot artifact is present before and absent after, in both mobile and desktop, with the performance category and the desktop form factor intact. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Re-applied to re-measure the audit runtime now that the full-page screenshot is actually being skipped. Revert this commit before marking the PR ready. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This reverts commit 51fdfb2.
…pr-lighthouse # Conflicts: # package.json
The audit goes back to running inline at the tail of ci-pull-request.sh, exactly where it was. .github/workflows/pull-request.yml and ci-pull-request.sh are now byte-identical to master. Measuring the split honestly made it hard to justify. The path filter trips on only 13 of the last 120 merged PRs (~11%), and the speedups in run-audits.mjs already take the audit from 135s to 82s -- so moving it to its own job was worth a further 82s on roughly 1 in 9 PRs. Carrying that were an artifact hand-off, a duplicate ESC fetch, and an isolated npm install that had to scrape the Lighthouse version out of yarn.lock and symlink node_modules back into the checkout. That install was the most fragile thing in the diff, and its only failure mode was quiet: a green advisory job with a table full of Error rows. What remains is the part that carried most of the win and none of the risk. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
@claude #update-review |
|
🤖 Review updated on @jeffmerrick's request. |
CamSoper
left a comment
There was a problem hiding this comment.
Looks great, looking forward to this
Trying to speed up the build a bit!
Changes
One Chrome instead of six.
scripts/run-lighthouse-pr.shshelled out tonpx lighthouseonce per page/device combination, paying a cold Chrome boot each time.scripts/lighthouse/run-audits.mjsdrives the Node API instead and runs all six against a single launched browser. Lighthouse still callsnewPage()per run, closes it after, and clears storage, so the audits stay independent.No screenshots. The report only reads the performance score plus FCP/LCP/TBT/CLS/SI, so every captured screenshot was encoded and thrown away. The expensive one is the full-page screenshot, and it can't be dropped via
skipAudits—full-page-screenshotis a gatherer id, not an audit id, andFullPageScreenshotis in Lighthouse'sfilterResistantArtifactIds, so it runs regardless of which audits survive filtering.disableFullPageScreenshotis the only lever. The two real screenshot audits are skipped alongside it.One page list. The audited pages move to
scripts/lighthouse/pages.json, read by both the runner and the renderer, so the two can't drift.chrome-launcherbecomes a direct devDependency sincerun-audits.mjsimports it; it was already present as a Lighthouse transitive dep, andyarn.lockneeded no change.Numbers
Measured on
ubuntu-latestagainst real preview buckets, bounded by the audit's own log markers so old and new are measured identically.buildSite's critical path.Single runs, not medians — see Follow-up.
Verified
The audit ran green on this PR with all six rows scoring normally and none falling back to an
Errorrow, using a throwawaytheme/touch to trip the path filter (reverted; the diff above is unaffected). ThedisableFullPageScreenshotbehavior was confirmed directly against Lighthouse 12.8.2 by resolving both the mobile and desktop configs throughinitializeConfig: theFullPageScreenshotartifact is present before the change and absent after, with the performance category and desktop form factor intact.Considered and dropped: a separate
lighthousejobMoving the audit to its own job made nothing faster in absolute terms: the fresh job re-paid ~55s of setup it had been inheriting from
buildSite, so total runner time went up and only the gating check's report time improved. At an 11% trigger rate (13 of the last 120 merged PRs), that bought 82s on 1 in 9 PRs in exchange for an artifact hand-off, a duplicate ESC fetch, and an npm install that scrapedyarn.lockand symlinkednode_modules. Cleanly additive later if it's ever worth it.Follow-up
Median-of-3 is what would make these numbers trustworthy — the same page scored 89, 51, 45 and 34 across runs here. It's ~12 lines in
run-audits.mjs, but it triples the audit load, so it belongs in its own PR.🤖 Generated with Claude Code