Coder Legion - Recent posts tagged lighthouse

When should you lazy load images (and when does it hurt LCP)?

Thu, 15 Oct 2026 07:36:37 +0000

A short rule list for loading="lazy": below the fold yes, LCP hero no, and retest after every theme or plugin change that touches images.

A theme update or optimisation plugin turns on lazy loading for every image. Bandwidth on long articles looks better in the waterfall, yet PageSpeed Insights still names a deferred hero as Largest Contentful Paint, or lab LCP gets worse than last month. That outcome is common when loading="lazy" is treated as a global performance switch instead of a per-image choice.

The full decision guide, including iframes, video, and lab-versus-field checks, lives on our blog in Lazy Loading for LCP and CLS: When to Use loading="lazy" (and When Not To). Formats, sizing, and CDN work sit beside that in Image Optimisation Strategies for Better LCP Scores. What follows is the short checklist we use in reviews: when lazy loading images helps, when it hurts LCP, and which CMS habits to watch.

Three checks before you lazy-load an image

These three questions usually decide whether loading="lazy" belongs on an <img>:

Is it in the first viewport on phone and desktop? If yes for either primary breakpoint, leave it eager.
Could PageSpeed Insights or Chrome name it as LCP? If it is the hero, primary product shot, or large above-the-fold banner, omit lazy, or set loading="eager" when a plugin injects lazy by default.
Does the markup reserve space? Width and height attributes or an aspect-ratio rule should be present before you defer the fetch, so Cumulative Layout Shift does not replace the LCP problem.

If the template or page builder does not make those answers obvious, identify the first-screen image before you change attributes. A plugin toggle is not a substitute for knowing which image paints first. Note the exclusions in the work item so the next theme update has a clear list.

When lazy loading images helps bandwidth without hurting LCP

Lazy loading images is usually right for content that starts offscreen: article body photos after the fold, related-product grids, footer logos, long category galleries, and comment avatars. Those bytes should not compete with the critical path on first paint. On a long post with many images, native lazy loading can cut early mobile bandwidth sharply without changing what the user sees first.

Eager versus lazy works better as a short policy per template than as a single sitewide switch. Eager fits the LCP candidate and other first-screen images on common breakpoints. Lazy fits everything that needs scroll or a tab change before it matters. Check phone width as well as desktop: an image that looks “below the fold” on a large monitor can sit in the first screen on a phone, and that traffic often dominates field data.

When `loading="lazy"` hurts Largest Contentful Paint

LCP marks when the largest above-the-fold content element becomes visible. If that element is an image marked loading="lazy", the browser may delay the request even though the image is already on screen. Lab tools show that as higher resource load delay and a worse LCP. Google’s guidance and support threads still treat “do not lazy-load the LCP image” as a first triage step, not a rare edge case.

The fix is usually small. Remove loading="lazy" from the named LCP image (and matching sources in <picture>). fetchpriority="high" fits when the LCP URL is known early and other resources are not already marked high. Preloading and lazy-loading the same URL fights itself. A reasonably sized eager hero usually beats a huge lazy hero on LCP, even when a plugin dashboard calls the waterfall optimised.

CMS and theme traps that lazy-load the hero

WordPress themes, page builders, and Shopify settings often inject loading="lazy" on every attachment. Logos, banners, and first product images get deferred with the gallery. Elementor and similar stacks show up often in “lazy load LCP” threads for that reason. A CDN or image plugin that rewrites markup can put lazy back after the theme was fixed once.

When scores drop after a “performance” plugin install, open the LCP element detail before you change hosting plans. Exclude the first-screen image from auto-lazy rules, or override with eager on that node. Record the exclusion in the monthly notes so the next theme update does not silently put lazy back on the hero.

Quick verify: lab LCP element after a lazy-loading change

After any change that touches image markup or lazy defaults, re-run PageSpeed Insights or your scheduled lab profile on the homepage and other priority pages. Check which element is LCP, whether that element is still lazy-loaded, and whether deferred below-the-fold images reserve space with width/height or aspect-ratio. One green Lighthouse run on a staging URL is not enough if production themes differ by template.

Comparing the same lab profile before and after the change, kept in monitoring history, is how agencies catch a theme update that re-applies sitewide lazy loading three weeks later, when nobody remembers the original ticket. Scheduled runs on the homepage and other priority pages are more reliable than another one-off Insights paste after each deploy. That habit turns a one-time attribute fix into something the next quarterly review can still prove.

FAQ

Should every image use loading="lazy"?
No. Offscreen images are the usual fit. Keep the LCP candidate and other first-viewport images eager. Sitewide lazy loading is a common cause of worse lab LCP.

Does lazy loading fix Cumulative Layout Shift?
Not by itself. Reserve space with width and height or aspect-ratio CSS. Lazy loading without reserved space can make CLS worse when images appear late and push the layout.

Is the HTML loading attribute enough, or do we still need a JavaScript library?
For ordinary images, native lazy loading is usually enough in modern browsers. Older themes still ship JavaScript lazy libraries; check whether those libraries also defer the hero. Knowing which mechanism is in use belongs in the work item before anyone blames hosting.

How do we know which image is LCP?
Use the LCP element detail in PageSpeed Insights or Lighthouse on phone and desktop widths. Do not guess from the design mockup alone.

CTA

If lazy loading is already “on” everywhere, treat the toggle as incomplete until the LCP image is named. Below-the-fold images usually stay lazy; the hero stays eager; space is reserved; theme and plugin changes get a retest. For the longer guide with iframes, video, and lab-versus-field detail, use the Watcher lazy-loading post linked above. For formats and sizing that keep eager heroes small enough to ship, use the image optimisation piece. When you need scheduled lab history across many client pages so a theme update cannot silently defer the hero again, run continuous PageSpeed checks in Apogee Watcher.

References

Lazy Loading for LCP and CLS: When to Use loading="lazy" (and When Not To) (Apogee Watcher)
Image Optimisation Strategies for Better LCP Scores (Apogee Watcher)
Browser-level image lazy loading for the web (web.dev)
Lazy loading (MDN Web Docs)
Common misconceptions about Largest Contentful Paint (web.dev)

Originally published on Hashnode.

Brotli compression is on: why is PageSpeed / LCP still slow?

Tue, 13 Oct 2026 08:49:35 +0000

A green compression toggle is not an LCP fix. Confirm Content-Encoding on the critical path, then check the LCP element and Time to First Byte that still dominate the lab run.

The CDN panel shows Brotli enabled and the host checklist ticks compression, yet PageSpeed Insights on the homepage or checkout URL still shows a slow Largest Contentful Paint, or the Performance score barely moves after the change. Those two facts can both be true. Brotli compression shrinks text on the wire; it does not change the LCP element, a slow origin response, or a lab path that never negotiated br on the files that matter.

How to turn compression on without breaking scores is already covered on our blog in Brotli and Gzip Compression: Shrink Text Assets Without Breaking PageSpeed Scores. Caching and reuse sit beside that work in Cache-Control Headers for Web Performance. What follows here is the triage we run when the toggle is already green and the lab result is still poor: confirm encoding on the critical path, then address the bottlenecks compression was never going to fix.

Confirm Brotli is actually on the critical path

A dashboard labelled “Brotli” often means the edge can compress. Lighthouse and PageSpeed Insights care whether the HTML document and the render-blocking CSS and JavaScript on that URL arrived with Content-Encoding: br or gzip. Those are different claims. Open the Network panel (or curl -sI with Accept-Encoding: br, gzip) on the document URL and on each large text resource in the critical path. Look for content-encoding and for transfer size versus content size. If the document is compressed but the main stylesheet is not, the Enable text compression audit can still fail, and paint can still wait on uncompressed bytes.

Partial coverage is the usual miss after a “we enabled Brotli” ticket. Origin middleware compresses HTML; the CDN serves fingerprinted CSS from a bucket that never negotiated Brotli; fonts and JSON follow yet another path. Agencies also see the reverse: the lab client hits a cache or region where encoding differs from the URL the engineer tested by hand. Until you can name the encoding on the document and the two or three largest text blockers, treat the toggle as incomplete evidence.

Why Brotli can leave Largest Contentful Paint unchanged

LCP measures when the largest visible element finishes rendering, not when every text file is as small as possible. Compression helps when download time for HTML, CSS, or critical JavaScript was a meaningful slice of that path. It does nothing useful for an LCP image that is still a multi-megabyte JPEG, lazy-loaded by mistake, or discovered late after client-side rendering. Decode and layout work on the main thread also sit outside what compression can fix: a smaller JavaScript transfer still costs the same parse and execute time once the bytes arrive.

In our experience, teams over-credit the compression ticket because it is easy to mark done. The lab waterfall still shows a late LCP resource, a long Time to First Byte, or render-blocking scripts that compression only shortened by tens of milliseconds. When transfer size was never the bottleneck, expecting a Core Web Vitals step-change from Brotli alone is the wrong bet. Use the LCP element detail in PageSpeed Insights or Lighthouse: if the element is an image or a late text block waiting on fonts and scripts, compression is support work, not the fix.

When enabling Brotli makes PageSpeed Insights worse

Compression can raise Time to First Byte (TTFB) when the origin or edge encodes HTML on every request at a high Brotli quality level. Smaller bodies help only after the first byte is available. If CPU queues behind dynamic compression, every paint metric starts later even though transfer size looks healthier in the waterfall. That pattern shows up after someone raised Brotli quality to the maximum on dynamic pages without precompressing static assets or without a moderate quality setting for HTML.

Other regressions are quieter. Double compression (a gzip wrapper around an already-Brotli body, or filters stacked at origin and edge) burns CPU without shrinking useful bytes. Compressing JPEG, PNG, WebP, AVIF, or MP4 as if they were text adds work for almost no gain. Missing or wrong Vary: Accept-Encoding on shared caches can mix encodings across clients and produce flaky lab runs that look like random PageSpeed noise. When the score drops after the toggle, compare Time to First Byte and the server-response audit before chasing image formats again.

What to fix next when the LCP element is not a text file

Once Content-Encoding looks correct on the critical path, return to ordinary LCP triage. Identify the LCP element. If it is an image, check discovery (preload or early HTML), format and dimensions, and whether loading="lazy" was applied to the hero by mistake. If Time to First Byte is high, compression will not hide a cold origin, an uncached HTML document, or a slow application query. If render-blocking CSS and JavaScript dominate, shrinking them with Brotli helps a little; removing or deferring work that is not needed for first paint usually helps more.

Keep compression and caching as paired delivery checks rather than as a substitute for element-level work. Cache-Control decides whether repeat views reuse bytes; Brotli and gzip decide how small the first download of text is. Neither replaces a late LCP image or a client-only render of the hero. For agencies, a clear client update is: compression is done and verified; the remaining LCP risk is named (image, Time to First Byte, or blocking scripts) with an owner and a retest plan.

