A slow website costs you in two places at once: rankings and conversions. Google confirmed Core Web Vitals as a ranking input in 2021, and the relationship between load time and bounce rate is well-documented across the web performance literature. This isn't a "nice to have" anymore.
Below are seven specific fixes — in roughly descending order of impact for most sites. Each one has a clear mechanism, not just a vague directive to "make it faster."
Quick answer — the 7 ways to improve website speed:
- Convert images to WebP or AVIF and compress before uploading
- Defer and remove unused JavaScript to cut Total Blocking Time
- Route visitors through a CDN to reduce latency
- Set long cache expiry headers on static assets
- Audit and remove unnecessary third-party scripts and tags
- Upgrade hosting or add server-side caching to lower TTFB
- Validate performance with CrUX field data, not just PageSpeed Insights lab scores
1. Compress and Modern-Format Your Images
Images are typically the heaviest assets on any webpage — converting them to WebP or AVIF and compressing before upload is the single highest-ROI speed fix for most sites.
JPEG and PNG were built for a different web. WebP delivers smaller file sizes than JPEG at equivalent visual quality. AVIF goes further — Google's own web.dev documentation describes AVIF as achieving smaller file sizes than WebP in many cases, at the same or better quality. Both formats are now supported by all major modern browsers.
The practical workflow: run images through a tool like Squoosh (free, browser-based, from the Chrome team) or a plugin like ShortPixel before upload. If you're on WordPress, a plugin like Imagify or ShortPixel can bulk-convert your existing library and serve WebP automatically to supported browsers with no code changes.
Two additional steps matter alongside format:
- Lazy-load below-the-fold images. The
loading="lazy"HTML attribute tells the browser to skip loading images until the user scrolls toward them. Google's documentation on lazy loading covers implementation. This reduces initial page weight without removing a single image. - Set explicit width and height attributes. Omitting these causes layout shift during load, which directly hurts your Cumulative Layout Shift (CLS) score — one of the three Core Web Vitals.
Takeaway: Before touching your server config or JavaScript, audit your images. It's free, takes an afternoon, and typically produces the biggest single drop in page weight.
2. Reduce and Defer JavaScript
Excess JavaScript is the most common cause of slow, unresponsive pages on modern sites — especially on mobile.
When a browser encounters a JavaScript file, it stops parsing HTML, downloads the script, executes it, and then resumes. This is called render-blocking. Google's Total Blocking Time (TBT) metric — a proxy for your Interaction to Next Paint (INP) Core Web Vital — measures how long this blocking adds up during load.
Two techniques address this directly:
- Defer non-critical scripts. Adding
deferorasyncto script tags tells the browser not to block rendering while downloading those files. Scripts that don't need to run before the page displays (analytics, chat widgets, A/B testing tools) are candidates for deferral. - Remove unused JavaScript. Modern sites accumulate JS from plugins, page builders, and integrations. Chrome DevTools' Coverage tab (open DevTools → Cmd/Ctrl+Shift+P → "Show Coverage") shows exactly which JS bytes are downloaded but never executed on a given page. Unused code is pure weight.
For WordPress and Shopify sites, page builder plugins frequently load scripts site-wide even when those scripts are only needed on one template. A developer can conditionally enqueue scripts only on the pages that need them — this alone can cut JS payload substantially.
Takeaway: Run the Coverage audit in Chrome DevTools before assuming you need a CDN or hosting upgrade. JS bloat is often the hidden ceiling.
3. Use a Content Delivery Network
A CDN (Content Delivery Network) routes each visitor's request to the server node geographically closest to them, cutting the physical distance data has to travel. For a site hosted on a single US server, a visitor in London pays the latency penalty of a transatlantic request on every asset. A CDN eliminates that.
Every third-party tag adds a network request your server doesn't control; auditing and removing unused tags in Google Tag Manager is one of the fastest ways to cut page weight. (Note: this speakable is positioned here in the flow — its natural home is Item 5, but it's flagged early per the speakable set.)
The practical impact of a CDN shows most clearly in Time to First Byte (TTFB) and in the load time of static assets — images, CSS, JS. Cloudflare's free tier is a legitimate starting point for most small and mid-size businesses. Cloudflare also adds HTTP/2 and HTTP/3 support automatically, which allows multiple assets to load over a single connection instead of opening a new connection for each file.
What a CDN won't fix: slow database queries, unoptimized server-side code, or a server that's simply undersized. A CDN accelerates asset delivery — it doesn't substitute for a properly configured origin server.
Takeaway: If your audience is geographically distributed, a CDN is one of the lowest-effort, highest-impact infrastructure changes you can make. Start with Cloudflare's free plan and measure before upgrading.
4. Cache Aggressively
Caching tells browsers (and intermediate servers) to hold onto files they've already downloaded so they don't re-request them on the next visit. For a returning visitor, a well-cached page can load in a fraction of the time of a first visit — because most of the assets are already on their device.
Browser caching stores static files on a returning visitor's device so unchanged assets don't need to re-download, cutting load time on every subsequent visit.
The key lever is the Cache-Control HTTP header. Setting a long max-age on static assets (images, fonts, CSS, JS) — typically one year for files with versioned filenames — tells the browser to reuse the cached copy. Google's guidance on HTTP caching covers the header syntax and cache invalidation strategy.
For WordPress sites, plugins like WP Rocket or W3 Total Cache implement both browser caching and server-side page caching — the latter stores a pre-rendered HTML version of each page, so the server doesn't regenerate it from the database on every request. This directly reduces TTFB for cached pages.
Two things to confirm:
- Your cache headers are actually set. Run your URL through GTmetrix or WebPageTest and check whether static assets return
Cache-Controlheaders with a meaningfulmax-age. - Cache invalidation is handled correctly. If you update a CSS file, the browser needs to know to re-download it. Content-addressable filenames (e.g.,
style.a3f2bc.css) solve this automatically — most modern build tools and WordPress caching plugins handle this.
Takeaway: Cache-Control headers are often not set by default on shared hosting. Check yours. It's a two-hour fix that benefits every return visitor indefinitely.
5. Trim Third-Party Scripts and Tags
Every third-party tag — a chat widget, a Facebook Pixel, a Hotjar session recording script, a Google Ads remarketing tag, a review badge — adds at least one external network request. Your server doesn't control those external servers, so if one is slow or goes down, it can block or delay your page load.
The right tool for this audit is Google Tag Manager. Open GTM, go to your container, and pull up the list of all active tags. For each one, answer two questions: (1) Is this tag still in use? (2) Is it firing on pages where it has no purpose?
Common findings in a real tag audit:
- A/B testing scripts loading site-wide when only one page is being tested
- Pixel tags for ad platforms the client stopped using six months ago
- Multiple versions of the same tag (GA4 and UA both running simultaneously long after UA sunset)
- Chat widgets loading on every page when support is only offered to logged-in customers
Removing unused tags doesn't require a developer — it's a GTM publish. Restricting tags to fire only on relevant page paths is a trigger configuration change, also in GTM.
Every third-party tag adds a network request your server doesn't control; auditing and removing unused tags in Google Tag Manager is one of the fastest ways to cut page weight without a code deployment.
Takeaway: A tag audit takes two hours. Run it quarterly. The tags that slow your site most are often ones no one remembers adding.
6. Improve Server and Hosting Response Time
Time to First Byte measures how long your server takes to respond — slow shared hosting can neutralize every other performance improvement you make.
Time to First Byte (TTFB) is the elapsed time between a visitor's browser sending an HTTP request and receiving the first byte of the response. Google explicitly calls TTFB out in its page experience documentation as a server-side metric that affects Core Web Vitals — specifically Largest Contentful Paint (LCP).
Shared hosting is the most common cause of high TTFB for small business sites. On shared hosting, your site shares CPU and memory with dozens or hundreds of other sites on the same physical server. When those neighbors spike in traffic, your TTFB spikes too. It's not a code problem — it's an infrastructure one.
Practical path forward:
- Add a server-side cache first. If you're on WordPress, WP Rocket or LiteSpeed Cache (if your host runs LiteSpeed) can bring TTFB down substantially by serving pre-built HTML instead of hitting the database on every request. Test before migrating hosts.
- Move to managed WordPress hosting if caching doesn't solve it. Hosts like Kinsta, WP Engine, or Flywheel are built specifically for WordPress and include infrastructure-level caching, isolated containers, and CDN by default. The price delta is real, but so is the performance delta.
- Measure before and after. Use WebPageTest's waterfall view to isolate TTFB as its own metric. If TTFB is above 600ms consistently, it's a hosting problem first, a code problem second.
Takeaway: If your TTFB is consistently above 600ms, no amount of image compression or JS deferral will get you to a passing LCP. Fix the server first.
7. Measure with Field Data, Not Just Lab Data
Google's Core Web Vitals are confirmed ranking inputs, meaning page speed directly affects where your site appears in search results.
Here's the distinction most people miss: PageSpeed Insights gives you two kinds of data. The lab data at the top — simulated on a fixed device with a throttled connection — tells you what could happen. The field data below it, drawn from the Chrome User Experience Report (CrUX), tells you what actually happened for real visitors to your site over the past 28 days.
Google's ranking algorithm uses field data from real users, collected through the Chrome User Experience Report, not simulated lab scores — so a good PageSpeed Insights number doesn't guarantee good ranking performance.
Google's ranking algorithm uses the field data. A site can score 90+ in the lab and still fail Core Web Vitals in the field if real users on slower devices or connections are having a worse experience. This matters practically: you can over-optimize for a simulated score while your actual ranking signal stays poor.
Where to check field data:
- PageSpeed Insights — scroll past the lab score to the "Discover what your real users are experiencing" section. This is your CrUX data.
- Google Search Console → Core Web Vitals report — shows field performance across your entire site, segmented by page group, with a 28-day rolling window.
- CrUX Dashboard (via Looker Studio) — a free template Google provides for tracking field data over time.
The CrUX dataset requires a threshold of real user visits to surface data. New sites or low-traffic pages may not have field data yet — in which case lab data is your best available proxy, but treat it as directional.
Takeaway: Optimize for the Google Search Console Core Web Vitals report, not a PageSpeed Insights score. The Search Console report shows what Google actually sees for ranking purposes.
Why Speed Directly Affects Revenue
Page speed isn't a developer vanity metric. It runs through two clear business levers:
SEO rankings. Google confirmed Core Web Vitals — LCP, INP, and CLS — as page experience ranking signals. A site that fails Core Web Vitals in the field is working against itself in organic search, regardless of how good its content and backlinks are.
Conversion rate. The relationship between load time and bounce rate is well-documented in web performance research. Visitors who don't wait for a page to load don't convert. For businesses running Google Ads or any paid channel, a slow landing page raises cost per lead by reducing the conversion rate on every dollar of spend — you pay for the click either way.
If your site is running paid media and you haven't audited page speed, you're almost certainly leaving qualified traffic on the table. A strategy call can identify exactly where speed is costing you conversions — book one here.
For a broader look at how technical performance fits into your overall visibility, see our SEO services overview.
Frequently Asked Questions
How can I make my website faster?
Start with images — convert to WebP or AVIF and compress before uploading. Then audit JavaScript for unused and render-blocking scripts. Add browser caching headers, consider a CDN for geographically distributed visitors, and remove unused third-party tags from Google Tag Manager. Check your server's TTFB — if it's consistently above 600ms, a hosting upgrade or server-side cache is the next priority.
Why does website speed matter?
Website speed affects two business outcomes directly: search rankings and conversion rate. Google's Core Web Vitals are confirmed ranking inputs, so slow pages compete at a disadvantage in organic search. Separately, visitors who experience slow load times are more likely to leave before converting, which raises cost per lead on any paid media you're running.
What is a good page speed score?
Google's Core Web Vitals define thresholds for each metric: Largest Contentful Paint (LCP) should be 2.5 seconds or faster, Interaction to Next Paint (INP) should be 200 milliseconds or less, and Cumulative Layout Shift (CLS) should be 0.1 or less. These are field data thresholds — what real users experience — not lab simulation scores.
What is Time to First Byte (TTFB)?
TTFB is the time elapsed between a browser sending an HTTP request and receiving the first byte of the server's response. It's a server-side metric. High TTFB typically indicates slow hosting, missing server-side caching, or slow database queries. Google includes TTFB as a factor in its page experience evaluation because it directly drives Largest Contentful Paint.
What's the difference between lab data and field data in PageSpeed Insights?
Lab data is a simulated measurement run on a fixed virtual device with a throttled network connection. Field data (CrUX) is aggregated from real Chrome users visiting your actual site over the past 28 days. Google uses field data for Core Web Vitals ranking signals, not lab data. A high lab score does not guarantee passing field data.
Does page speed affect Google Ads performance?
Yes, in two ways. First, Google's Quality Score for landing pages considers user experience, and a slow page can lower Quality Score, which raises your cost per click. Second, a slow page directly reduces conversion rate — meaning you pay for clicks that don't convert. For any campaign where you're optimizing toward a target CPA or ROAS, landing page speed is a lever worth measuring.
How do I check my Core Web Vitals field data?
Open Google Search Console and navigate to the Core Web Vitals report under Experience. This shows field data from CrUX across your site's page groups, flagging pages that are Poor, Need Improvement, or Good for LCP, INP, and CLS. You can also check field data for individual URLs at pagespeed.web.dev — scroll below the lab score to the "Discover what your real users are experiencing" section.
What is a CDN and do I need one?
A CDN (Content Delivery Network) is a network of servers distributed geographically. When a visitor loads your site, the CDN routes their request to the nearest server node, reducing latency. If your visitors are spread across multiple regions and your site is hosted on a single server, a CDN will reduce load times for anyone not physically close to that server. Cloudflare offers a free tier that covers most small business needs.