How to Speed Up a Slow Website (2026)

Your website feels slow, and you already suspect it is costing you. It is. The good part is that slowness is measurable and mostly fixable. You can find the exact cause in about two minutes with a free tool, fix the biggest offenders yourself, and know when you have hit a wall that optimisation cannot get past.

This guide walks the whole path: how to diagnose what is actually slow, the handful of problems behind most slow sites, how to fix them on WordPress and on hosted builders like Wix and Shopify, and the honest point where a WordPress site plus its plugins hits a ceiling that no plugin removes.

Why is my website slow? The short answer

Most slow websites are slow for one of four reasons: oversized images, render-blocking code, slow hosting, or too much third-party JavaScript. Almost every slow site is some mix of these. You do not need to guess which, because the browser can tell you.

Here is the order to check, ranked by how often each one is the main problem:

A slow site is rarely one catastrophic mistake. It is usually a 4 MB hero image, a page builder loading fifteen stylesheets, a cheap shared host, and six marketing scripts, all adding up. The diagnosis tells you which one to attack first.

Step 1: Diagnose before you fix

Run your URL through Google PageSpeed Insights before you change anything. It is free, it needs no login, and it gives you Google's own view of your site, the same data that feeds search rankings. Changing things before you measure is how people spend a weekend "optimising" the wrong thing.

PageSpeed Insights shows two kinds of data, and the difference matters.

Field data (CrUX) is what real visitors actually experienced on your site over the last 28 days. The Chrome User Experience Report collects real load times from real Chrome users, aggregated by URL. This is the data Google uses to judge your Core Web Vitals. If the field data section is green, your real users are having a fast experience. If it is red, they are not. Trust this over everything else.

Lab data (Lighthouse) is a single simulated load in a controlled environment. It is useful for debugging because it lists specific problems ("properly size images", "eliminate render-blocking resources", "reduce unused JavaScript") and estimates how many seconds each fix would save. Treat the lab score as a to-do list, not a grade. It varies run to run and does not reflect your real audience.

The three numbers to read are your Core Web Vitals. Core Web Vitals are Google's three user-experience metrics: Largest Contentful Paint measures loading speed, Interaction to Next Paint measures responsiveness, and Cumulative Layout Shift measures visual stability. A page passes only when all three are in the good range at once.

Source: Google Core Web Vitals documentation

Start with LCP. It is the metric most sites fail, and it is the one users feel as "this page is slow". Fix that first, then INP, then CLS.

Step 2: Fix the images

Images are the single heaviest thing on most web pages, and they are the easiest big win. The median mobile page ships 900 KB of images, more than any other resource type (HTTP Archive Web Almanac 2024). On 68% of mobile pages the LCP element itself is an image (Web Almanac Media chapter), so the thing Google times as "how fast the page loads" is usually a picture. If that picture is a 3 MB file the browser has to download before anything useful appears, your LCP is wrecked no matter how good the rest of the site is.

Four fixes, in order of impact:

1. Compress before you upload. A photo straight off a phone or camera is often 3 to 8 MB. The same image compressed for the web is 100 to 300 KB with no visible quality loss. Run images through Squoosh, TinyPNG, or your CMS's built-in compression before they go live.

2. Serve modern formats. WebP and AVIF are image formats that produce much smaller files than JPEG or PNG at the same quality. Switching a hero image from JPEG to WebP typically cuts its size by 25 to 35% for free.

3. Set explicit width and height. When an image has no dimensions in the HTML, the browser does not know how much space to reserve, so text jumps down when the image finally loads. That jump is your Cumulative Layout Shift. Setting width and height (or an aspect ratio) fixes it.

4. Lazy-load everything below the fold. Images further down the page do not need to load until the visitor scrolls near them. Lazy loading defers them so the visible part of the page loads first. Modern browsers support this with a single loading="lazy" attribute, and every major CMS has a setting for it.

Do these four things and most slow sites drop a full second or more off their load time. It is the highest return per hour of any speed work.

Step 3: Fix render-blocking code