How agencies verify compression and LCP across a client portfolio

One curl on staging is not enough evidence across a client portfolio. After deploys that touch CDN, origin, or build output, re-check Content-Encoding on each client’s homepage and other priority pages, then re-run the same lab profile you use for monthly reporting. Scheduled PageSpeed monitoring catches the case where Brotli is on in one region and missing in another, or where a theme update reintroduces uncompressed CSS while the dashboard still says compression is enabled. Pair those runs with a short note in the monthly report: encoding verified on the document and main CSS/JavaScript; LCP element and Time to First Byte trend unchanged or improved.

That habit keeps the compression ticket from being closed while LCP is still slow. It also stops the next quarterly review from reopening “we turned Brotli on months ago” when the real issue was always the hero image or the origin. Include compression checks in the same monitoring cadence you already use for Core Web Vitals regressions. A separate ritual that nobody opens after launch week does not help.

FAQ

Does Brotli always improve Largest Contentful Paint?
No. It can shorten download time for text on the critical path when that download was a real bottleneck. It will not fix a slow LCP image, a late-discovered hero, or a high Time to First Byte caused by origin work. Before-and-after lab runs on the same profile show whether the change mattered.

Why does Enable text compression still fail after we turned Brotli on?
The Lighthouse audit looks at individual text resources above a size threshold, not at a single CDN toggle. HTML may be compressed while CSS or JavaScript is not, or the lab path may differ from the URL you checked by hand. Confirm Content-Encoding on each flagged URL.

Can Brotli make PageSpeed scores worse?
Yes. High-quality dynamic compression on every HTML response can raise Time to First Byte. Double compression and compressing already-compressed media waste CPU without helping LCP. Prefer precompressed static assets and moderate settings for dynamic HTML, then retest.

Is gzip still needed if Brotli is enabled?
Yes as a fallback. Keep gzip for clients or hops that do not take br. Verify both encodings on the homepage and other priority pages rather than assuming the dashboard covers every path after a CDN or origin change.

CTA

If the toggle is green and LCP is still slow, treat compression as verified delivery work and name the next bottleneck in plain language. Confirm encoding on the critical path, then put image discovery, Time to First Byte, and render-blocking scripts on the work item with an owner. For enablement detail and MIME allow-lists, use the Watcher compression guide linked above; for caching that sticks beside those bytes, use the Cache-Control piece. When you need scheduled lab history across many client URLs so the next deploy cannot silently drop Content-Encoding, run continuous PageSpeed checks in Apogee Watcher rather than another one-off Insights paste.

References

Brotli and Gzip Compression: Shrink Text Assets Without Breaking PageSpeed Scores (Apogee Watcher)
Cache-Control Headers for Web Performance: CDN and Browser Caching That Sticks (Apogee Watcher)
Enable text compression (Chrome for Developers)
Largest Contentful Paint (LCP) (web.dev)
Brotli (MDN Web Docs)

Originally published on Hashnode.

Why is PageSpeed Insights worse than my local Lighthouse score?

Fri, 02 Oct 2026 07:54:07 +0000

Same URL, same Lighthouse engine: different CPU, throttling, and cache. Compare tools fairly instead of merging the scores.

You run Lighthouse in Chrome DevTools on a client URL and see Performance 94. You paste the same URL into PageSpeed Insights and the lab Performance score drops to the sixties. The audits look related. The numbers do not. Neither result is “lying.” They ran the same Lighthouse family of audits on different machines, with different throttling behaviour, and often with different cache and extension state.

That gap shows up constantly in agency Slack threads and client calls. People then optimise against the friendlier number, or treat PageSpeed Insights as broken. What follows explains why PageSpeed Insights lab data is often worse than a local Lighthouse run, how to compare fairly, and which result to trust for client work. For how Lighthouse turns metrics into a score, see How Lighthouse Performance Scores Are Recorded and Calculated. For when one-off PageSpeed Insights checks stop being enough, see PageSpeed Insights vs Automated Monitoring.

Same Lighthouse engine, different machines

PageSpeed Insights lab results are Lighthouse runs on Google’s shared infrastructure. Chrome DevTools Lighthouse and the Lighthouse CLI run on your laptop. The audit set is related. The CPU is not.

Lighthouse records a benchmarkIndex (device score) that describes how fast the host can run JavaScript before the audited page load. A powerful developer machine often scores much higher than the PageSpeed Insights workers. Mobile runs also apply a CPU slowdown (commonly described as about 4×) so the lab approximates mid-tier phones. Four times a fast laptop is still faster than four times a slower shared worker. Long tasks, Total Blocking Time, and Interaction to Next Paint proxies move first when the host is slower. Largest Contentful Paint and other paint timings can move too when layout and script work stretch.

Network path and test location add another layer. PageSpeed Insights picks from a small set of regions. Your laptop sits on your office fibre next to a nearby CDN edge. Cold loads on a distant worker see different latency even before CPU differences matter.

So a lower PageSpeed Insights lab score does not prove the site “got worse overnight.” It often proves you compared two hosts.

Why Total Blocking Time jumps on PageSpeed Insights

Total Blocking Time is especially sensitive to host speed. It sums the portions of long tasks that exceed 50 milliseconds during page load. On a fast local CPU, many tasks finish just under that line and never enter Total Blocking Time. On a slower PageSpeed Insights worker, the same work crosses 50 milliseconds and the metric spikes. Performance score then falls even when First Contentful Paint only moved a little.

That pattern is well documented in developer threads and Lighthouse discussions: throttling and slower hosts push borderline tasks over the threshold. Simulated throttling (PageSpeed Insights lab default) is also not the same as packet-level throttling used by some other lab tools. Treat PageSpeed Insights lab numbers as one environment, not as a perfect replay of your MacBook.

Local pollution: extensions, cache, and warm state

Local Lighthouse can look better for reasons that have nothing to do with the production HTML.

Chrome extensions inject scripts and change network behaviour. A warm disk cache and service worker can skip work that a cold PageSpeed Insights load always pays. Cookie banners and consent layers may already be dismissed on your profile. Antivirus, VPN, and other processes on the machine add noise. DevTools may warn when it detects conditions that skew the audit; PageSpeed Insights starts from a cleaner cold profile on Google’s side.

Use an Incognito window with extensions disabled, or the Lighthouse CLI against a clean profile, when you need a local baseline. Even then, expect residual host-speed differences versus PageSpeed Insights. A clean local profile removes extension noise; it does not turn your laptop into Google’s lab workers.

Do not mix PageSpeed Insights field data with local lab

PageSpeed Insights shows two stories on one page. The top block is Chrome UX Report field data when enough real Chrome users visited the origin or URL. The lower block is a fresh Lighthouse lab run.

Your local Lighthouse score is lab only. Comparing a local Performance score to the field Core Web Vitals categories is a category error. Field windows cover days of real devices and networks. Lab is one controlled load. Lab-versus-field reconciliation is a separate topic; here the focus is local lab versus PageSpeed Insights lab.

If field looks healthier than PageSpeed Insights lab, users may be on faster devices, revisit with cache, or you may be reading origin-level field against a URL-level lab run. Calibrate, do not average the two into one fake “truth.”

How to compare fairly (and what to trust for client work)

Source	What it measures	Best use
Chrome DevTools / local CLI	Lab on your machine	Before/after while debugging the same URL
PageSpeed Insights lab	Lab on Google’s workers	Shareable cold-load baseline close to what clients paste
PageSpeed Insights field (CrUX)	Real-user Core Web Vitals	Trend and eligibility, not a Lighthouse score twin

Rules that keep agencies from mixing incompatible scores:

Compare before and after on the same tool. Local 94 → local 88 after a change is useful. Local 94 versus PageSpeed Insights 61 is not a regression proof.
Match strategy. Mobile versus mobile. Desktop versus desktop.
Prefer cold loads when you claim a public score. Clear cache or use a clean profile locally.
Read the device score / environment notes in the Lighthouse JSON when you need to explain a gap to a technical lead.
For client reporting, prefer a stable lab path. Scheduled PageSpeed Insights-style runs from a monitoring product reduce “my laptop versus your laptop” arguments. Spot checks still help debugging; they are a weak single source of truth for retainers.

DebugBear’s comparison of PageSpeed Insights and Lighthouse, and Google’s own Lighthouse variability notes, make the same point: synthetic scores depend on CPU, location, Chrome version, and throttling method. Absolute equality across tools is the wrong goal. Directional agreement on the same tool is the right one.

FAQ

Is PageSpeed Insights “more accurate” than local Lighthouse?

For cold-load lab diagnostics that clients can reopen in a browser, PageSpeed Insights is often the better shared reference. For day-to-day engineering, local Lighthouse before/after on the same machine is faster and still valid. Neither replaces field Core Web Vitals when you need real-user truth.

Why does my local Lighthouse match PageSpeed Insights sometimes?

When host speeds are closer, the URL is light on main-thread work, or the runs simply land nearer each other, gaps shrink. Heavy JavaScript and layout work widen them. Treat occasional agreement as luck on a light page, not proof that the two environments are interchangeable.

Should I raise local CPU slowdown until scores match PageSpeed Insights?

You can experiment with CLI throttling for research. Do not treat a personalised slowdown as a contract with the client unless everyone agrees that environment is the baseline. Document the tool and settings you will use in the retainer.

Does a better local score mean Search Console will improve?

Not by itself. Search Console and Chrome UX Report track field data. Lab wins help you find fixes; field windows confirm whether real users felt them.

What to do next

Pick one money URL. Run Lighthouse twice locally in a clean profile and note the spread. Run PageSpeed Insights lab on the same URL and strategy. Write down host differences instead of merging the scores. Put the PageSpeed Insights lab number (or a scheduled monitoring run) in the client pack when you need a shareable baseline, and keep local Lighthouse for the fix loop.

If you manage many client origins, automate the PageSpeed Insights-shaped lab path so every site uses the same cold-load recipe. That is the operational answer to “whose Lighthouse do we believe?”: agree the environment once, then track change inside it. Spot laptop runs stay useful for debugging; they should not be the only number in the monthly pack.

References

PageSpeed Insights vs. Lighthouse: What's the Difference? (DebugBear)
Lighthouse variability / scoring environment (Chrome Lighthouse docs)
Why Lighthouse via PageSpeed Insights API differs from CLI (Stack Overflow)
Why TBT on PageSpeed Insights differs from a local machine (Stack Overflow)
How Lighthouse Performance Scores Are Recorded and Calculated (Apogee Watcher)
PageSpeed Insights vs Automated Monitoring: When Manual Checks Aren't Enough (Apogee Watcher)

