Website speed work should improve what real visitors experience, not merely raise a single lab score. The reliable sequence is measure, identify the limiting resource or interaction, change one controlled cause, and verify both technical and user outcomes.
Use two kinds of evidence: field data describes real visits over time; lab data reproduces a page under controlled conditions and helps diagnose causes. A page can have excellent lab results and insufficient or poor field data, or the reverse.
Know the three Core Web Vitals
| Metric | What it represents | Good threshold |
|---|---|---|
| Largest Contentful Paint (LCP) | How quickly the main visible content appears | 2.5 seconds or less |
| Interaction to Next Paint (INP) | How quickly the page responds visually to interactions | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | How visually stable the page remains | 0.1 or less |
The web.dev Web Vitals reference recommends evaluating these thresholds at the 75th percentile of page loads, segmented for mobile and desktop. They are experience indicators, not a substitute for task completion, accessibility, or content quality.
Step 1: create a representative test set
Do not optimize only the homepage. Choose templates that reflect actual traffic and technical patterns: homepage, category or hub, long article, image-heavy page, form, product or service page, and any page using a distinct framework. Test signed-out and signed-in experiences separately when both exist.
- Record device class, connection assumptions, geography, cache state, and test time.
- Capture field data where available and at least three comparable lab runs.
- Note third-party scripts, consent state, personalization, and experiments.
- Save the release identifier so a regression can be tied to a change.
Step 2: find the LCP resource and its delay
The LCP element is often a hero image, heading, poster, or large content block. Break its total time into server response, resource discovery, download, and render delay. Fix the largest avoidable segment rather than applying every generic recommendation.
- Reduce slow server work and redirect chains.
- Make the primary resource discoverable in initial HTML.
- Do not lazy-load an above-the-fold LCP image.
- Serve correctly sized modern images with explicit dimensions.
- Preload only truly critical assets; excessive preloads compete with one another.
- Remove render-blocking work that does not need to precede the main content.
Step 3: reduce interaction delay
Poor INP commonly involves long main-thread tasks, heavy event handlers, excessive rendering, or third-party code. Reproduce the slow interaction, inspect the event and resulting paint, then divide work so the browser can respond.
- Ship less JavaScript and defer features that are not needed for the initial task.
- Break long work into smaller tasks and avoid repeated layout calculations.
- Give immediate visual feedback when a legitimate operation takes time.
- Virtualize or paginate very large interfaces instead of rendering everything.
- Audit tag managers, chat tools, embeds, and testing scripts by business value and cost.
Step 4: stop unexpected movement
CLS problems occur when content shifts without a recent user action. Reserve space for images, video, ads, embeds, banners, and asynchronously inserted components. Avoid placing new content above what a person is already reading.
Web fonts can also alter layout. Use a deliberate loading strategy, compact font subsets, and fallback metrics that minimize reflow. A decorative font should not block basic reading.
Step 5: make network work intentional
| Area | Check | Evidence |
|---|---|---|
| Images | Dimensions, responsive sources, format, compression, lazy loading below the fold | Transferred bytes and visual comparison |
| CSS | Unused rules, blocking files, duplicate frameworks | Coverage report and render trace |
| JavaScript | Bundle size, long tasks, unused code, third parties | Execution time and interaction trace |
| Fonts | Subsets, weights, preload count, display behavior | Requests, timing, and layout shift |
| Caching | Versioned static assets and suitable cache lifetimes | Response headers and repeat-load waterfall |
Step 6: use PageSpeed Insights correctly
PageSpeed Insights can show Chrome User Experience Report field data when enough eligible data exists and Lighthouse lab diagnostics for a controlled run. Read the scope carefully: origin-level and URL-level field data are not interchangeable, and an absent field panel does not mean nobody visited the page.
Prioritize opportunities that correspond to the measured bottleneck and affect representative templates. A perfect score is not a product requirement. A stable, accessible page that helps the reader complete a task is the requirement.
Step 7: verify without creating a regression
- Compare the same page, device profile, and cache conditions before and after.
- Check visual quality, keyboard behavior, forms, analytics, consent, and business events.
- Deploy gradually when the platform supports it.
- Watch real-user metrics through a full reporting window.
- Record the result and revert a change that harms a more important outcome.
Speed belongs inside the broader new-site SEO launch process. Use Search Console to monitor search-facing experience reports and page performance, and apply the same mobile discipline to the local service-business checklist.