Every check I run starts on the actual hostname, with caching behavior that resembles what a returning visitor sees, and with both desktop and mobile profiles. Mobile is not a shrunk desktop. It is a different CPU budget, a different network, and often a different failure mode. If you only test on a MacBook plugged into ethernet, you are optimizing for your own comfort.
\n\nI care about perceived speed first. Does the main message show up quickly? Does the layout jump while fonts and images arrive? Can a human tap the primary action without waiting for a hydration pass to finish? After that I care about the lab metrics because they give us shared vocabulary with search engines and with your marketing team when they ask reasonable questions.
\n\n- [ ] PSI mobile + desktop saved with URL\n- [ ] CrUX field section checked\n- [ ] 404 + redirect hop audit\n- [ ] Contact form on real deviceLargest Contentful Paint tells me whether the hero or primary content shows up in a reasonable time. It is not perfect—single-page apps can game it—but when LCP is bad, users notice. Interaction to Next Paint and Total Blocking Time tell me whether JavaScript is hogging the main thread. A site that paints fast but ignores taps for two seconds is still broken.
\n\nCumulative Layout Shift is where trust dies quietly. If your call-to-action moves because an image loaded without reserved space, you are training people not to click. I reserve aspect ratios, set dimensions on media, and avoid injecting banners above content that was already on screen.
\n\nDocument weight still matters. I open the network panel and look at the HTML document, the critical CSS, the first JavaScript chunk, and the largest image. WordPress marketing sites with twelve plugins are a useful comparison when a client is migrating. They are not a moral victory; they are a baseline for how much junk used to be normal.
\n\nI run Lighthouse from the command line against production, usually desktop and mobile profiles, and I save the JSON. I do not quote a single “performance score” in a proposal unless the client explicitly wants that language. Scores move when Google changes weights. The underlying audits matter more: render-blocking resources, unused JavaScript, image delivery, cache lifetimes, font loading.
\n\nWhen I publish a screenshot on my own site, it is from a run I can point to on briancrabtree.me with a date attached. If the number is not reproducible, it does not go on the marketing page. That policy keeps me honest and keeps you from defending a chart you cannot explain six months later.
\n\nFor the full ordered audit I run on React marketing sites — lab vs field, LCP head order, crawl HTML, INP — see Website Performance Audit Checklist (2026). When PSI lab and CrUX field disagree, start with Lab vs Field Data in PageSpeed Insights: When a 100 Score Still Fails Core Web Vitals.
\n\nField testing still happens. I scroll on a phone. I submit forms. I navigate away and back. I throttle the network in DevTools when I need to reproduce a complaint. Lab data finds regressions; field behavior tells you if you fixed the right thing.
\n\nThe order is predictable. Kill render-blocking surprises on the critical path. Resize and compress hero media. Split code so routes only download what they need. Defer non-critical scripts. Fix layout shift on the header and primary CTA. Then chase long-tail issues like third-party embeds and chat widgets clients insist on adding after launch.
\n\nCopy is part of performance. A page that loads in a second but makes visitors guess the next step is slow in the only metric that pays rent. I treat unclear headlines and buried contact paths as conversion defects, not copy quibbles. Sometimes the best performance win is removing half the carousel nobody clicked.
\n\nYou get a short written summary: what I measured, what changed, what improved, and what still depends on your content choices. If we set up analytics, you get event names that map to real CTAs—not a generic “user engaged” blob. You get deploy notes that mention cache headers and image formats so your team does not undo the work on the first blog upload.
\n\nI do not hand you a mystical “98% quality” label. I hand you a site that responds when tapped, a network waterfall you can read, and a repeat pass you can run after your next content push. If that pass regresses, you know where to look.
\n\nPerformance is not a one-time checkbox. The next marketing upload, the analytics snippet someone pastes into the header, the chat widget sales wants on every page—each one can undo a week of careful splitting. I document which third-party scripts are allowed, where images should live, and what format to use so your team does not accidentally ship a four-megabyte PNG as a hero. When a client keeps me on retainer, regression checks are part of the rhythm: same URL, same profiles, compare to the last saved run.
\n\nThat discipline is why I prefer boring stacks. React and Vite are not magic. They are tools I can reason about when something regresses. WordPress can be fast too, but only if you stop treating plugins like free calories. The handoff note is where I say which category you are in and what rules keep you there.
\n\nWhen NDAs hide client names, performance outcomes are often the clearest proof left. Faster LCP on a marketing site. Lower script weight after a refactor. A contact flow that stops bouncing on mobile. Those are the stories I can tell without naming the logo.
\n\nIf you are evaluating me, run your own audit on briancrabtree.me and compare it to your current site. Then ask whether your vendor will let you reproduce their before-and-after the same way. If they will not, ask why. For a related angle I keep coming back to, see Why PageSpeed Scores Change Every Run (And What to Fix First).
","tags":["lighthouse","core-web-vitals","handoff","performance-audit"],"views":53}