Originally published on Hashnode.

How to set performance budgets that CI and clients both keep

Wed, 30 Sep 2026 07:16:40 +0000

Same LCP and CLS numbers in the merge gate and the retainer review — not two conflicting greens.

Lighthouse CI can report green on a pull request while the client’s monthly PageSpeed pack still shows amber on Largest Contentful Paint. Both results can be “correct.” They measured different URLs, different strategies, or different thresholds that nobody reconciled when the retainer started. That mismatch is expensive: engineering trusts the gate, sponsors distrust the report, and the agency spends the call explaining why two greens disagree.

Web performance budgets only work when the merge gate and the client review speak the same language. What follows is the agency ritual that keeps those numbers aligned: pick thresholds once, wire them into CI for protection, and reuse them on production schedules for the retainer. For the CI plumbing itself, use How to Set Up Performance Budgets in CI/CD Pipelines. For a reusable threshold sheet, use Performance Budget Thresholds Template.

Why CI budgets and client budgets drift apart

Teams usually invent two documents by accident. Engineering owns a Lighthouse CI assertion file tuned to preview URLs. Account leads own a slide that still says “keep PageSpeed healthy” without naming LCP, Interaction to Next Paint, or Cumulative Layout Shift. After a few sprints the CI file tightens, the deck softens, and nobody notices until a sponsor asks why last week’s merge was green and this week’s field window is not.

Three drift patterns show up often:

Different URLs. CI protects / on the preview host. The retainer reports /checkout on production.
Different clocks. CI is lab-only. The client pack mixes CrUX categories without labelling the window.
Different owners. Developers change assertions without telling account leads; account leads invent “good enough” bands for a sales deck.

Performance budgets are the contract that stops that drift. web.dev’s performance budgets 101 frames them as limits you set before you ship. Agencies need one more step: the same limits must survive the handoff from demo to retained delivery.

One threshold language both sides keep

Start with Core Web Vitals in the same units Google already publishes, then add supporting lab metrics only if someone will act on them.

Metric	Example mobile budget (lab)	Why both sides care
LCP	≤ 2.5 s	Hero and checkout speed sponsors recognise
INP	≤ 200 ms	Interaction regressions after tag or SPA changes
CLS	≤ 0.1	Layout shift from banners, embeds, late fonts
Performance score (optional)	≥ 90 on priority URLs	Useful as a CI gate; weaker as the only client KPI

Write those numbers into a shared sheet once, with owners and review cadence. Lab budgets belong in CI assertions and in scheduled production tests. Field (CrUX) categories sit beside them as a labelled second row, not as a silent override of the lab gate. When CrUX has no data for an origin, say so plainly rather than inventing a green badge from lab alone.

Weight and request-count budgets still help on image-heavy templates. Keep them secondary to CWV language in client conversations unless the engineering team already lives in kilobytes. Official orientation for Lighthouse-based budgets sits in Use Lighthouse for performance budgets; MDN’s Performance budgets guide is a solid companion for the same idea.

The demo → retained budget ritual

Agencies that keep budgets sticky usually run a short ceremony when a new client starts, then refuse to invent new bands every quarter.

1. Demo with production-shaped URLs. Show the money paths you will monitor, not only the homepage. Capture baseline lab numbers and note field availability.

2. Agree thresholds in writing. Use the shared sheet. Name mobile and desktop if both matter. Name who owns a breach (agency sprint vs client tag team).

3. Mirror into Lighthouse CI. Assertions protect merges on the preview URLs that map to those money paths. Do not encode a vanity homepage score that production never measures.

4. Mirror into production schedules. The same LCP / INP / CLS lines become the green and red language in alerts and monthly reports. Scheduled PageSpeed Insights (or equivalent) runs keep history; budgets decide when humans get interrupted.

5. Review on a calendar, not on vibes. Quarterly is enough for most retainers unless a redesign is live. Change a threshold only with a written reason both sides can find later.

That ritual is the product of the retainer. Tools differ. DIY scripts, portfolio monitors, and CI plugins all work when the sheet is the source of truth. Apogee Watcher is built for the production side of that loop (schedules, budgets, alerts across organisations). Keep Lighthouse CI thin for merge gates either way.

What stays in CI versus what stays on production schedules

Job	Belongs in Lighthouse CI	Belongs on production monitoring
Block a bad merge	Yes	No
Catch regressions after deploy or tag changes	Weak alone	Yes
Multi-tenant client reporting	No	Yes
CrUX / field context	Rarely	Yes, labelled
Same LCP ≤ 2.5 s language	Yes (assertions)	Yes (budgets + reports)

CI answers: “May this change ship?” Production monitoring answers: “Is the live portfolio still inside the contract?” Confusing the two jobs produces either enormous workflows or neglected configurations. Keep both; share the threshold language. When account leads can point at the same LCP band the pipeline just enforced, the retainer review stops sounding like two different products.

FAQ

What are performance budgets in a web performance sense?
Numeric limits for page experience (and sometimes weight or request counts) that you set before shipping and reuse when something regresses. In agency retainers they should match the Core Web Vitals language you put in client reports.

How do performance budget thresholds differ from a vague “keep PageSpeed high” promise?
Thresholds name metric, strategy, URL set, and pass/fail band. Vague promises invite taste debates. Use a shared template so account leads are not inventing bands per deck.

Should Lighthouse CI performance budgets match production budgets exactly?
Match the metrics and bands that matter commercially. Preview hosts may differ slightly from production; document that. Do not run a 95 score gate in CI while the retainer quietly accepts 70 on checkout.

Do Core Web Vitals budgets replace Search Console?
No. Budgets organise lab (and optionally field) pass/fail for delivery. Search Console remains a field and indexing source for many SEO conversations. Use both with clocks labelled.

Who owns a budget breach?
Decide at kick-off. Tag-manager and marketing-pixel breaches often sit with the client. Theme and critical-path breaches often sit with the agency. Write the split once so the alert does not become a blame meeting.

CTA

Pick one retainer client this week. Export or write a one-page threshold sheet for three money-path URLs, wire the same LCP / INP / CLS bands into Lighthouse CI, and reuse those bands on whatever production schedule you already run. When you need the CI assertion path in detail, follow performance budgets in CI/CD pipelines. When you need a blank sheet, use the performance budget thresholds template.

Portfolio schedules and budget alerts without a private spreadsheet of PageSpeed tabs are what Apogee Watcher is built for. Keep your merge gates. The sheet you agree with the client is still the source of truth either way.

References

Performance budgets 101 (web.dev)
Use Lighthouse for performance budgets (web.dev)
Performance budgets (MDN)
Start Performance Budgeting (Addy Osmani)
How to Set Up Performance Budgets in CI/CD Pipelines (Apogee Watcher)
Performance Budget Thresholds Template (Apogee Watcher)
Understanding Core Web Vitals and Google search results (Google Search Central)

Originally published on Hashnode.

Google Lighthouse Score Explained: How Scoring Works

Mon, 14 Sep 2026 19:47:44 +0000

A Google Lighthouse score is a lab Performance number from 0 to 100 for one controlled run. Scoring does not average raw milliseconds. Each metric is mapped through an HTTP Archive curve, then weighted into one score for a single URL and one device strategy.

Agencies usually meet that number as the green or amber circle in PageSpeed Insights. Clients treat it as "Google speed." It is neither a ranking factor by itself nor a field Core Web Vitals percentile. It is recorded under simulated conditions, then calculated with documented weights that change across Lighthouse majors.

TL;DR: Record lab metrics in a throttled run, convert each to a 0–100 metric score, apply Lighthouse 10 weights (TBT 30%, LCP and CLS 25% each, FCP and Speed Index 10% each), and report the blend as lab only. Keep CrUX and Search Console on a separate slide. Chrome’s Lighthouse performance scoring guide is the source of truth; what follows is the agency translation, including a worked example and FAQ.

What a Lighthouse Performance score actually is

The Performance score is a single 0–100 summary for one lab run of one URL under one device strategy (mobile or desktop). It is not a ranking factor by itself. It is not a rolling average of real visitors. Opportunities and Diagnostics in the report do not add points directly; they explain ways the underlying metrics might improve, which can raise the score indirectly when those metrics move.

Colour bands in the docs are simple: 0–49 poor (red), 50–89 needs improvement (orange), 90–100 good (green). A perfect 100 is unusually hard. Moving from 99 to 100 can need as much metric improvement as moving from 90 to 94. For client language, “good” means a lab run that cleared 90 under that profile, not that every user on every network had a green experience.

PageSpeed Insights uses Lighthouse for the lab block. When people say “the PageSpeed Insights score,” they usually mean that lab Performance category, sometimes while looking at a CrUX field panel on the same screen. Keep those two stories separate in every deck.

How Lighthouse records lab metrics in a controlled run

Recording comes first. Lighthouse (and PageSpeed Insights lab mode) loads the URL in a controlled environment: a chosen form factor, simulated network and CPU throttling for typical mobile profiles, and a single navigation. During that load it measures timings and layout behaviour. Common Performance metrics include First Contentful Paint (FCP), Speed Index (SI), Largest Contentful Paint (LCP), Total Blocking Time (TBT), and Cumulative Layout Shift (CLS). Diagnostics such as Time to First Byte (TTFB) may appear as supporting detail. None of those values are taken from real visitors in that run.

The lab profile matters. Mobile and desktop use different throttling and, since Lighthouse 6, different scoring curves so desktop is not scored on mobile HTTP Archive distributions. Running on a quiet office machine with extensions disabled still differs from a busy shared CI worker. Chrome documents common causes of score fluctuation: ads and A/B tests, routing changes, device power, extensions, antivirus. Treat a single paste as a sample from a distribution, not as the only possible score for that URL.

Scheduled monitoring reduces the “two screenshots, no baseline” problem. You still measure lab conditions, but you compare like with like over time. That is the operational gap we described in PageSpeed Insights versus automated monitoring.

How Lighthouse calculates the 0–100 Performance score

Calculation is a second step. Lighthouse does not average raw milliseconds into one number. For each metric it maps the recorded value onto a 0–100 metric score using a log-normal scoring curve calibrated from HTTP Archive site data. Those metric scores stay under the hood in the usual report UI. The visible Performance score is then a weighted average of the metric scores.

Chrome describes the curve control points clearly. The 25th percentile of HTTP Archive data for a metric maps to a metric score of 50. The 8th percentile maps to 90 (the “good” control point). Between roughly 0.50 and 0.92 the relationship is nearly linear; near 0.96 returns diminish and further metric gains buy less score. Exploring a metric in the Lighthouse scoring calculator is the fastest way to see how a raw LCP or TBT value becomes a metric score before weights apply.

