How to improve website speed without guessing

The most expensive words in performance work are “it feels faster.” Start with a reproducible baseline instead — the site that flies on your laptop, on office Wi-Fi, with a warm cache, tells you nothing about a first-time visitor on a mid-range phone three networks away.

1. Define the pages and user journeys

Choose representative templates: home, article, product, search, login, and checkout. Include mobile traffic and the regions that matter. Record whether the test is cold or warm cache, authenticated or anonymous, and production or staging.

2. Gather field and lab evidence

Field data shows what real users experience. Lab tools provide a controlled trace for diagnosis. Track Core Web Vitals alongside business outcomes and server metrics.

• Largest Contentful Paint (LCP) measures when the main content likely becomes visible.
• Interaction to Next Paint (INP) measures responsiveness to user interactions.
• Cumulative Layout Shift (CLS) measures unexpected visual movement.

Also inspect time to first byte, request waterfalls, main-thread work, image sizes, cache headers, database time, and third-party scripts.

3. Diagnose the slow stage

For slow server response, inspect cache misses, application traces, database queries, external APIs, resource saturation, and geographic distance.

For slow LCP, break it into server delay, resource discovery, resource download, and render delay. A large hero image cannot load early if JavaScript discovers it late. A text LCP can wait on a font.

For poor INP, find long main-thread tasks, large JavaScript bundles, repeated rendering, and expensive event handlers. For CLS, reserve dimensions for images, embeds, and dynamic interface elements.

4. Apply high-impact changes

Prioritize changes tied to the evidence:

• Cache reusable HTML or data where correctness permits.
• Compress text responses and use modern protocols through the platform.
• Resize and compress images; prioritize the LCP image without lazy-loading it.
• Remove unused JavaScript and CSS; defer noncritical work.
• Preload only critical, confidently used resources.
• Reduce font files, weights, and blocking behavior.
• Delay or remove third-party scripts that do not justify their cost.
• Fix slow database queries before buying a larger server.

5. Test the change safely

Measure before and after under the same conditions. Check visual correctness, accessibility, analytics, and cache invalidation. Performance changes can cause stale content, broken personalization, missing events, or image-quality problems.

Release gradually when the platform supports it and monitor error rate and business outcomes.

6. Establish budgets

Set limits for JavaScript, CSS, fonts, images, third-party requests, and key timing metrics. Enforce them in review or deployment checks. Track field percentiles over time so a regression is visible before it becomes normal.

Continue with website caching and CDN strategy and image optimization.

Sources and further reading

• web.dev: Optimize Largest Contentful Paint
• web.dev: Interaction to Next Paint
• web.dev: Cumulative Layout Shift