The Complete Website Speed Optimization Guide (Core Web Vitals)

Why Speed Is a Revenue Metric

Website speed directly affects conversion rate, bounce rate and search visibility, which makes it a revenue metric, not just a technical one. Every additional second of load time gives a visitor another chance to abandon the page.

Industry benchmark studies across ecommerce and lead-generation sites consistently show conversion rate declining as page load time increases past roughly two to three seconds, with the steepest drop-offs on mobile connections. This pattern holds across industries because it reflects basic human patience, not a quirk of any specific platform or audience.

Speed also compounds with advertising spend. A business paying for clicks through Google Ads or Meta Ads that lands visitors on a slow page is effectively paying to send traffic into a leaky funnel, since a meaningful share of that paid traffic bounces before the page even finishes rendering. Fixing speed often improves paid media return on ad spend without changing a single targeting setting.

Largest Contentful Paint (LCP)

Largest Contentful Paint measures how long it takes the largest visible element, usually a hero image or headline, to render on screen, and it should happen within 2.5 seconds for a good user experience.

LCP is most often dragged down by unoptimized hero images, slow server response times, render-blocking CSS or JavaScript, and late-loading fonts. Because LCP measures the largest element specifically, a single oversized banner image can single-handedly push an otherwise fast page into a poor score.

Fixing LCP usually starts with the server: reducing time to first byte through better hosting or caching, then addressing the render path by preloading the hero image, serving it in a modern compressed format, and eliminating unnecessary render-blocking resources above the fold. Fonts should be preloaded and set with font-display swap so text does not wait invisibly for a custom typeface to arrive.

Common LCP fixes ranked by impact

1. 1Improve server response time (hosting, caching, database queries)
2. 2Preload and compress the largest above-the-fold image
3. 3Eliminate render-blocking CSS and JavaScript above the fold
4. 4Use a CDN to reduce network latency for all visitors
5. 5Preload key fonts and set font-display to swap

Interaction to Next Paint (INP)

Interaction to Next Paint measures how quickly a page responds to a user's click, tap or keypress, replacing the older First Input Delay metric, and it should stay under 200 milliseconds for a good score.

INP problems almost always trace back to heavy JavaScript execution blocking the browser's main thread, whether from large frameworks, poorly optimized third-party scripts, or excessive DOM manipulation triggered by a single interaction. Unlike LCP, which is mostly about initial load, INP reflects ongoing responsiveness throughout the entire visit.

Improving INP typically means breaking up long JavaScript tasks into smaller chunks, deferring non-essential scripts like chat widgets and marketing pixels until after the page is interactive, and auditing third-party tags regularly since they are one of the most common hidden causes of poor responsiveness. Reducing unnecessary re-renders in JavaScript frameworks also meaningfully helps on interaction-heavy pages.

• Defer non-critical third-party scripts until after page load
• Break long JavaScript tasks into smaller chunks
• Audit tag manager scripts quarterly and remove unused tags
• Minimize unnecessary DOM updates triggered by user interactions

Cumulative Layout Shift (CLS)

Cumulative Layout Shift measures unexpected visual movement on a page, such as text jumping when an image loads late, and it should stay below 0.1 for a good experience.

CLS is almost always caused by elements without reserved space: images and videos missing width and height attributes, ads or embeds injected after the surrounding content has already rendered, and web fonts that swap in with a different size than the fallback font. Each of these causes visible content to shift after a user has already started reading or interacting.

The fix is consistently the same principle: reserve space in advance. Always specify explicit dimensions or aspect ratios for images and embeds, reserve a fixed height for ad slots even before the ad loads, and choose fallback fonts that closely match the metrics of the final web font to minimize the visual jump when it swaps in.

Image Optimization

Images are typically the single largest contributor to page weight, so converting to modern formats and serving properly sized files is often the fastest way to meaningfully improve load time.

Modern formats like WebP and AVIF compress images significantly smaller than older JPEG and PNG files at comparable visual quality, often cutting image weight by 30 to 60 percent with no visible difference to most users. Combined with responsive image sizing that serves a smaller file to mobile devices instead of scaling down a desktop-sized image in the browser, image weight can often be cut in half across an entire site.

Compression alone is not enough without correct delivery. Images should be served through a CDN with automatic format negotiation, sized to the actual display dimensions rather than the original upload size, and lazy loaded below the fold so the browser is not forced to download images the visitor may never scroll to see.

CDN and Cloudflare Configuration

A content delivery network serves cached assets from a location physically closer to each visitor, cutting the network latency that otherwise adds meaningful delay for anyone far from the origin server.

Cloudflare and similar CDN providers cache static assets like images, CSS and JavaScript at edge locations worldwide, so a visitor in another country is not waiting on a round trip to a single origin server. Beyond raw caching, most CDNs also offer automatic image optimization, minification, HTTP/3 support and DDoS protection bundled into the same service.

Configuration matters as much as adoption. A CDN set up with overly conservative cache rules, or one that is bypassed for dynamic content that could actually be cached, delivers a fraction of its potential benefit. Reviewing cache hit ratio and adjusting cache rules for static assets is one of the highest-return, lowest-effort speed projects most sites can undertake.