Because the curves come from real-site distributions, “good” is relative to the web as captured in HTTP Archive, not to an arbitrary round number your client invented in a brand guideline. When Lighthouse major versions change weights or curves, historical scores need a footnote. Always cite the Lighthouse version your tool used when you compare quarters.

Lighthouse scoring weights (Lighthouse 10)

Chrome’s documented Lighthouse 10 weights for the Performance score are:

Metric	Weight
First Contentful Paint (FCP)	10%
Speed Index (SI)	10%
Largest Contentful Paint (LCP)	25%
Total Blocking Time (TBT)	30%
Cumulative Layout Shift (CLS)	25%

TBT carries the largest single weight. LCP and CLS share 25% each. FCP and Speed Index are lighter. Earlier majors differed; Lighthouse 8 still weighted Time to Interactive and used a different CLS weight. Verify the table for the version you ship in CI or see in PageSpeed Insights, and re-check the calculator when Google publishes a new major.

INP may appear in field tooling and in some report contexts, but the lab Performance blend documented for Lighthouse 10 emphasises TBT as the interactivity proxy inside the score. Do not tell a client that “INP is 30% of the Lighthouse score.” Point them at TBT for lab scoring and at field INP for CrUX and Search Console when samples exist. Metric definitions live in LCP, INP, and CLS explained; field interactivity detail is in our INP guide.

Worked example: from metric scores to a Performance number

Suppose a mobile lab run produces these metric scores (already mapped through the curves; not raw milliseconds): FCP 90, Speed Index 85, LCP 70, TBT 60, CLS 95. Apply the Lighthouse 10 weights:

FCP: 90 × 0.10 = 9.0
Speed Index: 85 × 0.10 = 8.5
LCP: 70 × 0.25 = 17.5
TBT: 60 × 0.30 = 18.0
CLS: 95 × 0.25 = 23.75

Sum ≈ 76.8, which rounds to a Performance score in the mid-70s (needs improvement). The same raw LCP in milliseconds can yield a different metric score when the curve or Lighthouse major changes, so always cite the version beside the number. Open the Lighthouse scoring calculator to poke individual levers before you promise a client that "ten points is one easy fix."

Lighthouse version footnote: Weights and curves above follow Chrome’s documented Lighthouse 10 Performance scoring. PageSpeed Insights and CI runners may ship a different major. When you compare quarters or tools, record the Lighthouse version (or PageSpeed Insights date) on the report. A five-point swing across a major upgrade can be scoring math, not a regression.

Why the Performance score is not the same as Core Web Vitals field data

Field Core Web Vitals come from real Chrome users in the Chrome User Experience Report (CrUX), with Search Console and the PageSpeed Insights field section as common surfaces. Lab Performance scores come from one synthetic navigation. Both can mention LCP and CLS; only the lab score folds in Speed Index and TBT with the weights above. Field INP has no twin inside that Lighthouse 10 weight table.

Question	Lab Performance score	Field Core Web Vitals (CrUX)
Who was measured?	Controlled lab profile	Real Chrome users (sample)
What number?	Weighted 0–100 from metric scores	Percentiles for LCP, INP, CLS (and related)
Interactivity in the blend?	TBT (lab)	INP (field)
Good enough for SEO field status?	No, not by itself	Search Console / CrUX when eligible
Useful after a deploy?	Yes, fast regression signal	Yes, after the rolling window catches up

Agencies need both clocks. Lab catches “we broke the template today.” Field answers “Chrome users over ~28 days still feel it.” We covered the field lag in Why your Core Web Vitals fix is not in CrUX yet and the synthetic versus RUM split in When to use synthetic versus real user monitoring. Missing field rows are a sampling problem, not proof the lab score is wrong; see When PageSpeed Insights shows no CLS or INP.

Mid-article check: run the URL you are arguing about

Before you debate a screenshot in Slack, run a free PageSpeed check on the same URL and strategy (mobile or desktop). Pair the lab Performance score with the metric breakdown, then keep the scoring calculator open so stakeholders see how LCP, TBT, and CLS drive the blend. Scheduled history in Apogee Watcher beats one heroic paste after a tag-manager change.

Why Lighthouse scores fluctuate between runs

Variability is normal. The same URL can move several points between back-to-back runs when ads, consent banners, third-party scripts, or CPU contention differ. Chrome’s variability documentation exists for a reason. For retainers, prefer medians or repeated scheduled runs over a single heroic screenshot. Agree the device strategy (mobile versus desktop) before you argue about a five-point swing.

CI and local DevTools can also disagree because of Lighthouse version, throttling presets, and whether the environment matches PageSpeed Insights. When you automate audits with coding agents or DevTools workflows, still treat the Performance number as lab math under a stated version. Our note on Lighthouse audits with AI agents covers the agency gap between one-off agent runs and portfolio schedules. Separate audits such as Baseline Features change Best Practices diagnostics without rewriting the Performance weight table; see Lighthouse’s Baseline Features audit.

How agencies should report Lighthouse scores to clients

Name the artefact: “Lighthouse / PageSpeed Insights lab Performance score,” not “Google’s speed ranking.”
State device and version: mobile or desktop, and Lighthouse major when known.
Show the drivers: LCP, TBT, and CLS usually explain most of the blend under current weights.
Separate field status: CrUX / Search Console on their own slide or paragraph.
Use trends: three or more scheduled runs beat one paste after a deploy.
Open the calculator when a stakeholder wants to know how many milliseconds buy the next ten points.
Avoid score chasing at 99–100 unless the contract truly requires vanity greens; spend engineering time on user-visible LCP and TBT first.

Budgets work better on metric thresholds than on a single Performance integer, because the integer hides which metric moved. Pair score trends with LCP and TBT budgets on money URLs so engineering knows what to fix. A five-point score drop that is all TBT is a different ticket from one that is all CLS.

Where Apogee Watcher stores Performance scores

Apogee Watcher schedules PageSpeed Insights tests across multi-tenant portfolios and stores the lab category scores and metric payloads from those runs for trends, budgets, and alerts. That history is lab data under Google’s PSI/Lighthouse pipeline. It is not a substitute for CrUX percentiles, and it does not claim to weight INP inside the Performance blend.

Use Watcher when you need the same URLs retested on a cadence after deploys, with mobile and desktop strategies and client-ready charts. Use CrUX and Search Console for field Core Web Vitals when samples exist. Use the scoring calculator when someone asks how the 0–100 number is built. Layer the tools; do not collapse them into one green circle in a slide.

Start a free trial to schedule PageSpeed tests and keep Performance score trends beside metric budgets. Or run a free PageSpeed check on a priority URL and open the Lighthouse scoring calculator beside the result.

FAQ

What is a Google Lighthouse score?

A Google Lighthouse score usually means the Performance category (0–100) from one lab audit, alongside Accessibility, Best Practices, and SEO category scores. The Performance number is the weighted blend covered here. It is not an average of real-user timings and not a Search Console field status.

How does Lighthouse scoring work?

Recording comes first: Lighthouse loads the URL under a fixed device and throttling profile and measures lab metrics (FCP, Speed Index, LCP, TBT, CLS under current docs). Calculation comes second: each metric maps to a 0–100 metric score via log-normal HTTP Archive curves, then those metric scores are weighted into the visible Performance number.

What is a good Lighthouse Performance score?

Chrome’s colour bands: 0–49 poor, 50–89 needs improvement, 90–100 good. "Good" means that lab run cleared 90 under that profile, not that every visitor on every network had a green experience. Chasing 99–100 is usually vanity; spend engineering time on user-visible LCP and TBT first.

How do lab Lighthouse scores differ from PageSpeed Insights and CrUX?

PageSpeed Insights shows a Lighthouse lab block and, when eligible, a CrUX field block on the same page. The lab circle is Lighthouse scoring. CrUX is aggregated Chrome field data (percentiles for LCP, INP, CLS), not the weighted 0–100 Performance blend. For when to lean on synthetic lab runs versus real-user monitoring, see when to use synthetic versus real user monitoring. Do not collapse "the PageSpeed Insights score," "Lighthouse," and "Core Web Vitals" into one sentence in a client deck.

Does Google use the Lighthouse Performance score as a ranking factor?

Google’s ranking systems use page experience signals tied to real-user Core Web Vitals concepts, not your lab Performance integer as a published ranking weight. Treat the score as an engineering and reporting aid. Use CrUX and Search Console for field status when data exists.

Why is Total Blocking Time in the score if INP is the Core Web Vital?

Lab runs need a synthetic interactivity signal during a single load. TBT fills that role inside the documented Lighthouse 10 Performance weights. INP is a field metric built from real interactions over a page life. Report both without merging them into one sentence.

Do Opportunities change the Performance score directly?

No. Only metric scores feed the weighted average. Opportunities and Diagnostics guide fixes that may improve those metrics on the next run.

Why did desktop scores change a lot after older Lighthouse versions?

Before Lighthouse 6, desktop runs could be scored against mobile-derived curves and look artificially strong. From v6 onward, desktop has its own scoring. Compare desktop history carefully across that boundary.

Can Apogee Watcher show how each metric score was weighted for a run?

Watcher stores the PageSpeed Insights / Lighthouse results from scheduled tests for trends and budgets. For interactive weight exploration, use Google’s scoring calculator and Chrome’s scoring documentation alongside your Watcher history.

References

Lighthouse performance scoring (Chrome for Developers)
Lighthouse scoring calculator (Chrome)
HTTP Archive (scoring curve source data)
Lighthouse variability (Lighthouse project)
<a href="https:

How to increase PageSpeed/performance of a website that makes heavy use of interactive maps?

Fri, 04 Sep 2026 10:21:46 +0000

Defer map JavaScript until intent, reserve container height, and treat pan and zoom as INP work—not a one-time Lighthouse pass on a static screenshot.

Store locators, delivery zones, property listings, and field-service dashboards often ship a full map widget above the fold because the business needs pins, polygons, and search on day one. PageSpeed Insights on that same URL frequently returns poor Largest Contentful Paint, high Interaction to Next Paint on pan and zoom, and Cumulative Layout Shift when the map canvas replaces a grey box. The gap is not “maps are bad”; it is that map SDKs behave like heavy third-party applications embedded inside a marketing page that Lighthouse still treats as a document.

Below is a practical checklist for improving PageSpeed on map-heavy sites without removing the map. We use it when auditing client estates in Apogee Watcher; the same steps apply whether you run Google Maps, Mapbox, Leaflet, or a custom tile stack.

Why do interactive maps hurt PageSpeed scores more than static images?

An interactive map is rarely one request. Typical embeds pull a large JavaScript bundle, WebGL or canvas rendering, vector or raster tiles, geocoding endpoints, and UI chrome (search, zoom controls, attribution). Lighthouse scores the initial navigation and a short interaction window. Maps pay for that work in three places at once:

