![\"Line](\"/images/journal-inline-pagespeed-variance.webp\")
\n PageSpeed Insights runs Lighthouse in a controlled environment: emulated mobile or desktop, throttled CPU, throttled network, a cold-ish load profile, and a single pass through your page. That is useful. It is also not what every visitor experiences. Your real users arrive on different devices, cached assets, background tabs, and networks that have nothing to do with Google's default 4G profile.
\n\nWhen someone quotes \"we got 100 on mobile\" without linking to the run, ask which run. When a score drops twenty points overnight without a deploy, ask whether the lab conditions shifted before you ask whether the developer broke production. Lab data answers a narrow question: under this profile, right now, how does the page behave? It does not answer \"is my business fast for everyone forever.\"
\n\n// Same URL, two lab runs — LCP can shift seconds\n// Fix the LCP element, not the headline score\n
Several things move the performance number between runs on an unchanged site. Network timing jitter affects Largest Contentful Paint and Speed Index—a hero image that finishes at 2.4s on one pass and 3.5s on the next can swing the category score hard. Main-thread work from third-party scripts, analytics beacons, or edge security checks shows up inconsistently depending on when they execute relative to the measurement window.
\n\nLighthouse weights change over time. A score you saved six months ago is not comparable to today's score even if your byte count is identical. Total Blocking Time and Interaction to Next Paint can look fine on desktop while mobile still punishes you for JavaScript that hydrates too early. None of that means the tool is useless. It means treating a single integer as a permanent grade is sloppy engineering.
\n\nWhen I dig into a regression, I read the audits, not the headline number. LCP tells me whether the primary content—usually a hero image or headline block—shows up in time. Speed Index tells me how quickly the page visually fills in. TBT and INP tell me whether JavaScript is stealing the main thread before the page feels responsive. CLS tells me whether layout is stable enough to trust a tap target.
\n\nOn React single-page apps, the usual LCP culprits are predictable: hiding a prerender shell before the real hero paints, loading Firebase or grid chunks during the lab window, font preloads competing with the LCP image, and render-blocking CSS that arrives after module JavaScript starts. Fixing those does not require stripping the design. It requires respecting paint order and deferring work that is not on the critical path. That is the difference between a cosmetic perf pass and one that survives the next PSI run.
\n\nThe Chrome User Experience Report section in PageSpeed Insights is field data: real Chrome users over a rolling window. Low-traffic sites often see \"No Data\" there. That is not a failure. Google needs enough eligible Chrome visits to publish origin- or URL-level percentiles without leaking individual behavior. You cannot simulate CrUX with bots or synthetic monitors. You earn it with real traffic over time.
\n\nUntil field data exists, lab scores are the honest proxy—provided you publish them honestly. I treat CrUX as the long game and Lighthouse as the regression alarm. When a client has traffic, we compare both. When they do not, we still fix LCP and interaction before arguing about a badge in the footer.
\n\nMy order has not changed in years. Identify the LCP element and make sure it can paint early: preload the right image, reserve its space, do not hide a static shell before the React version is ready. Stop below-fold JavaScript from downloading during the first seconds—lazy routes help only if you also defer mounting the trees that pull Firebase and public API calls. Audit font loading: one critical face on mobile beats preloading every display weight. Then chase third-party scripts clients insist on adding after launch.
\n\nCopy is still part of performance. A fast page that hides the contact path is slow where it matters. I mention that because teams sometimes chase a green gauge while the offer stays buried. Fix paint first. Fix clarity second. Both show up in conversion.
\n\nOn this site I publish lab snapshots with links to the exact PageSpeed analysis used—not a cropped screenshot from a lucky run. If mobile is 100 today and 86 tomorrow, both numbers are true for their runs. The linked report lets a skeptical hire verify the audit trail. That policy costs ego and wins trust.
\n\nIf you are evaluating a vendor, ask for the PSI URL, the date, and the form factor. Run your own pass on the same hostname. Compare waterfalls. If they refuse, ask why. Performance proof should be reproducible the same way a deploy script should be rerunnable.
\n\nRun PageSpeed on briancrabtree.me and read the LCP breakdown. Open the mobile lab report we used when the homepage gauges were last updated. Read Website Performance Audit Checklist (2026) for the full ordered pass on React sites, and Performance Checks Before Handoff for how I document handoff. If you want the same discipline on your stack, send a brief with your URL and what feels slow—not the score you wish you had, the behavior you actually see.
","tags":["pagespeed-insights","core-web-vitals","lighthouse","react"],"views":69}