Render-blocking resources are CSS and JavaScript files the browser must download and process before it can draw anything on screen. While the browser waits for them, your visitor stares at a blank page. This is usually the second biggest cause of a slow site after images, and PageSpeed Insights flags it directly as "eliminate render-blocking resources". Google's own guidance is to inline critical resources, defer the non-critical ones, and remove anything unused.

Three moves handle most of it:

• Defer non-critical JavaScript. Scripts that are not needed for the first paint (analytics, chat widgets, anything below the fold) should load with defer or async so they do not block the page. The page draws, then the scripts run.
• Minify and combine CSS and JavaScript. Minifying strips whitespace and comments to shrink files. Every caching plugin and modern build tool does this automatically.
• Remove code you do not use. This is the one most sites get wrong. A page builder loads its entire CSS and JavaScript library on every page even if a given page uses none of it. The Lighthouse "reduce unused JavaScript" and "reduce unused CSS" audits show you how much dead weight is shipping. On a bloated site this is often the largest single number in the report.

That last point is where platform choice starts to matter, which the ceiling section gets to.

Step 4: Fix your hosting

Your server response time is the delay before the page even begins to load, and cheap shared hosting is a common hidden cause of a slow site. Time to First Byte (TTFB) measures how long the browser waits after asking for your page before it receives the first byte back. Google says most sites should aim for a TTFB of 0.8 seconds or less, because it precedes every other metric, including LCP. If that number is high, every visitor waits before a single image or script has been touched, and no front-end optimisation can claw it back.

Two things fix most hosting-related slowness:

• Caching. A cache stores a ready-made copy of your page so the server does not rebuild it from scratch on every visit. On WordPress this is a plugin (WP Rocket, or the free LiteSpeed Cache and W3 Total Cache). On a static or modern-framework site it is built in.
• A CDN. A content delivery network stores copies of your site on servers around the world and serves each visitor from the nearest one. For an Australian business whose host sits in a US data centre, a CDN can cut hundreds of milliseconds off every load. Cloudflare has a free tier that covers most small sites.

If you have compressed your images, deferred your scripts, and TTFB is still high, the host is the problem. Upgrading from budget shared hosting to quality managed hosting is often the fastest single fix available.

How to speed up your site, by platform

The fixes above apply everywhere, but how you apply them depends on what your site is built with.

How to speed up a WordPress site

WordPress runs 43% of the web, and most WordPress speed problems come down to four things you can fix yourself:

1. Install one caching plugin. WP Rocket (paid) or LiteSpeed Cache (free) covers caching, minification, and lazy loading in one install. Do not stack multiple caching plugins, they conflict.
2. Compress and convert images. ShortPixel or Imagify compress on upload and serve WebP automatically.
3. Cut plugins you do not use. A typical WordPress business site runs 20 to 30 plugins, each loading its own CSS and JavaScript on every page. Every plugin you deactivate is weight removed. Audit them and delete what you do not need.
4. Move to quality hosting. Managed WordPress hosting handles caching and server-level optimisation that budget shared hosting does not.

That combination fixes the majority of slow WordPress sites. Where it stops working is covered below.

How to speed up Wix, Squarespace, or Shopify

On hosted builders you do not control the server or the code, so your levers are narrower: compress images before uploading, remove apps and third-party widgets you are not using, and keep the number of fonts and animations down. These platforms handle caching and CDN for you, which is why their average performance is often better than an unmanaged WordPress site. Shopify sites pass Core Web Vitals on mobile 75.22% of the time versus WordPress at 43.44% (CrUX, June 2025). The trade-off is you cannot fix what you cannot reach: if the platform's own code is the bottleneck, you are stuck with it.

How to improve Core Web Vitals specifically

If PageSpeed Insights shows a specific failing metric, target it directly:

• Failing LCP: compress and preload the hero image, serve WebP or AVIF, cut render-blocking CSS, and improve TTFB with caching. LCP is the most common failure and the highest-impact fix.
• Failing INP: reduce and defer JavaScript. INP is poor when heavy scripts block the browser's main thread while it tries to respond to a tap. Fewer, lighter scripts fix it.
• Failing CLS: set explicit dimensions on every image, video, and ad slot, and avoid injecting content above existing content after load. Reserve the space before the element arrives.

