Case Study 2 — The Hundred-Point Trap: The Team That Chased a Perfect Score and Won Nothing

A complementary angle. Case Study 1 looked at Google telling everyone Core Web Vitals was minor. This one looks at a team that didn't listen — that treated a perfect PageSpeed score as the goal, spent months reaching it, and got nothing back but a green number. It teaches the chapter's limits from the failure side.

This is a labeled composite. It is not one named company; it is a pattern that plays out constantly, in agencies and in-house teams alike, and that Google's own representatives have warned against. Every number below is illustrative. What is real is the mistake — and how seductive it is.

Background: the score becomes the mission

A mid-size advice-and-how-to website — call it a home-and-garden content site with a few hundred articles and a respectable, if flat, stream of organic traffic — brings in a new manager under pressure to "improve SEO." Looking for something concrete and measurable to show progress, the manager runs the site through PageSpeed Insights, sees a lab performance score of 62 out of 100 on the key article template, and declares a mission: get every important page to 100.

It is an understandable choice. The score is a single, crisp number. It goes up when you work on it. It looks like a grade, and grades feel like progress. Leadership loves a chart that climbs. So the team spends the next four months on it: deferring and removing JavaScript, stripping out a helpful interactive calculator that was "too heavy," lazy-loading nearly everything, cutting an author-bio widget and a related-articles module because they added a few points of load, and hand-tuning the template until the lab score reads a glorious 99–100 on the developer's machine.

The issue: four ways the mission was aimed at the wrong target

Walk the project through this chapter and almost every decision is subtly off.

  • They optimized the lab score, not the field data. The 100 was a Lighthouse result — one synthetic run on a simulated device (§16.5). Nobody checked the CrUX field data. When they finally did, real users on real phones were seeing an LCP of about 3.1 seconds — "needs improvement," not "good." The lab and the field disagreed, and the team had been polishing the wrong one for four months.
  • They chased the maximum, not the threshold. Even in the lab, the journey from a decent result to a perfect one (§16.7) delivered essentially no ranking value. The meaningful move — poor/needs-improvement to good — could have been reached in a fraction of the time.
  • They sacrificed content and function for points. The interactive calculator they deleted was one of the page's best features — the thing that actually helped readers and earned links. The author-bio widget was an E-E-A-T signal (Chapter 5). They traded reasons to rank for milliseconds, which is exactly backwards.
  • They never touched the real problem. Traffic was flat because the articles didn't match search intent as well as competitors' and the site had thin topical coverage (Chapters 3, 4, 8). No amount of speed work addresses that. The genuine bottleneck sat untouched for four months while the team optimized a tiebreaker.

text FIGURE 16.5 — "Four months, one green number, zero traffic" [constructed teaching example] BEFORE AFTER FOUR MONTHS RESULT Lab score 62/100 Lab score 99/100 Leadership thrilled by the chart Field LCP ~3.1 s (unchecked) Field LCP ~3.0 s (barely moved) Real users no better off Calculator + bio present Calculator + bio DELETED Lost a linkable asset + E-E-A-T signal Organic traffic: flat Organic traffic: still flat No ranking gain; possible small loss Intent/content gap: unaddressed Intent/content gap: unaddressed The actual problem, still there (All figures illustrative — the SHAPE, effort spent on the wrong target, is the lesson.)

What it shows

This is the mandated myth of §16.7 — "a perfect 100 PageSpeed score ranks you #1" — playing out as a slow- motion own goal.

  1. A lab score is not a ranking signal. The team's headline metric was a synthetic number Google does not rank on. The one that matters — field data — barely moved, because the real-world bottleneck (server response, real-device rendering) wasn't what they'd been tuning.
  2. Passing the threshold is the goal; perfection is vanity. The SEO value lives entirely in the poor-to-good transition. Grinding good-to-perfect is engineering effort with a near-zero ranking return — time that competitors spent on content.
  3. Speed is not free if you pay for it in content. Deleting the calculator and the author bio to save milliseconds removed genuine reasons to rank and cite the page. A fast page that is less useful than it was can rank worse, not better. Never trade relevance, functionality, or E-E-A-T for a score.
  4. Opportunity cost is the real bill. The four months were not free even if the site had lost nothing directly. They were four months not spent on intent, coverage, and links — the levers that actually move rankings. The most expensive part of chasing the wrong metric is everything you didn't do instead.

Outcome

In the honest version of this story, someone eventually opens the field data, sees that real users are merely "needs improvement," realizes the perfect lab score was a mirage, and — worse — notices the deleted calculator has cost the page a slow trickle of the links it used to earn. The team resets: they restore the calculator (reserving space for it so it doesn't wreck CLS), do the actual high-leverage speed fix (page caching and a CDN to cut the real-user TTFB, which finally drags field LCP under 2.5 s), pass the threshold in about two weeks, and then — crucially — stop, and redirect their remaining time to the content and intent work that was the real problem all along. Rankings begin to move only once that content work lands, months later, and the speed fix contributes a modest tailwind rather than the miracle it was cast as.

In the unfortunate version, the green "100" is presented as the SEO win, everyone moves on, and a year later the site is still flat and no one connects the dots.

The lesson

The score is a diagnostic, not a destination — and it is the wrong destination twice over. First, the 0-to-100 lab number is not what Google ranks on; the field data is. Second, even the field data is only a tiebreaker: passing the "good" threshold is worth doing for users and for the small ranking nudge, but maximizing it is vanity, and paying for speed with content is a net loss. The professional move is unglamorous: check the field data, make the cheap high-leverage fixes (caching, CDN, image sizing, explicit dimensions) until you clear the threshold, then put the tool down and go do the content and intent work that actually decides the contest.

Connect it to Rivertown. This is the trap the Chapter 16 Strategy File is built to avoid. Rivertown's measurement pass leads with field data, fixes the shared root causes to clear the threshold, and states in writing that speed will not solve the thin location pages or the local pack — those belong to Chapters 15 and 25. We fix the tiebreaker cheaply and keep our eyes on the real prize.


Discussion questions

  1. The lab score is genuinely useful for some jobs. Name one thing the Lighthouse 0-to-100 score and its "Opportunities" list are good for — and the one job it must never be used for.
  2. The team deleted a helpful calculator to save load time. Construct the argument they thought they were making, then rebut it using §16.7 and the idea of a "reason to rank."
  3. "Opportunity cost is the real bill." Estimate, in your own words, what four months of content and internal-linking work might have done for a flat site — and why that is hard to put on a chart that leadership likes as much as a rising score.
  4. How could this team have caught the lab-versus-field mistake in the first week instead of the sixteenth? Name the specific step in the PageSpeed Insights report they skipped.
  5. Suppose the field data had shown "poor" LCP. Would the four months then have been justified? Explain why "the metric was failing" still would not justify deleting content — and what the right sequence of fixes would have been.