Download and parse of map JavaScript on the critical path.
Paint of a large surface that often becomes the Largest Contentful Paint element.
Main-thread work on drag, pinch, and zoom that shows up under Interaction to Next Paint long after First Contentful Paint looks acceptable.

Static map screenshots or server-rendered tiles can satisfy “show a location” without loading the full SDK on first paint. Interactive maps are justified when users must explore; the performance task is to keep that exploration off the path until they ask for it.

Which Core Web Vitals break first on map-heavy pages?

Metric	What map embeds usually trigger	What to check in lab
Largest Contentful Paint (LCP)	Map canvas or hero tile layer becomes LCP; late SDK init delays paint	Filmstrip: blank or grey box until SDK ready
Interaction to Next Paint (INP)	Pan, zoom, drag handlers on main thread	Trace interactions after load, not only idle metrics
Cumulative Layout Shift (CLS)	Container without fixed height; controls injected above map	Layout shift when map replaces placeholder

For a deeper read on INP mechanics, see Understanding INP: The Newest Core Web Vital and Why It Matters. For layout stability patterns beyond maps, see CLS Deep-Dive: Common Causes and Fixes for Layout Shift.

How should you defer map JavaScript until the user shows intent?

The highest-leverage change on many sites is click-to-load (sometimes called a facade):

Render a static image, lightweight SVG outline, or low-zoom tile preview in the map container.
Reserve the final width and height in CSS so nothing jumps when the real map mounts.
Load the map SDK only after the user clicks “Show map”, taps the preview, or scrolls the map into view (if you use intersection-based loading, still keep a explicit affordance on mobile).

Async and defer attributes help script order, but they do not remove parse and execution cost from the first seconds after load. Intent gating moves that cost to the moment the user chooses interactivity. On listing pages with twenty pins, consider loading the map only on the detail view and keeping the index page on static previews.

What placeholder and container rules stop layout shift?

Map widgets often mount into a div with min-height: 400px that collapses before the SDK injects inner nodes. Fix the box before the SDK runs:

Set explicit height (or aspect ratio) on the map wrapper for each breakpoint.
Preload a static preview that matches the final aspect ratio.
Avoid injecting toolbars or consent banners above the map container after paint without reserved space.

If Lighthouse reports CLS on a map page, inspect whether the shift is the map itself or a late cookie banner pushing the canvas down. Both need reserved space; only one needs a deferred SDK.

How do tile weight and imagery affect Largest Contentful Paint?

Even when JavaScript is deferred, the first painted map surface may still be LCP if you load high-resolution raster tiles immediately. Mitigations that usually help:

Start at a lower zoom or simplified basemap on first paint.
Prefer vector tiles where bandwidth and device allow; watch GPU cost on low-end phones.
Do not treat the map as the hero on mobile unless the user task requires it; move search or copy above the fold and lazy-load the map below.
Compress and size any static preview image used as a facade; a 200 KB PNG preview defeats the purpose of deferring the SDK.

Compare mobile and desktop separately. A map that is below the fold on phone but full-width on desktop will have different LCP elements per strategy.

Why do pan and zoom show up as Interaction to Next Paint problems?

Lighthouse’s lab INP sample includes clicks, taps, and keyboard input during the measurement window. Map libraries attach move, drag, and wheel listeners that can keep the main thread busy. Mitigations:

Throttle redraw work during drag; avoid synchronous geocoding on every pixel move.
Offload heavy geometry work to Web Workers where the SDK allows it.
Reduce overlapping third-party tags on the same page; map pages often also load analytics, chat, and consent stacks that compete for the same thread. Triage those scripts with the same discipline as any other heavy embed; see Third-Party Scripts and Performance: How to Identify and Fix the Worst Offenders.

One green lab run on a map page that nobody pans is not proof of good INP. Re-test with a short script: open the page, wait for idle, then pan and zoom before closing the trace.

When should the map leave the critical path entirely?

Not every URL needs a live embed on first paint. Strong candidates for off-critical-path treatment:

Blog or editorial pages with a single reference location (static map link or image is enough).
SEO landing pages where the map supports trust but not conversion on first visit.
Mobile homepages where search and phone CTAs matter more than an interactive canvas.

Keep full interactivity on flows where the user task is explicitly spatial: “find nearest store”, “draw delivery zone”, “filter listings by map bounds”. Match embed weight to task frequency, not to what the design comp showed on day one.

How do you monitor map pages after you ship?

Maps regress silently when marketing adds a tag, when the SDK auto-upgrades, or when tile CDN latency shifts by region. Treat map templates as first-class URLs in monitoring, not as one-off homepage checks:

List every template that mounts a map (store locator, listing detail, checkout zone picker).
Run mobile and desktop lab tests on a fixed URL set after each release.
Compare LCP element and INP on interaction scripts, not only Performance score.
Share #summary links from domain reports when you audit a whole host with many location pages.

Automated PageSpeed monitoring catches drift when a plugin re-enables synchronous map loads on staging.

FAQ

Can I lazy-load a Google Maps iframe and still pass Core Web Vitals?
Often, if the iframe is not the LCP element and the placeholder reserves space. Iframes still fetch nested documents; combine lazy loading with a static preview and load on click for the best lab and field results.

Does replacing Google Maps with Mapbox automatically improve PageSpeed?
Not by itself. Any full SDK can dominate LCP and INP. Compare bundle weight, default tile behaviour, and how your integration mounts the canvas.

Will async on the map script fix render-blocking warnings?
It helps script ordering but does not remove execution cost. Intent gating and smaller first paint surfaces usually move scores more than attribute tweaks alone.

Should the map be Largest Contentful Paint on a store locator page?
Sometimes yes. If the user’s job is “pick a store on the map”, optimise the map path rather than hiding it. If the job is “call this number”, promote copy and defer the embed.

What to do next

Pick one high-traffic map URL, run PageSpeed Insights on mobile, and note whether LCP, INP, or CLS fails first. Implement click-to-load with a fixed-height container, re-test with a pan-and-zoom interaction, then roll the pattern across templates. If you manage many client sites, add those URLs to a recurring monitoring set so the next plugin update does not restore synchronous map loads without notice.

References

Google Maps 100% page speed guide (Core Web Vitals.io)
Remove render-blocking JavaScript (Google PageSpeed Insights documentation)
Web Vitals (web.dev)
Third-Party Scripts and Performance: How to Identify and Fix the Worst Offenders
Understanding INP: The Newest Core Web Vital and Why It Matters
CLS Deep-Dive: Common Causes and Fixes for Layout Shift
How to Set Up Automated PageSpeed Monitoring for Multiple Sites

Originally published on Hashnode.

How we tuned apogee.lu for a 95 mobile PageSpeed score

Mon, 31 Aug 2026 05:39:06 +0000

Render-blocking CSS, Cloudflare HTML rewrite, fixed hero heights, and Watcher domain report Summary before and after

Our corporate site at apogee.lu is a static marketing front door: two HTML pages, a hero photograph, Victor Mono typography, and no application server in the path. It should be an easy Core Web Vitals win. Earlier this month, PageSpeed Insights on mobile still reported First Contentful Paint and Largest Contentful Paint above 2.5 seconds, with render-blocking CSS and a filmstrip that stayed blank until late in the load. We build Apogee Watcher to monitor PageSpeed for client estates; tuning our own homepage was overdue, and we used the new domain-level report Summary to keep the work honest across every URL we ship under that host.

Below is the sequence we ran: domain triage, diagnosis, failed experiments, and what landed us at 95 mobile and 100 desktop in lab tests, with Cumulative Layout Shift at 0.

What PageSpeed Insights showed before we changed anything

Mobile lab runs told a consistent story. First Contentful Paint and Largest Contentful Paint were nearly equal, often around 2.6 to 3.0 seconds. The filmstrip showed no painted pixels for most of the timeline, then the full hero appeared in one step. Total Blocking Time stayed at zero; the bottleneck was not JavaScript on the main thread. Lighthouse flagged render-blocking index.css from our asset CDN. Speed Index lagged because the visible hero arrived only after CSS allowed layout.

That single-URL picture was useful, but incomplete. apogee.lu also ships mailops.html and will keep growing small product pages. A green homepage with a neglected second URL is how agencies ship “we fixed PageSpeed” stories that fall apart on the next client call.

How we used Watcher domain reports before touching CSS

Before we edited templates, we generated a domain report for the host and opened it on the Summary tab. Shared domain reports now default to Summary: an attention-free score (the share of completed mobile and desktop tests that pass Performance, category, and Core Web Vitals gates), a short list of metrics that still need attention, and the top pages that fail those gates. For apogee.lu that view made three decisions cheap: the homepage on mobile was the first attention sink (LCP and render-blocking CSS), not a desktop-only quirk; mailops.html either shared the same head and hero pattern or needed its own pass; and a shareable #summary link kept the before state visible while we experimented locally. Single-URL PageSpeed Insights remains the right drill-down once Summary names the URL and strategy. Domain Summary is what stops you from optimising the wrong page first.

How we found the real Largest Contentful Paint bottleneck

Lighthouse named the hero photograph as the Largest Contentful Paint element, but the image was not the first gate. Our 500w WebP hero is about 15 KB and often finished downloading before layout. The gate was synchronous CSS: the browser waited for stylesheet parse before painting.

On production we also found Cloudflare injecting a cdn-cgi/challenge-platform script into HTML. That script added main-thread work and pushed Largest Contentful Paint above 2.9 seconds. Setting Cache-Control: no-transform on HTML from Apache stopped rewrite; injected scripts left view-source and lab Largest Contentful Paint dropped by roughly a second.

Moving assets to our CDN and reordering the document head

We moved images, CSS, JavaScript, and fonts to https://cdn.apogee.lu/assets/ with preconnect in the head. Critical links now run before title and social meta so discovery order matches what lab filmstrips punish: CDN first, then paint-critical assets, then the rest of the document chrome.

preconnect to the CDN
Hero image preload (500w on mobile via <picture>)
Font preloads and victor-mono.css
Main CSS preload and synchronous stylesheet

The hero download starts in the head even though paint still waits on CSS. That parallel fetch is why preload still helps Largest Contentful Paint when the stylesheet remains synchronous.

Hero images and fixed heights per breakpoint

We ship WebP at 500w, 780w, 1200w, and full width. <picture> serves 500w on viewports up to 980px so mobile does not pull a 780w file on a 2x screen. The preload uses media="(max-width: 980px)" so lab mobile requests the smaller asset first.

Fluid height caused Cumulative Layout Shift when we tried async CSS. min-height: clamp(420px, 62vh, 720px) gave 577px on an iPhone 15 Pro Max (62% of 932px viewport height). Late full CSS shifted .hero-stage and Lighthouse scored 0.197 Cumulative Layout Shift.

