THEO: The recipe blog spent weeks chasing a perfect 100 on PageSpeed, hit it, expected rankings to jump, and nothing moved. Before anyone calls that a failure, the disappointment is built on a measurement confusion. They optimized the rehearsal and expected applause for the performance.
ELENA: Unpack that, because “rehearsal” is going to sound like a dodge to the owner.
THEO: That 100 is mostly a lab score, one synthetic load in a controlled room. What actually feeds search signals is field data, the experience real users get on real phones. A perfect lab score and bad field data live together constantly.
ELENA: And on a recipe site the gap is brutal, specifically. The lab loads the page once, clean, no variables. The field is slow phones, spotty networks, and the stuff the lab never triggers, the ad script that fires on real loads and delays the main content, that’s your Largest Contentful Paint suffering, images shifting layout as they arrive, that’s Cumulative Layout Shift, a heavy script tying up the page when someone taps, that’s Interaction to Next Paint. Recipe sites are image-heavy and ad-supported, so they ace the lab and still load like a brick in someone’s kitchen.
HANNAH: Both of you are about to oversell how much this moves rankings, though, and I need to put a ceiling on it. Core Web Vitals are real, but modest, mostly a tiebreaker between pages of comparable relevance. Even if the blog had genuinely great field data, “rankings will jump” was never on the table. Speed isn’t worthless, I’m not saying that. I’m saying it’s a refinement on top of relevance, not a substitute for it.
MARCUS: Hannah’s ceiling is the polite version. I’ll say the blunt one, who decided speed was the bottleneck in the first place?
THEO: Meaning the whole project rested on an unchecked assumption.
MARCUS: Exactly. The blog assumed speed was holding it back and optimized it, but never confirmed that. Maybe the recipes are thin, maybe the space is crowded, maybe the titles don’t match how people search. Chasing 100 treated a symptom nobody diagnosed, which is precisely why a perfect score changed nothing. If speed was never the cap, the score was always going to do nothing.
SOFIA: And the thing worth fixing has nothing to do with rankings anyway. Picture the reader, phone propped up, floury hands, halfway through a recipe. A page that jumps as ad slots load, or stalls before the ingredient list shows, loses that person. So the real payoff of good field data isn’t a ranking bump, it’s the reader actually reaching the recipe. Reframe the goal from “score 100” to “the cook on the phone gets to the recipe fast and it doesn’t jump,” and you fix what counts.
NOAH: Which is the proxy trap in a fresh outfit. A round, gameable number stood in for a messy real goal, and the team maxed the number because watching it climb to 100 felt like winning. The tell is the perfect target itself, “we hit 100,” a score treated as the achievement instead of a rough gauge of something real.
AIKO: So watch the right dashboard, because they were monitoring the wrong one entirely. Not a one-off lab score, the field data, real-user Core Web Vitals over time, segmented to mobile since that’s where recipe traffic lives. Search Console’s Core Web Vitals report buckets your URLs into good, needs-improvement, and poor against Google’s own thresholds, so instead of chasing a number you watch which group your pages sit in and which metric is dragging them down. The lab tool is a diagnostic for finding fixable issues. The field data is the actual scoreboard, and they confused the two.
THEO: So the rule is the split I opened with. Optimize field data for users, use the lab tool only to surface concrete problems, then verify each fix in real-user data, because a fix that looks good in the lab and does nothing in the field isn’t a fix. And do Marcus’s check first, confirm performance was ever the ranking constraint, because a perfect score against the wrong bottleneck buys nothing.
DANA: Then here’s the decision, and it pulls apart two things the team fused. We don’t chase a lab score, and we don’t expect performance alone to move rankings, because Hannah’s right that it’s a tiebreaker, not a lever. We optimize what real users feel, tracked in field data, where a recipe site’s ad and image load makes the lab and the field disagree sharply. The lab tool only surfaces fixable issues, layout shift, render-blocking scripts, and we confirm each fix in real-user metrics. And before any further work here, we settle Marcus’s question, what’s actually capping these rankings, because that was never established. Caring about how fast the page feels is right, it matters for readers. Treating a lab score as the goal, and a fast page as a ranking lever, is the misread that made the work feel wasted.
SOFIA: That points the effort at the cook on the phone, instead of a number in a simulation she never sees.
DANA: A perfect score in a clean room means little if the kitchen is still slow. Fix what real users feel, and confirm speed was ever the thing holding you back.