WordPress speed optimization that targets real users, not a lab score
A 100/100 Lighthouse score on your laptop is not the same as a fast site for a customer on mobile data in Trois-Rivières. We optimize for field Core Web Vitals — the numbers Google actually uses and your customers actually feel.
The score everyone chases is the wrong one
Lighthouse runs a simulated test on a simulated device. It's a useful diagnostic and a terrible KPI. What Google uses for ranking, and what correlates with your bounce rate, is field data — real Core Web Vitals from real visitors.
The three that matter:
WordPress's weak spot is LCP, not INP. Across the ecosystem, sites pass INP far more often than they pass LCP. If someone quotes you a lab score without showing you field LCP, they're optimizing the number that's easiest to move.
Fix TTFB first or nothing else matters
Time to First Byte is how long your server takes to start answering. Above roughly 400ms, front-end optimization is rearranging furniture in a burning building. You cannot lazy-load your way out of a slow server.
TTFB is governed by hosting quality, PHP version, object caching, database health, and full-page caching at the edge. That's the first thing we measure and usually the first thing we change.
Our order of operations
What we'll tell you honestly
A feature-rich WordPress site with background video, sliders and animation will not score 95 on mobile Lighthouse. Anyone promising that is either going to strip your design or show you a desktop number and hope you don't check.
What we commit to is passing field Core Web Vitals — LCP under 2.5s, INP under 200ms, CLS under 0.1 — because that's the threshold Google uses and the one your customers experience. On pages we're allowed to simplify, lab scores follow.