We replaced fluid height with fixed values from the same formula at canonical breakpoints:

Breakpoint	Reference viewport	Fixed height
≤980px	390×844	524px
981-1360px	1280×900	558px
≥1361px	design cap	720px

Mobile lab Cumulative Layout Shift returned to 0 after deploy. That is the same “reserve space” idea you see in CLS how-tos, applied to a hero stage whose height was CSS-driven rather than an <img> without dimensions. Width and height on the image alone would not have stopped the stage from resizing when late CSS replaced the fluid min-height.

CSS and fonts: what we tried and what we kept

Extracting inline CSS into index.css shrank HTML but did not remove render-blocking.

Inline critical CSS plus async full stylesheet cut First Contentful Paint to about 1.0 seconds locally and cleared the render-blocking warning. It also broke typography (font-display: optional skipped Victor Mono on slow links) and pushed Cumulative Layout Shift back up when below-the-fold rules arrived late. We kept synchronous main CSS and self-hosted Victor Mono on the CDN instead: four latin WOFF2 files and a small @font-face sheet, with preloads for normal and italic latin, and font-display: swap so the correct family appears after files load. The Lighthouse render-blocking warning can remain while Performance still lands in the mid-90s; we preferred stable layout and brand fonts over chasing a green Opportunities row.

Scores after deploy and what Summary showed next

Mobile PageSpeed Insights after CDN alignment (captured 30 Aug 2026):

Performance 95
First Contentful Paint ~1.7s, Largest Contentful Paint ~2.4s
Cumulative Layout Shift 0, Total Blocking Time 0ms

Desktop lab reached 100 with sub-second paint metrics (FCP 0.5s, LCP 0.6s, Speed Index 0.7s). Speed Index on mobile can stay above 4 seconds because the hero image paints after text; we accept that on a rarely changed marketing page rather than reopening the async-CSS experiment.

We regenerated the domain report and opened Summary again. All 4 completed page tests passed the CWV and category gates, so the attention-free score sat at 100%, with average Lighthouse Performance 97 on mobile and 100 on desktop.

That before/after pair is what we keep when someone asks whether the ship actually moved the portfolio, not only one PageSpeed Insights screenshot.

What we monitor now

We keep apogee.lu on scheduled PageSpeed runs in Watcher and re-check after HTML header, Cloudflare, or CDN cache changes. Lab green after deploy proves the fix shipped. Search Console field data still moves on its 28-day CrUX window, so we do not treat one green lab week as field proof.

Manual PageSpeed Insights before every deploy does not scale across client sites. Apogee Watcher automates runs, stores history, and alerts on regression. Domain reports with Summary give you the same triage shape we used on our own host. For pipeline versus scheduled monitoring, see Lighthouse CI vs managed monitoring.

FAQ

Does CDN CSS stop render-blocking?

No. Synchronous stylesheet blocks first paint until parsed, even for a small file. Preload helps discovery; async or inlined critical CSS removes the gate. We used sync CSS plus fixed hero height to hold Cumulative Layout Shift at zero.

Why preload the hero if CSS blocks paint?

The image can download in parallel with the stylesheet. When paint is allowed, Largest Contentful Paint is shorter if those bytes are already cached instead of starting only after CSS finishes.

Why open a domain report instead of only PageSpeed Insights?

PageSpeed Insights answers one URL. Domain Summary answers which URLs and strategies still need attention under one host, with an attention-free pass rate you can share. Drill into Opportunities after Summary names the page.

Next step: Run PageSpeed Insights on your homepage. If First Contentful Paint equals Largest Contentful Paint in the filmstrip, check render-blocking CSS and injected scripts before resizing images. Generate a free domain scan, open #summary, then start a Watcher trial to keep the same URLs on a schedule.

References

PageSpeed Insights (Google)
Optimize Largest Contentful Paint (web.dev)
Render-blocking resources (Chrome Developers)
Optimize CSS Delivery (Google)
Attention-Free Score: How Domain Reports Show Which Pages Need Work (Apogee Watcher)
Why a Core Web Vitals fix may not show in CrUX yet (Apogee Watcher)
Lighthouse CI vs managed monitoring for agencies (Apogee Watcher)
Apogee Information Systems (corporate site)

Originally published on Hashnode.

How Lighthouse Performance Scores Are Recorded and Calculated

Tue, 18 Aug 2026 09:44:00 +0000

A client forwards a PageSpeed Insights screenshot with a big green 94 and asks whether the site is “fast enough for Google.” Another week the same URL shows 81 on mobile after a tag manager change, and the account thread fills with theories. Both reactions treat the Lighthouse Performance score as a single truth. It is not. It is a lab construct: metrics recorded under controlled conditions, then calculated into a 0–100 number with curves and weights that Google documents and occasionally revises.

Chrome’s Lighthouse performance scoring guide is the source of truth for that math. What follows translates it for agency reporting: what gets recorded in a run, how the score is calculated, which weights apply in current Lighthouse 10 documentation, why the number is not the same as field Core Web Vitals, and how Apogee Watcher stores category scores from scheduled runs without pretending they are CrUX. Keep the calculator open while you read if you want to poke individual metrics.

What a Lighthouse Performance score actually is

How Lighthouse records lab metrics in a controlled run

How Lighthouse calculates the 0–100 Performance score

Lighthouse scoring weights (Lighthouse 10)

Chrome’s documented Lighthouse 10 weights for the Performance score are:

Metric	Weight
First Contentful Paint (FCP)	10%
Speed Index (SI)	10%
Largest Contentful Paint (LCP)	25%
Total Blocking Time (TBT)	30%
Cumulative Layout Shift (CLS)	25%

Why the Performance score is not the same as Core Web Vitals field data

Question	Lab Performance score	Field Core Web Vitals (CrUX)
Who was measured?	Controlled lab profile	Real Chrome users (sample)
What number?	Weighted 0–100 from metric scores	Percentiles for LCP, INP, CLS (and related)
Interactivity in the blend?	TBT (lab)	INP (field)
Good enough for SEO field status?	No, not by itself	Search Console / CrUX when eligible
Useful after a deploy?	Yes, fast regression signal	Yes, after the rolling window catches up

Why Lighthouse scores fluctuate between runs

How agencies should report Lighthouse scores to clients

Name the artefact: “Lighthouse / PageSpeed Insights lab Performance score,” not “Google’s speed ranking.”
State device and version: mobile or desktop, and Lighthouse major when known.
Show the drivers: LCP, TBT, and CLS usually explain most of the blend under current weights.
Separate field status: CrUX / Search Console on their own slide or paragraph.
Use trends: three or more scheduled runs beat one paste after a deploy.
Open the calculator when a stakeholder wants to know how many milliseconds buy the next ten points.
Avoid score chasing at 99–100 unless the contract truly requires vanity greens; spend engineering time on user-visible LCP and TBT first.

Where Apogee Watcher stores Performance scores

FAQ

Does Google use the Lighthouse Performance score as a ranking factor?
Google’s ranking systems use page experience signals tied to real-user Core Web Vitals concepts, not your lab Performance integer as a published ranking weight. Treat the score as an engineering and reporting aid. Use CrUX and Search Console for field status when data exists.

Why is Total Blocking Time in the score if INP is the Core Web Vital?
Lab runs need a synthetic interactivity signal during a single load. TBT fills that role inside the documented Lighthouse 10 Performance weights. INP is a field metric built from real interactions over a page life. Report both without merging them into one sentence.

Do Opportunities change the Performance score directly?
No. Only metric scores feed the weighted average. Opportunities and Diagnostics guide fixes that may improve those metrics on the next run.

Why did desktop scores change a lot after older Lighthouse versions?
Before Lighthouse 6, desktop runs could be scored against mobile-derived curves and look artificially strong. From v6 onward, desktop has its own scoring. Compare desktop history carefully across that boundary.

Can Apogee Watcher show how each metric score was weighted for a run?
Watcher stores the PageSpeed Insights / Lighthouse results from scheduled tests for trends and budgets. For interactive weight exploration, use Google’s scoring calculator and Chrome’s scoring documentation alongside your Watcher history.

References

Lighthouse performance scoring (Chrome for Developers)
Lighthouse scoring calculator (Chrome)
HTTP Archive (scoring curve source data)
Lighthouse variability (Lighthouse project)
LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It
Understanding INP: The Newest Core Web Vital and Why It Matters
PageSpeed Insights vs Automated Monitoring
When to Use Synthetic vs Real User Monitoring for Performance
Why Your Core Web Vitals Fix Isn't in CrUX Yet (28-Day Window)
When PageSpeed Insights Shows No CLS or INP for Your URL
Automate Lighthouse Audits with AI Agents
Lighthouse’s New Baseline Features Audit

Automate Lighthouse Audits with AI Agents: What Chrome DevTools Means for Agencies

Tue, 28 Jul 2026 00:32:22 +0000

Chrome has documented how coding agents can run Lighthouse audits inside Chrome DevTools for agents. Instead of grepping a repository for vague performance clues, the agent loads the page you care about and measures accessibility, SEO, best practices, and agentic browsing against live runtime behaviour. That loop is better for fixing a checkout UI on a local server than another round of static guessing from file names alone.

Agencies should treat this as a development tool, not a finished monitoring programme. A Lighthouse AI agent can catch colour contrast failures or missing meta tags while a developer still has the branch open. It does not replace scheduled tests across forty client sites, budget thresholds, or alerts when a theme deploy regresses Largest Contentful Paint overnight. The sections below separate what Chrome’s agent workflow does well from what multi-tenant PageSpeed monitoring still has to own.

What a Lighthouse AI agent measures in Chrome DevTools

Chrome’s documentation groups agent-driven Lighthouse work into four categories. Accessibility covers screen-reader readiness and related checks such as contrast and ARIA labelling. SEO covers technical discoverability signals search engines need to find and understand the page. Best practices covers modern web hygiene: HTTPS usage, console errors, deprecated APIs, and similar technical standards. Agentic browsing covers how far AI assistants can understand and interact with the site, which sits beside Core Web Vitals work rather than replacing it.

The useful claim is runtime evidence. The agent is not inventing a checklist from file names. It triggers Lighthouse against a page that is actually visible in Chrome, including local development servers and HTML opened through the file:// protocol. Staging URLs count the same way. A coding agent can verify a UI change on localhost before anyone merges, which is where agencies often lose days when accessibility and technical SEO fail only after client UAT.

Local, staging, and file:// support for Chrome DevTools agents

Chrome states that the agent can audit any page visible in the browser. That includes local development servers and local HTML files. For agency teams, that means you can run a Lighthouse AI agent against a feature branch without waiting for a public staging hostname. Keep authentication and feature flags in mind: a logged-in staging route can look healthy while the anonymous production path still fails SEO or accessibility checks.