• Enable full-page caching for static or mostly static pages
• Turn on automatic image optimization at the CDN edge where available
• Enable Brotli or gzip compression for text-based assets
• Review cache hit ratio regularly and adjust rules for underperforming asset types

Caching Layers

A well-configured site should have multiple caching layers working together, from the browser to the CDN edge to the application and database, each removing repeated work the server would otherwise redo on every request.

Browser caching stores static assets locally so repeat visitors do not re-download unchanged files. CDN edge caching, discussed above, handles this for new visitors. Application-level caching, such as full-page caching or object caching for database queries, reduces the work the server does to generate each page in the first place, which matters enormously for content-heavy or database-driven sites like WordPress or ecommerce platforms.

The common mistake is treating caching as a single on/off setting rather than a layered system. A site can have a fast CDN but still feel slow on cache-miss requests if the application layer is doing unnecessary database queries on every page load, so a proper audit checks each layer independently rather than assuming one caching plugin solves everything.

Most performance problems we find are not exotic; they are a missing caching layer or an unoptimized image library that has quietly accumulated for years. Fixing the fundamentals in the right order almost always outperforms chasing the newest optimization trick.

Hosting Choices

Hosting sets the ceiling for how fast a site can possibly be, since no amount of front-end optimization compensates for a server that is slow to respond in the first place.

Shared hosting environments, where server resources are split across many unrelated sites, are the most common source of unpredictable slow performance, particularly for sites with meaningful traffic or database complexity. Moving to managed hosting built specifically for a platform, such as managed WordPress hosting, or to a scalable cloud provider, typically produces a noticeable and consistent improvement in server response time.

Geographic server location also matters if a CDN is not fully covering dynamic requests. A site hosted far from its primary audience will show higher latency on any request that cannot be served from cache, which makes hosting region selection a real, if often overlooked, performance decision.

• Avoid budget shared hosting for any site with meaningful traffic
• Choose managed hosting built for your specific platform where available
• Select a hosting region close to your primary audience
• Monitor server response time (TTFB) separately from front-end metrics

Lazy Loading Done Correctly

Lazy loading defers offscreen images and content until a visitor scrolls near them, but applied carelessly it can actually hurt performance by delaying above-the-fold content that should load immediately.

The correct pattern is to lazy load everything below the initial viewport while explicitly eager-loading the hero image and any other above-the-fold content, since that hero image is usually the Largest Contentful Paint element and lazy loading it directly damages LCP scores. Native browser lazy loading via the loading attribute handles most cases well without needing heavier JavaScript libraries.

Lazy loading also applies well beyond images: embedded videos, comment sections, and below-the-fold third-party widgets can all be deferred until they are near the viewport, reducing the initial JavaScript and network load a browser has to process before a page becomes interactive.

Performance Plugins and Testing Tools

Speed optimization should be measured with a mix of lab tools for controlled testing and field data reflecting how real visitors experience the site, since the two can tell meaningfully different stories.

Lab tools like Google PageSpeed Insights, Lighthouse and WebPageTest run controlled tests useful for diagnosing specific issues, while field data from Chrome UX Report or real-user-monitoring tools shows how actual visitors on varied devices and connections experience the site over time. Relying only on lab scores can mask real-world problems affecting mobile users on slower connections.

For platforms like WordPress, caching and optimization plugins can help significantly, but they are not a substitute for fixing underlying hosting or code issues, and stacking too many overlapping plugins often creates conflicts that hurt performance rather than help it. The most effective approach uses one well-configured caching solution alongside targeted fixes rather than layering multiple competing tools.

The Complete Website Speed Checklist

A complete website speed optimization project touches hosting, images, code and caching together, and the checklist below covers the full sequence most sites should work through.

1. 1Run a baseline test with PageSpeed Insights and WebPageTest to document current LCP, INP and CLS
2. 2Move off budget shared hosting if server response time (TTFB) is consistently slow
3. 3Set up a CDN with proper caching rules for static assets
4. 4Convert images to WebP or AVIF and compress appropriately
5. 5Add explicit width and height or aspect-ratio to every image and embed
6. 6Preload the hero image and critical fonts
7. 7Set font-display to swap for all custom web fonts
8. 8Defer or remove unnecessary third-party scripts and tracking pixels
9. 9Eliminate render-blocking CSS and JavaScript above the fold
10. 10Lazy load all offscreen images and embeds, but not the hero image
11. 11Enable browser caching headers for static assets
12. 12Enable a single well-configured caching plugin or layer, avoiding overlapping tools
13. 13Minify and combine CSS and JavaScript where appropriate
14. 14Re-test against the baseline and monitor field data over the following weeks

Key takeaways

• Website speed is a revenue metric, directly affecting conversion rate and paid media return on ad spend
• LCP is improved primarily through server response time, image optimization and removing render-blocking resources
• INP problems almost always trace back to heavy or poorly deferred JavaScript
• CLS is fixed by reserving space in advance for images, embeds and web fonts
• Modern image formats like WebP and AVIF, combined with a CDN, deliver some of the fastest wins available
• Caching should be treated as multiple layers (browser, CDN, application) rather than one setting

Frequently asked questions