A slow website costs you twice. Visitors leave before the page finishes loading, and the ones who stay find it harder to do what they came to do. If you want to make your website faster, the useful question isn’t “how many seconds does the page take?” It’s “which part of loading is slow, and what’s causing it?”

This guide to how to increase website speed works through that question in order. Confirm what good looks like, find out why your pages are slow, then fix the causes behind each of Google’s three Core Web Vitals.

What a good website speed looks like

Google defines good speed with three Core Web Vitals thresholds: Largest Contentful Paint (LCP) of 2.5 seconds or less, Interaction to Next Paint (INP) of 200 milliseconds or less, and Cumulative Layout Shift (CLS) of 0.1 or less, measured across at least 75% of real visits. For what each threshold measures and why a lab score differs from real-user data, see what a good website speed is.

Find out why your website is slow

Most speed work stalls because teams start fixing things before they know which metric is failing. Diagnose first.

What you can do: Run your most important page templates through PageSpeed Insights. It shows real-user data where Google has enough of it, plus a lab test for any page, for both mobile and desktop. Check mobile first, because slower phones and networks expose problems a desktop test hides. Then open the Core Web Vitals report in Google Search Console to see which groups of URLs fail and on which metric. The failing metric tells you where to look. A slow LCP points to loading, a poor INP points to JavaScript, and a high CLS points to layout. PageSpeed Insights also lists the specific resources behind each problem, which gives you a starting backlog.

Fix slow loading (LCP)

LCP measures how long the largest visible element, usually a hero image or a headline block, takes to appear. On most pages that element is an image, so images and server response are the usual reasons LCP is slow.

Size images for the space they fill

An image uploaded 4,000 pixels wide and displayed at 800 still makes the browser download every pixel. Print-style resolution settings such as PPI make no difference on screen. What matters is the image’s pixel dimensions and its file size.

What you can do: Export images at the largest size they’ll actually be displayed. Use the srcset and sizes attributes so phones download smaller versions than large screens do. Compress every image before it goes live.

Use modern image formats

AVIF and WebP usually produce smaller files than JPEG or PNG at similar visual quality, and current browsers support both. Animated GIFs are especially heavy. A short looping video file is usually far smaller than the same animation saved as a GIF.

What you can do: Serve AVIF or WebP with a JPEG or PNG fallback. Many CMSs and image CDNs convert formats automatically. Replace large animated GIFs with muted, looping video.

Lazy load what sits below the fold, but not the LCP image

Lazy loading tells the browser to wait to fetch images and iframes until a visitor scrolls near them. That cuts the work done during the first load. Applied to the hero image, it does the opposite and delays LCP.

What you can do: Add loading="lazy" to images and embeds below the fold. Leave the LCP image loading normally, and add fetchpriority="high" to it so the browser requests it early.

Cut server response time

No image fix helps if the server takes a second to send the first byte. Response time depends on your hosting, on how much work the server does for each request, and on the distance between the server and the visitor.

What you can do: Choose hosting sized for your traffic rather than the cheapest plan. Use a content delivery network (CDN) so files are served from locations close to each visitor. Turn on server-side caching so pages aren’t rebuilt on every visit, and set browser caching headers so returning visitors reuse files they’ve already downloaded. Remove redirect chains too. Every redirect adds a round trip before the page can start loading, so internal links should point straight at the final URL.

Stop CSS and fonts from blocking the first render

Browsers won’t show a page until they have the CSS needed to style it, and web fonts often arrive late.

What you can do: Inline the small amount of CSS the top of the page needs and load the rest without blocking. Serve fonts as WOFF2, limit the number of weights and styles you load, preload the one or two fonts used above the fold, and use font-display: swap so text appears in a fallback font while the web font loads.

Fix slow responses (INP)

INP measures how quickly a page responds when someone clicks, taps or types. Poor INP usually comes from JavaScript keeping the browser’s main thread busy.

Defer JavaScript the page doesn’t need right away

A standard script tag stops the browser from reading the rest of the HTML until the script downloads and runs. The async and defer attributes remove that block. An async script runs as soon as it arrives, in no fixed order. A deferred script waits until the HTML is parsed and runs in order.

What you can do: Use defer for most scripts, keep async for independent ones such as analytics, and load features like chat or reviews only when a visitor reaches for them.

Minify, compress and bundle with care

Minification strips whitespace, comments and unneeded characters from HTML, CSS and JavaScript. Compression with Brotli or gzip shrinks files further on the way to the browser. Combining files used to be standard advice because every HTTP request was expensive. HTTP/2 and HTTP/3 carry many requests over one connection, so a few well-sized bundles now beat one enormous file that makes visitors download code for pages they never open.

What you can do: Minify and compress everything you serve, confirm your server supports HTTP/2 or HTTP/3, and split JavaScript so each template loads only what it uses.

Audit third-party scripts, plugins and themes

Tag managers, chat widgets, testing scripts, social embeds and video players each add JavaScript you don’t control. On CMS-driven sites, plugins and heavy themes add more. A WordPress site running dozens of plugins is the familiar example, but every CMS collects the same weight over time.

What you can do: List every third-party script and plugin, give each one an owner, and remove the ones nobody can justify. Replace embedded video players with a lightweight preview image that loads the player only when clicked, and host video on a dedicated video platform rather than your own server. Clean up the CMS database on a schedule, removing old revisions and data nothing uses.

Break up long tasks

Any piece of JavaScript that runs for more than 50 milliseconds without a break stops the page from responding until it finishes.

What you can do: Ask developers to split long-running work into smaller chunks that hand control back to the browser, and to move non-urgent work out of click and input handlers.

Fix layout shifts (CLS)

CLS measures how much visible content moves unexpectedly while a page loads. Most of its causes sit in the markup, so the fixes are usually straightforward.

What you can do: Give every image, video and iframe width and height attributes so the browser reserves space before the file arrives. Reserve fixed space for banners and embeds that load late. Avoid inserting content above what a visitor is already reading, and use the font settings above to keep text from jumping when a web font loads.

Keeping a large website fast

On a site with thousands of pages, speed rarely breaks one page at a time. It breaks at the template, or when a new script ships to every page at once. Set a performance budget for each template, such as a maximum page weight and an LCP target, and check it before releases go live. Fix problems in the template so every page built on it improves together. Put third-party tags through a review so nothing reaches production without an owner. Then keep watching real-user data after each release, because lab tests miss what visitors actually experience. Continuous performance monitoring turns speed from a one-off project into part of how the site is run. Teams that already run an accessibility program can fold this into the same process, an approach covered in treating Core Web Vitals and WCAG as one system.

Where to start

Pick your three highest-traffic templates, run them through PageSpeed Insights, and fix the failing metric on each before moving to the next. On many sites, images, server response and third-party scripts account for the biggest gains. Speed is also one part of broader website optimization, not a substitute for it. Google’s own guidance on page experience in Google Search notes that good Core Web Vitals results don’t guarantee top rankings, so a fast page still has to answer what visitors came to find.