Skip to content
RA — Rohit Agnihotri, home
Resume ↓

Performance · Techjockey · Shipped · 2 min read

Core Web Vitals sprint: page speed as experience

When Search Console starts flagging your pages, how do you fix page speed across a whole marketplace instead of one page at a time?

After Search Console flagged layout-shift and loading problems, I led a Core Web Vitals sprint with engineering that went through Techjockey's page templates in priority order (category, product, blog, home, compare, alternatives, reviews) on desktop and mobile. Performance scores rose from 50 to 90+ on desktop and from 40 to 85+ on mobile. This coincided with bounce rate falling from 45% to 32% and organic traffic growing 25% year on year.

At a glance

Mobile performance score
40 → 85+
Desktop performance score
50 → 90+
Bounce rate
45% → 32%
Organic traffic, year on year
+25%
Role
Product Manager · User pod lead
Context
Shipped at Techjockey
Format
Engineering sprint · 7 page templates
Stack
Lighthouse · PageSpeed Insights · Google Search Console · GA4 · Microsoft Clarity · GTM

The problem

Google Search Console started flagging Techjockey pages for layout-shift and loading problems, and a first fix didn't pass its validation. Before the sprint, performance scores sat around 50 on desktop and 40 on mobile, and 45% of visitors bounced. For a marketplace that depends on organic search, slow pages were costing visitors before they ever reached a product.

How I made the call

Six stages, from Search Console's flags to the result and what came next. The schematics are illustrative; every number on them is real.

  1. The flags started on mobile blog posts: Cumulative Layout Shift (CLS) jumped sharply and pages were marked as errors, while PageSpeed Insights showed Largest Contentful Paint (LCP) getting worse. A first fix failed Search Console's validation for both. Performance scores sat around 50 on desktop and 40 on mobile.

    Evidence

    Schematic

    Flags · before the sprint

    1. Search ConsoleMobile blog posts: layout shift (CLS) up sharplyError
    2. PageSpeed InsightsLoading (LCP) getting worseWorse
    3. Search ConsoleFirst fix: validation for LCP and CLSFailed

    Before the sprint

    Desktop performance score
    50
    Mobile performance score
    40
    Bounce rate
    45%

    The page drawing is illustrative, not a screenshot.

  2. Page speed isn't a backlog ticket. It's part of the experience, and it's set by templates, not individual pages. Fixing one blog post at a time wouldn't scale; fixing the template behind a page type fixes every page built on it. So the sprint was organised by template, not by page.

    Reframe

    Schematic

    Page by page

    One blog post fixed

    One page better. Doesn't scale.

    Template by template

    The template behind the page type

    Every page built on it.

    Speed is part of the experience, set by templates

    Page counts are illustrative.

  3. The scoping ticket ranked seven page templates by importance: category, product detail, blog, home page, compare, alternatives and review pages. Each was in scope on desktop and mobile web, measured on CLS, LCP, FID, TTI and other metrics against a baseline taken at the start.

    Prioritisation

    From the spec
    1. P1Category pages
    2. P2Product detail pages
    3. P3Blog pageswhere the flags were
    4. P4Home page
    5. P5Compare pages
    6. P6Alternatives pages
    7. P7Review pages
    Measured onCLSLCPFIDTTIand other metrics

    Against a baseline taken at the start · desktop and mobile web

  4. The flagged mobile blog posts came first, with a follow-up round when validation failed. Then the sprint went through P1 to P7 on desktop and mobile web, tracking scores alongside bounce rate and organic traffic. New templates were checked after launch too: the revamped category page's fix list included a layout-shift issue.

    How it ran

    Schematic

    1. 01Fix the flagged pages

      1. Mobile blog posts: CLS, LCP
      2. Validation failed
      3. Follow-up round

    2. 02Go template by template

      1. P1Category
      2. P2Product detail
      3. P3Blog
      4. P4Home page
      5. P5Compare
      6. P6Alternatives
      7. P7Reviews

      Desktop and mobile web. Scores tracked alongside bounce rate and organic traffic.

    3. 03Check new templates after launch

      1. Revamped category page
      2. Post-launch fix list
      3. A CLS issue
      4. Handled with the post-live changes

  5. Performance scores rose from 50 to 90+ on desktop and from 40 to 85+ on mobile. This coincided with bounce rate falling from 45% to 32% and organic traffic growing 25% year on year.

    Result

    To scale

    40 → 85+mobile performance score

    Desktop performance score

    Before
    50
    After
    90+

    Mobile performance score

    Before
    40
    After
    85+

    “+” scores are drawn at their floor: 90 and 85.

    Over the same period · coincided with the sprint

    Bounce rate
    45% → 32%
    Organic traffic, year on year
    +25%

  6. Later launches brought regressions back: product page scores were flagged as fluctuating, and a new About Us page shipped with LCP and CLS issues. So performance needs a standing release check, not a one-off sprint. Next came the stack: the P1 category template was taken up for a move to Next.js, and I opened a "Migration to Next.js" epic for the rest of the site.

    What came next

    Schematic

    Later launches

    • Product page scores flagged as fluctuatingRegression
    • A new About Us page shipped with LCP and CLS issuesRegression

    A standing release check, not a one-off sprint

    The next structural step: the stack

    1. P1 category template taken up for Next.js
    2. "Migration to Next.js" epic, across the site

What I took away

Page speed is part of the product, not a clean-up job. It's set by templates, so that's where to fix it, and every release can undo it, so that's where to guard it.

Want to talk through this?

Email me →Resume ↓