A slow website is not a technical inconvenience. It is a revenue problem. Users abandon slow pages. Google down-ranks them. Every second of delay narrows the window between a click and a conversion. The good news: most speed problems come from a short list of fixable causes, and you do not need a full site rebuild to fix them.
Below are nine concrete improvements, ordered roughly from easiest wins to foundational infrastructure. Each one is self-contained so you can act on any item without finishing the list first.
Quick answer:
- Compress and properly size every image before it hits the server.
- Switch from JPEG/PNG to WebP or AVIF to cut file size further.
- Defer or remove JavaScript that blocks the browser from rendering your page.
- Use browser caching and a CDN to serve assets faster on repeat visits and to distant users.
- Inline only the critical CSS; defer the rest so it does not block the first paint.
- Audit and remove third-party scripts that add network requests without adding value.
- Check your server response time (TTFB), hosting quality matters more than most fixes.
- Add the native
loading="lazy"attribute to images and iframes below the fold. - Measure everything with Core Web Vitals in Google Search Console before and after each change.
1. Compress and properly size images
Oversized images are the single most common cause of slow load times, compress them before upload and serve them at the exact pixel dimensions the layout requires. [SPEAKABLE]
A hero image shot at 4,000 pixels wide and uploaded directly to your CMS does not become smaller just because your layout shows it at 1,200 pixels. The browser still downloads the full file and then scales it down. That mismatch wastes bandwidth on every page load, for every visitor.
The fix has two parts. First, resize the image to the largest dimension it will ever display at before uploading. Second, run it through a compression tool. Tools like Squoosh (built by the Google Chrome team) let you see the quality tradeoff in real time before you commit. Aim for the smallest file size where the image still looks sharp at its intended display size.
WordPress users can automate this with plugins that compress on upload. Custom builds should add image processing to the deployment pipeline so no oversized file ever reaches production.
Takeaway: Size and compress before upload. Never let the browser do the scaling work.
2. Use modern formats (WebP/AVIF)
WebP delivers smaller file sizes than JPEG or PNG at comparable visual quality, and AVIF compresses further still. [SPEAKABLE]
JPEG has been the web standard for decades, but it was not designed for today's high-resolution screens and performance budgets. WebP, developed by Google, consistently produces smaller files than JPEG at equivalent perceptual quality. AVIF, based on the AV1 codec, goes further, though encoding is slower and support, while broad in modern browsers, is worth verifying for your specific user base via caniuse.com.
Most modern CMSs and image CDNs (Cloudinary, Imgix, and similar) can serve WebP or AVIF automatically based on the browser's Accept header, so the conversion happens without a manual export step. If you are on a static site or custom build, convert images during your build process.
The <picture> element lets you serve AVIF with a WebP fallback and a JPEG/PNG final fallback for older browsers:
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="Description">
</picture>
Takeaway: Switch to WebP at minimum. Use AVIF where your build process supports it. Fall back gracefully.
3. Reduce and defer JavaScript
JavaScript that loads and executes before the page renders blocks the browser from showing content to the user. [SPEAKABLE]
This is called render-blocking JavaScript. The browser parses HTML top to bottom. When it hits a <script> tag without a defer or async attribute, it stops, downloads the file, executes it, and only then continues building the page. From the user's perspective, nothing appears until that work is done.
Two attributes fix this for scripts that do not need to run before the page paints:
defer: downloads in parallel, executes after HTML parsing is complete. Preserves execution order. Correct for most site scripts.async: downloads in parallel, executes as soon as it downloads. Order is not guaranteed. Correct for independent scripts like analytics where load order does not matter.
Beyond attribute changes, audit your JavaScript bundle. Tools like BundlePhobia show the cost of individual npm packages. A single bloated dependency can add hundreds of kilobytes. Tree-shaking (removing unused code at build time) and code-splitting (loading only what a given page needs) are standard in modern frameworks like Next.js and Nuxt but often ignored in older WordPress themes.
Reducing JS payload also directly improves Interaction to Next Paint (INP), which replaced First Input Delay as a Core Web Vital in 2024. A leaner JS thread means the browser is free to respond to user input faster.
Takeaway: Add defer to non-critical scripts. Audit your bundle and remove code the page does not use.
4. Leverage caching and a CDN
A content delivery network serves files from an edge server close to the user, cutting round-trip latency regardless of where the origin server is located. [SPEAKABLE]
Browser caching and a CDN solve different parts of the latency problem.
Browser caching stores static assets (images, CSS, JS) on the user's device after the first visit. When they return, the browser loads those files locally instead of downloading them again. You control this via Cache-Control headers on your server. A common setting for versioned assets like main.abc123.js is max-age=31536000, immutable, cache for a year, never revalidate. For HTML, a shorter or no-cache policy is typically correct since content changes frequently.
A CDN solves latency for first-time visitors and visitors far from your origin server. If your server is in Virginia and a user is in Los Angeles, every request travels coast to coast. A CDN places copies of your static assets at edge locations around the world so that the Los Angeles user downloads from a node nearby. Cloudflare, Fastly, and AWS CloudFront are common options. Many hosts include CDN functionality at the infrastructure level.
Together, caching and a CDN reduce both bandwidth costs and the number of requests that ever reach your origin server.
Takeaway: Set long cache headers for versioned static assets. Serve through a CDN to cut latency for all users.
5. Minimize render-blocking CSS
CSS loaded in the document head blocks rendering until the browser has parsed the full stylesheet, inlining only critical above-the-fold styles lets the browser paint the visible page faster.
The same render-blocking logic that applies to JavaScript applies to CSS linked in the <head>. The browser will not show anything until it has downloaded and parsed every linked stylesheet, because it needs to know how to style the page before painting it.
The solution is to separate critical CSS from non-critical CSS. Critical CSS contains only the styles needed to render what the user sees on initial load (above the fold). That small block gets inlined directly in the <head> as a <style> tag. The full stylesheet loads asynchronously afterward:
<link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="styles.css"></noscript>
Tools like Critical by Addy Osmani automate the extraction of critical CSS. For most sites, the performance gain is largest on mobile connections where stylesheet download time is more significant.
Takeaway: Extract and inline critical CSS. Defer the full stylesheet to prevent it from blocking the first paint.
6. Cut third-party scripts
Every third-party tag adds a network request and can hold up your page if the vendor's server is slow, auditing and removing low-value third-party scripts is one of the fastest ways to reduce load time.
Third-party scripts are everything loaded from a domain you do not control: chat widgets, social share buttons, ad pixels, heatmap tools, review badge embeds, and similar. Each one creates a dependency: your page's load time now includes a DNS lookup, a TCP connection, and a download from that vendor's server. If their server is slow or down, your page waits.
The audit process is straightforward. Open Chrome DevTools, go to the Network tab, and filter by domain. Every external domain that is not your CDN or core analytics is a candidate for review. For each one, ask: does removing this have a measurable negative business impact, or is it there because someone added it and never revisited it?
Google Tag Manager (GTM) does not eliminate this problem, it centralizes it. A tag container with 40 tags still fires 40 requests. GTM makes it easier to audit and remove tags without touching code, which is valuable, but the tags themselves still carry their performance cost.
Takeaway: Audit every third-party script against its business value. Remove anything that is not earning its payload.
7. Improve server response time
Google recommends a Time to First Byte below 0.8 seconds; a slow origin server or shared hosting can inflate it before a single asset downloads. [SPEAKABLE]
Time to First Byte (TTFB) is the time between the browser sending a request and receiving the first byte of the response. Google's guidance identifies 0.8 seconds as the threshold for a "good" TTFB. Everything above that is time the user spends staring at a blank tab before anything loads.
TTFB is affected by:
- Hosting quality. Shared hosting means your server resources are split with other sites. A VPS or dedicated server with fewer neighbors typically responds faster.
- Server location. A CDN handles edge caching, but if a request misses the cache and hits the origin, distance to the origin server matters.
- Database queries. An unoptimized WordPress site running dozens of plugins can spend hundreds of milliseconds running queries before it sends a byte. Database query caching (object caching with Redis or Memcached) helps here.
- Server-side rendering time. For dynamic sites, the time to generate the HTML response before sending it adds to TTFB.
Measure TTFB in Google Search Console's Core Web Vitals report using real user data, or in PageSpeed Insights for lab data.
Takeaway: Check TTFB first. Hosting and database performance are upstream of every other fix.
8. Lazy-load below-the-fold media
The native loading="lazy" attribute on img and iframe elements defers off-screen media and reduces initial page payload in a single line of code. [SPEAKABLE]
When a browser loads a page, by default it downloads every image and iframe on the page, even images that are hundreds of pixels below where the user is looking. Lazy loading changes that behavior: images outside the viewport are not downloaded until the user scrolls close to them.
The implementation is straightforward:
<img src="product-photo.webp" alt="Product description" loading="lazy" width="600" height="400">
The loading="lazy" attribute is supported natively in all modern browsers without JavaScript. It does not require a library. For iframes, including YouTube embeds, the same attribute applies.
A few things to keep in mind:
- Do NOT lazy-load the LCP (Largest Contentful Paint) image, typically the hero. That image should load as fast as possible. Use
loading="eager"or simply omit the attribute on above-the-fold images. - Always include
widthandheightattributes. Without them, the browser does not know the image's dimensions before it loads, which causes Cumulative Layout Shift (CLS), content jumping as images load.
Takeaway: Add loading="lazy" to every image and iframe below the fold. Never lazy-load the hero or LCP image.
9. Measure with Core Web Vitals
Core Web Vitals, Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift, are Google's field-data speed signals used as ranking factors. [SPEAKABLE]
None of the eight fixes above matter if you are not measuring the right things before and after you make changes. Without data, you cannot know which change moved the needle, which fix is still needed, or whether a change caused an unintended regression elsewhere.
Core Web Vitals are Google's three primary user experience metrics:
- LCP (Largest Contentful Paint): measures loading performance. How long until the largest visible element (usually the hero image or heading) renders. Google's threshold for "good" is under 2.5 seconds.
- INP (Interaction to Next Paint): measures interactivity. How quickly the page responds to user input (clicks, taps, key presses). Replaced First Input Delay as a Core Web Vital in March 2024. Google's "good" threshold is under 200 milliseconds.
- CLS (Cumulative Layout Shift): measures visual stability. How much visible content shifts position during load. A score below 0.1 is "good." Missing width/height attributes on images is the most common cause.
Where to measure:
- Google Search Console shows field data, real user measurements from Chrome users on your actual site, grouped by URL. This is the data Google uses in its ranking systems.
- PageSpeed Insights shows both lab data (a simulated test) and field data from the Chrome User Experience Report (CrUX) for individual URLs.
- Chrome DevTools Performance panel and Lighthouse (built into DevTools) are useful for diagnosing specific issues in a controlled environment.
Run a baseline measurement before making any changes. Track each metric by URL group, not just site-wide averages. A fast homepage does not guarantee fast product or service pages.
Takeaway: Measure LCP, INP, and CLS in Google Search Console before and after every change. Lab tools diagnose; field data confirms.
Why speed pays
Fast pages convert better. Slow pages leak revenue at every step: users abandon before the page loads, bounce before they read, and never reach the form or the buy button. Google factors Core Web Vitals into ranking signals for both desktop and mobile search, which means a slow site can cost you organic traffic before a visitor ever arrives.
For businesses running paid search, page speed compounds the problem. A slow landing page raises your bounce rate, which harms Quality Score in Google Ads, which raises your cost per click. The spend stays the same; the results get worse.
Speed work is not glamorous. It does not show up in a campaign report with an easy attribution line. But it is foundational to everything else, SEO, paid media, and conversion rate all improve when the page loads faster.
If you want to know exactly where your site is leaking speed (and revenue), book a strategy call. We will pull your Core Web Vitals field data and your conversion tracking in the same session.
Frequently Asked Questions
How do I make my website load faster?
Start with images: compress them, size them correctly, and convert to WebP or AVIF. Then audit your JavaScript for render-blocking scripts and add defer where appropriate. Check your server response time (TTFB) in PageSpeed Insights, if it is above 0.8 seconds, hosting or database performance is the first bottleneck to fix. Run a Core Web Vitals report in Google Search Console to identify which pages and which metrics need the most attention.
Why is website speed important?
A slow website loses visitors before they engage with your content or offer. Google uses Core Web Vitals, including Largest Contentful Paint and Interaction to Next Paint, as ranking signals, so slow pages can rank below faster competitors for the same keywords. In paid search, a slow landing page increases bounce rate, which can reduce Quality Score and raise cost per click.
What is a good page load time?
Google measures loading performance through Largest Contentful Paint (LCP). A "good" LCP score is under 2.5 seconds, meaning the main visible content on the page loads within 2.5 seconds of the navigation starting. That threshold applies to both mobile and desktop.
What are Core Web Vitals?
Core Web Vitals are three user experience metrics Google uses as search ranking signals. Largest Contentful Paint (LCP) measures loading speed. Interaction to Next Paint (INP) measures how quickly the page responds to user input. Cumulative Layout Shift (CLS) measures visual stability, how much content jumps around as the page loads. Google publishes the "good" thresholds: LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1.
Does website speed affect SEO?
Yes. Google confirmed Core Web Vitals as a ranking signal as part of the Page Experience update. Field data collected from real Chrome users, visible in Google Search Console, feeds directly into Google's ranking systems. Improving LCP, INP, and CLS can improve rankings for pages that are currently below the "good" thresholds.
How do I check my website speed?
Use PageSpeed Insights for both lab and field data on individual URLs. Use Google Search Console's Core Web Vitals report for aggregated field data across your entire site, grouped by page type. Chrome DevTools Lighthouse provides detailed diagnostic recommendations in a local environment.
What is Time to First Byte (TTFB)?
TTFB is the time between the browser sending a request to the server and receiving the first byte of the response. It reflects the speed of your server, the quality of your hosting, and the time needed to process any dynamic content (like database queries). Google recommends a TTFB below 0.8 seconds. A high TTFB delays every subsequent step of the load process.
What is lazy loading?
Lazy loading defers the download of images and iframes that are outside the visible viewport until the user scrolls toward them. It reduces the amount of data downloaded on initial page load. The native HTML attribute loading="lazy" implements this without JavaScript and is supported in all modern browsers. Do not apply it to the main hero or LCP image, which should load immediately.
Should I use WebP or AVIF for images?
Both are better than JPEG or PNG for most web images. WebP has broader browser support and is a safe default. AVIF typically achieves smaller file sizes than WebP at the same visual quality but has slower encoding times. If your image CDN or build pipeline supports AVIF with a WebP fallback using the <picture> element, AVIF is worth using. For teams without that infrastructure, WebP is the practical starting point.