For the full data on how Australian sites perform against these thresholds, and what each metric costs in real revenue, see the benchmark report below.

Core Web Vitals by Industry: Australian Benchmarks (2026)

Original Lighthouse data from 18 Australian sites across 6 industries, plus what LCP, INP, and CLS actually mean for rankings and revenue.

Read more

The ceiling: where WordPress and plugins stop helping

There is a point where you have compressed every image, deferred every script, installed the best caching plugin, and moved to premium hosting, and the site is still not fast. This is the platform ceiling, and it is real. No plugin removes it, because the problem is the architecture underneath the plugins.

The numbers show the ceiling clearly. Only 43.44% of WordPress sites pass Core Web Vitals on mobile, and sites built with Elementor, the most popular WordPress page builder, drop to 26.99% (CrUX, June 2025). That is not because those site owners are lazy. It is because a page builder ships its entire styling and scripting library on every page, WordPress assembles each page from a database on the fly, and a stack of 25 plugins each adds its own code. Caching hides some of this by serving a saved copy, but the moment a visitor hits an uncached page, or the cache clears after an update, the full weight is back.

You have hit the ceiling when these are all true:

• PageSpeed Insights still shows large "reduce unused JavaScript" and "reduce unused CSS" numbers after you have done everything.
• The site is fast on a cached load and slow on an uncached one.
• Every plugin update risks breaking something, so you are afraid to touch it.
• You are paying for premium hosting and a premium caching plugin and still failing Core Web Vitals.

At that point, more optimisation is throwing good money after a fixed limit. The alternative is a different architecture. Modern frameworks like Next.js, Astro, and Remix generate the HTML ahead of time, so a page arrives as a finished file instead of being built on every request. There is no page builder shipping unused code, no database query on the critical path, and no plugin stack. Sites built this way score at or near 100 on Lighthouse by default, not after a weekend of tuning. That is the difference between fighting a ceiling and not having one.

The maths usually favours the rebuild sooner than owners expect. A WordPress site that needs quarterly performance work, premium hosting, and a paid caching plugin has a real annual cost. A static build on a modern framework hosts for free or near-free, needs no caching plugin, and does not drift slow between updates. Over three years, the rebuild is often the cheaper option, and it is faster for every visitor the whole time.

The honest summary

Speeding up a slow website is a sequence, not a mystery. Diagnose with PageSpeed Insights and trust the CrUX field data. Fix your images first, because they are the heaviest and easiest thing on the page. Kill render-blocking code and audit your hosting. On WordPress, one caching plugin, compressed images, fewer plugins, and good hosting solve most problems.

The one thing no guide can optimise away is the platform ceiling. When you have done everything and a page builder plus 25 plugins is still shipping megabytes of unused code on every uncached load, the fix is not another plugin. It is a different foundation. Knowing which situation you are in, a site that needs tuning or a site that needs rebuilding, is the whole game.

Sources

• Google PageSpeed Insights - Free tool combining CrUX field data and Lighthouse lab data
• Chrome User Experience Report (CrUX) documentation - How Google collects real-user performance data
• Google Core Web Vitals / Web Vitals - Definitions and thresholds for LCP, INP, CLS
• web.dev: Optimize Largest Contentful Paint - Main causes of poor LCP and how to fix them
• web.dev: Optimize Time to First Byte - TTFB target of 0.8s and the role of CDNs
• Chrome Developers: Eliminate render-blocking resources - Inline critical, defer non-critical, remove unused
• HTTP Archive Web Almanac 2024: Page Weight - Median mobile page ships 900 KB images, 558 KB JavaScript
• HTTP Archive Web Almanac 2024: Media - 68% of mobile pages have an image as the LCP element
• Deloitte / Google: Milliseconds Make Millions - 0.1s load improvement lifts conversions ~8%
• Google / SOASTA: Mobile Page Speed Benchmarks - 53% mobile abandonment at 3+ seconds
• Search Engine Journal: 2025 Core Web Vitals CMS Rankings - CrUX pass rates by CMS (WordPress 43.44%, Elementor 26.99%, Shopify 75.22%)
• HTTP Archive / CrUX Technology Report - Real-world CMS performance data from Chrome users