Chrome also warns about browser behaviour during audits. The page may resize or reload while Lighthouse simulates different devices. Anyone pairing an agent with a shared staging tab should expect brief disruption. Treat agent audits as intentional lab sessions, not something you leave running on a client demo screen without warning.

Prompts for a Lighthouse AI agent: accessibility, SEO, and best practices

Chrome’s examples are short enough to paste into a coding agent that already has DevTools agent tooling. They map cleanly to delivery habits agencies already use. Keep the prompt, the failing audits, and the re-run result in the ticket so the fix is reviewable after the chat window closes.

How to improve accessibility with a Lighthouse AI agent

Prompt: “How can I improve accessibility on this page as measured by Lighthouse?” The documented behaviour is a mobile formFactor audit that surfaces issues such as insufficient colour contrast or missing ARIA labels, then proposes concrete code fixes. That pass earns its keep when a designer ships a new badge colour that still looks fine to sighted reviewers on a calibrated monitor. Ask for the failing audit IDs in the pull request so review does not depend on chat history alone.

How to catch technical SEO blockers before launch

Prompt: “According to Lighthouse audit, how can I improve this page for better discoverability in search?” The agent looks for missing meta tags, canonical links, or weak descriptive text and can offer source updates. Catching those blockers in staging is cheaper than explaining a soft indexing story after launch. Pair the audit with the templates that matter commercially (product, pricing, checkout), not only the marketing homepage the agent happens to have open.

How to validate best practices on local and staging

Prompt: “Does my site follow best practices as measured by Lighthouse?” The audit reviews HTTPS, console errors, and deprecated API calls. Agencies often skip this pass because the design looks finished. Console noise and mixed content still show up in client QA and burn trust in the report pack.

When to run a full mobile and desktop Lighthouse audit

Prompt: “Run a full Lighthouse audit of my site, in mobile and desktop, and suggest improvement areas and possible fixes for any problems you find.” Chrome notes that agents with source context may suggest code fixes, and agents with broader context may also suggest server or backend configuration changes. Treat backend suggestions as hypotheses for your platform team, not as automatic production changes. Re-run after the patch so the conversation ends on measured results, not on a single hopeful pass.

None of these prompts invents a new quality bar. They attach an existing Lighthouse run to the agent’s conversation so the next patch is grounded in failing audits rather than guesswork. If the agent cannot see the page in Chrome, fix the browser connection first; no prompt compensates for an empty viewport.

Lighthouse agentic browsing versus Core Web Vitals reporting

Agentic browsing is the category that often confuses stakeholders. It is not another 0–100 Performance score. It asks whether assistants can understand and interact with the page: tool registration patterns such as WebMCP, agent-oriented accessibility, layout stability that affects programmatic clicks, and related discoverability signals. We already covered how experimental Lighthouse agentic browsing scoring works, including fractional pass ratios and WebMCP observation, in Lighthouse Agentic Browsing: How to rank in chatbots.

For agencies, the operational rule is simple. Keep Core Web Vitals and PageSpeed Performance scores as the client-facing performance language you already report. Use agentic browsing audits as an early research signal when a product site exposes agent tools or when a client asks whether AI assistants can use their flows. Do not promote experimental pass ratios into a retainer KPI until the standard and your tooling story are stable. Chrome’s agent docs put agentic browsing in the same Lighthouse family as accessibility and SEO, which is correct for developers, but buyers still buy predictability on Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift first.

If you need the math behind how Lighthouse turns raw timings into a Performance category score, Chrome documents the scoring model, and we have a dedicated Watcher explainer scheduled for that calculation path. The agency takeaway for agent workflows is narrower: a coding agent can improve category scores by fixing the failed audits it sees, but those lab scores are still synthetic. Field Core Web Vitals remain a separate truth.

Why one AI coding agent Lighthouse run is not portfolio monitoring

A successful agent session looks like this: open the priority URL on staging, run accessibility and SEO audits, apply fixes, re-run, then merge when the failures that blocked the ticket are cleared. That loop is useful. It is also a single device, a single URL, a single moment in time, and usually a single human watching the tab.

Agency failure modes live elsewhere. A plugin update lands on Friday across twelve WordPress sites. A Shopify theme ships a new app block that only hurts mobile Interaction to Next Paint on product templates. A marketing team adds a tag manager container that never appears on the developer’s localhost build. Spot PageSpeed Insights runs and agent audits both miss that class of regression unless someone remembers to re-check every affected URL after every change. We unpacked when manual checks stop scaling in PageSpeed Insights vs Automated Monitoring: When Manual Checks Aren't Enough.

Synthetic versus field data adds another split. Agent-driven Lighthouse is synthetic lab evidence, closer to a controlled PageSpeed Insights run than to Chrome UX Report percentiles. Knowing when to lean on lab schedules versus real-user monitoring is a separate decision; see When to Use Synthetic vs Real User Monitoring for Performance. Use the agent to fix what is broken in the environment you control, then keep scheduled synthetic tests on production priority URLs so regressions after merge still raise an alert.

How agencies combine Chrome DevTools agents with scheduled PageSpeed monitoring

A practical split that matches how delivery teams already work:

During build. Use a Lighthouse AI agent on local and staging for accessibility, technical SEO, best practices, and optional agentic browsing when the product exposes agent tools. Paste Chrome’s example prompts and keep the failing audit list in the pull request.
At release. Re-run the same priority templates on the staging hostname the client will accept, still with the agent or a manual Lighthouse pass if the agent tooling is unavailable.
After release. Rely on scheduled PageSpeed Insights or Lighthouse runs across the portfolio, with budgets and alerts on the URLs that earn revenue or retention. That is the layer Apogee Watcher is built for: multi-tenant schedules, history, and client-ready reporting without asking a developer to babysit Chrome tabs.

Layer, do not replace. Coding agents do not remove the need for continuous monitoring any more than Lighthouse CI removes the need for field Core Web Vitals. They shorten the time from “UI changed” to “measurable defect named.” Monitoring shortens the time from “production changed” to “someone on the account knows.” If you want a fast baseline before you wire schedules, run a free domain PageSpeed check to see multi-page lab results for a hostname. When you are ready to put priority URLs on a recurring cadence, follow Getting Started with Apogee Watcher: A Step-by-Step Setup Guide.

Common mistakes with Chrome DevTools agent Lighthouse audits

Treating a green agent pass as production proof

Local data, auth walls, and feature flags differ from what real users and the Chrome UX Report show. A clean mobile audit on staging can still leave desktop production amber on Interaction to Next Paint. Ship the fix, then confirm on the production URL with the same device form factor you care about in the retainer report.

Auditing only the homepage

Agents will audit whatever page is loaded. Homepages are convenient and often wrong for ecommerce and SaaS work. If checkout, pricing, or login is where money and trust live, load those routes before you ask for a Lighthouse AI agent run.

Ignoring audit disruption on shared environments

Resize and reload behaviour can interrupt demos and live editing. Chrome documents that Lighthouse may change viewport size while simulating devices. Schedule agent audits the same way you schedule Lighthouse CI: on purpose, not mid-call with a client watching the same tab.

Confusing Lighthouse agentic browsing with SEO rankings

Agentic browsing audits help you understand assistant interaction readiness. They are not a substitute for crawlability, content quality, or Core Web Vitals programmes you already sell. Keep the category in research notes until you and the client agree what a pass ratio means commercially.

Skipping history after the coding agent finishes

An agent conversation disappears when the chat ends. Agencies need trend lines and budget breaches stored against the site record. Without history, last week’s “we fixed contrast” claim is hard to prove in a monthly review, and the next developer repeats the same audit from scratch.

FAQ

Does a Lighthouse AI agent replace PageSpeed Insights?No. The agent uses Lighthouse categories in a developer workflow inside Chrome. PageSpeed Insights remains a common lab entry point for stakeholders, and scheduled PageSpeed Insights or Lighthouse API runs remain how you watch many URLs over time. Use the agent to fix; use monitoring to watch. For the wider comparison of spot checks versus automation, see our PageSpeed Insights versus automated monitoring guide.

Can coding agents audit pages that are not on the public internet?Yes, within Chrome’s stated support: any page visible in the browser, including local servers and file:// HTML. That is one of the strongest reasons to use agents during build rather than waiting for a public staging URL. Confirm the same checks later on the hostname clients and crawlers actually hit.

Should we report agentic browsing scores to clients every month?Only if you have agreed what the category means and how experimental it still is. Most retainers should keep leading with Core Web Vitals and clear lab Performance trends, then mention agentic browsing when a product roadmap or assistant integration makes it relevant. Point curious clients at the agentic browsing scoring explainer before you put pass ratios on a dashboard.

Where do budgets and alerts fit if developers already run agent audits?Budgets and alerts cover the gap after merge: unexpected third-party tags, plugin updates, and content changes that never open a coding agent session. Agent audits reduce defects entering the branch. Monitoring reduces defects lingering in production unnoticed. Set budgets on the same priority URLs you used in the agent session so the definition of “good” does not drift between tools.

Chrome DevTools for agents makes Lighthouse a first-class tool in coding-agent workflows. Accessibility, SEO, best practices, and agentic browsing can be measured on the page under change, including local and staging hosts. Agencies win when they adopt that loop for delivery quality and keep scheduled, multi-site PageSpeed monitoring for everything that happens after the pull request merges. Start with Chrome’s documented prompts on your next UI branch, then put the same priority URLs on a schedule so the fix stays fixed.

Lighthouse 100: Custom PHP vs WordPress vs Shopify

Mon, 13 Jul 2026 07:45:45 +0000

?>

Lighthouse 100: Custom PHP vs WordPress vs Shopify

April 2026 12 min read

I’m Jacob Campbell, and a perfect Lighthouse score isn’t luck — it’s the natural result of shipping only the code a page needs. A custom PHP site routinely loads in around 0.6 seconds and scores 100; the same content on a plugin-heavy WordPress or app-laden Shopify theme often lands at three to four seconds. Here’s how Lighthouse actually scores performance, why the platform gap is so wide, and what it takes to reach 100.

Your platform choice is the largest variable. Let’s prove it with hard numbers.

Breaking Down the Numbers – Why Such a Gap?

When Lighthouse CI maintenance in CI/CD pipelines becomes a second job

Sat, 04 Jul 2026 08:27:36 +0000

Performance budget gates in GitHub Actions are free until someone owns twelve client workflows, Chrome drift, and client reporting. How agencies split Lighthouse CI from managed PageSpeed monitoring.

The Slack thread started with a screenshot of a green GitHub Actions run. By the third reply someone had pasted a Lighthouse JSON artefact, a link to a Chrome release note, and a question nobody wanted to own: "Which client repository still pins Lighthouse 10?"

That is the week Lighthouse CI stopped being a merge gate and became a second job. The pipeline still passed and the portfolio still needed evidence, but the difference was who paid in hours: the developer shipping a feature, or the one person who inherited every lighthouserc file across client repositories.

When does Lighthouse CI maintenance outgrow a CI/CD pipeline?

Lighthouse CI earns its place early. You wire assertions on a preview URL, block a CLS regression, and the team trusts the red build. The cost is front-loaded configuration, not ongoing calendar time.

The shift happens when success creates obligations a CI/CD pipeline was never designed to carry:

Every new client repository needs a copied workflow, pinned Chrome, and preview URL rules that match their host.
Assertions need tuning after flaky LCP on cold runners, so thresholds loosen until they barely catch real regressions.
Account managers ask for client-ready reports, and the only export is a CI/CD artefact someone must turn into slides.
Production URLs outside the two preview paths regress while the job stays green.

At that point you are not "running Lighthouse CI in a pipeline." You are operating a small internal product: version pins, runner hygiene, assertion policy, and reporting glue. For a single product team that can be fine. For an agency portfolio it competes with billable delivery.

How do you know Lighthouse CI in CI/CD became an unpaid side role?

We treat these as signals to shrink CI/CD scope or add a managed monitoring layer, not as moral failure. Teams hit them around five to fifteen client sites, sometimes sooner when preview hosts differ wildly.

Flaky Lighthouse CI runs on GitHub Actions

Engineers merge after the third "Re-run failed jobs" click because INP moved six points on a shared runner. When the gate is noise, people route around it.

@lhci/cli and Lighthouse version drift across repositories

One repository uses @lhci/cli 0.13, another 0.14, Lighthouse 11 on one client and 10 on another. Nobody can say which assertion set is authoritative without opening six pull requests.

Preview URL versus production: green CI/CD, red PageSpeed Insights

The CI/CD job guards / on a Netlify preview while production serves /checkout from a different CDN rule. Sponsors see red on PageSpeed Insights; developers point at a green pipeline run and both sides are partially right.

Lighthouse CI artefacts instead of client-ready performance reports

Monthly retainers need a short narrative: which URLs broke budget, when, and what changed. If the answer lives in downloaded JSON and a manual chart, someone is doing monitoring work outside the pipeline, unpaid.

One engineer as the default Lighthouse CI maintainer

One senior developer becomes "the Lighthouse person," fixes workflows between client calls, and resents every Chrome update. That is a job description, not a YAML tweak.

If three or more patterns sound familiar, Lighthouse CI is already a second job. The fix is not deleting the pipeline check. It is deciding which hours belong in merge protection and which belong in scheduled monitoring with client-ready output.

Which performance budget checks should Lighthouse CI enforce in CI/CD?

We keep the CI/CD slice thin on purpose. Merge protection should answer a narrow question: did this candidate build break budgets on the one or two preview URLs we trust for this repository?

Keep as errors when the check is stable and the developer on the pull request can fix the cause:

CLS on in-scope templates where layout is the likely regression.
Bundle or script byte ceilings when the build exposes an artefact.
Total blocking time or main-thread proxies when the change touches JavaScript entry points.

Warn, do not block, when preview parity is weak: cold CDN LCP, ads on staging, INP without enough repetitions to trust a median.

Do not ask CI/CD to replace production monitoring: field CrUX exports, full sitemap crawls, rank proxies, or every revenue template on every docs-only commit. Those checks belong on a schedule against production URLs, with alerts that account managers can forward.

The wiring patterns, assertion keys, and GitHub Actions sketch live in our step-by-step guide: How to set up performance budgets in CI/CD pipelines. Use that guide to implement a small gate; use the criteria above to decide how small.

Lighthouse CI versus managed monitoring: why agencies hit build-versus-buy pressure early

Lighthouse CI is open source and runner-native, which makes it the default first step. Managed PageSpeed monitoring adds invoice line items, which makes teams delay the decision until the hidden invoice arrives: senior hours spent keeping workflows honest.

The build path scales poorly across repositories because CI/CD is repository-centric and agencies are portfolio-centric. Copying configuration per client multiplies drift. Preview URL changes when a client moves hosts. Authentication on staging breaks collection until someone scripts login. Each exception lands on the same maintainer.

The buy path trades some control for repetition: scheduled lab runs across many URLs, history, thresholds shared with client reports, and alerts when production templates cross budget. It does not replace merge gates on preview; it absorbs the work a pipeline should never have carried: full URL lists, post-deploy cadence, and evidence sponsors can read without terminal access.

We wrote the comparison for agency leads evaluating that trade explicitly: Lighthouse CI versus managed monitoring: build versus buy for agencies. The headline question is not "free versus paid." It is whether your team wants to operate monitoring infrastructure or operate client sites.

How to shrink Lighthouse CI scope in CI/CD pipelines without losing merge protection

When CI/CD became a second job for us, the recovery plan had four moves. None required removing Lighthouse from the pipeline entirely.

Limit Lighthouse CI to two preview URLs per client repository

Two preview paths maximum on small retainers: homepage plus one revenue or app-shell template agreed in the statement of work. Everything else lives in scheduled monitoring.

One performance budget document for CI/CD gates and client reports

Copy numbers from the same budget document monitoring uses. If CI/CD gates and the client report disagree on thresholds, engineers ignore both.

Demote flaky LCP to warnings; keep CLS and bundle size as errors

Demote flaky LCP to warnings until preview matches production behaviour on paper. Keep CLS and bundle ceilings as errors people act on.

Document pre-merge CI/CD versus post-deploy monitoring in the README

CI/CD answers pre-merge; monitoring answers post-deploy. Write that split in the repository README so account teams stop asking the pipeline to prove checkout on Friday's release.

Layer managed monitoring beside the CI/CD job rather than inflating YAML until every pull request waits ten minutes on Chrome. Multi-tenant monitors exist precisely because portfolio evidence does not belong inside each client's GitHub Actions bill.

Lighthouse CI in CI/CD versus scheduled PageSpeed monitoring: agency split for one repository

For a typical agency client on a modern JavaScript stack, we aim for under ten minutes of CI/CD web performance time and zero manual JSON exports per month.

Phase	Tooling	Question
Pre-merge	Lighthouse CI plus one bundle guard	Did this branch regress CLS or script weight on the two preview URLs in scope?
Post-deploy	Scheduled PageSpeed monitoring	Are production templates still inside budget on the cadence we promised?
Reporting	Monitoring product export	What do we send the sponsor without opening a terminal?

Green in CI/CD and red in the Friday report means the split failed, not that someone lied. Either preview parity is wrong, the URL list in monitoring is right and the pipeline was too narrow, or the regression shipped through a path CI/CD never watched. All three are operational fixes, not reasons to add a fourth Lighthouse run on every push.

Audit Lighthouse CI maintenance before you copy the workflow to another client

Pick the client repository where the CI/CD job failed most often last quarter. Answer honestly:

Who last updated lighthouserc and the Chrome pin?
How many hours went to flaky re-runs versus feature work?
Which production URL regressed while the pipeline stayed green?
What did the sponsor receive that was not a raw artefact?

If the maintainer has a name and the sponsor answer is "a screenshot from PageSpeed Insights," you already have a second job. Implement the thin CI/CD template from performance budgets in CI/CD pipelines, then read Lighthouse CI versus managed monitoring before copying the workflow into client seven.

Merge gates should block merges you would roll back. Everything else belongs on a schedule, with owners, on the full URL list the retainer names.

Originally published on Hashnode.

Coder Legion - Recent posts tagged lighthouse

When should you lazy load images (and when does it hurt LCP)?

Three checks before you lazy-load an image

When lazy loading images helps bandwidth without hurting LCP

When loading="lazy" hurts Largest Contentful Paint

CMS and theme traps that lazy-load the hero

Quick verify: lab LCP element after a lazy-loading change

FAQ

CTA

References

Brotli compression is on: why is PageSpeed / LCP still slow?

Confirm Brotli is actually on the critical path

Why Brotli can leave Largest Contentful Paint unchanged

When enabling Brotli makes PageSpeed Insights worse

What to fix next when the LCP element is not a text file

How agencies verify compression and LCP across a client portfolio

FAQ

CTA

References

Why is PageSpeed Insights worse than my local Lighthouse score?

Same Lighthouse engine, different machines

Why Total Blocking Time jumps on PageSpeed Insights

Local pollution: extensions, cache, and warm state

Do not mix PageSpeed Insights field data with local lab

How to compare fairly (and what to trust for client work)

FAQ

What to do next

References

How to set performance budgets that CI and clients both keep

Why CI budgets and client budgets drift apart

One threshold language both sides keep

The demo → retained budget ritual

What stays in CI versus what stays on production schedules

FAQ

CTA

References

Google Lighthouse Score Explained: How Scoring Works

What a Lighthouse Performance score actually is

How Lighthouse records lab metrics in a controlled run

How Lighthouse calculates the 0–100 Performance score

Lighthouse scoring weights (Lighthouse 10)

Worked example: from metric scores to a Performance number

Why the Performance score is not the same as Core Web Vitals field data

Mid-article check: run the URL you are arguing about

Why Lighthouse scores fluctuate between runs

How agencies should report Lighthouse scores to clients

Where Apogee Watcher stores Performance scores

FAQ

References

How to increase PageSpeed/performance of a website that makes heavy use of interactive maps?

Why do interactive maps hurt PageSpeed scores more than static images?

Which Core Web Vitals break first on map-heavy pages?

How should you defer map JavaScript until the user shows intent?

What placeholder and container rules stop layout shift?

How do tile weight and imagery affect Largest Contentful Paint?

Why do pan and zoom show up as Interaction to Next Paint problems?

When should the map leave the critical path entirely?

How do you monitor map pages after you ship?

FAQ

What to do next

References

How we tuned apogee.lu for a 95 mobile PageSpeed score

What PageSpeed Insights showed before we changed anything

How we used Watcher domain reports before touching CSS

How we found the real Largest Contentful Paint bottleneck

Moving assets to our CDN and reordering the document head

Hero images and fixed heights per breakpoint

CSS and fonts: what we tried and what we kept

Scores after deploy and what Summary showed next

What we monitor now

FAQ

References

How Lighthouse Performance Scores Are Recorded and Calculated

What a Lighthouse Performance score actually is

How Lighthouse records lab metrics in a controlled run

How Lighthouse calculates the 0–100 Performance score

Lighthouse scoring weights (Lighthouse 10)

Why the Performance score is not the same as Core Web Vitals field data

Why Lighthouse scores fluctuate between runs

How agencies should report Lighthouse scores to clients

When `loading="lazy"` hurts Largest Contentful Paint