How to fix a slow website: a step-by-step plan

A slow website rarely announces itself. Nobody emails to say the homepage took six seconds on their phone; they just tap back and call someone else. This guide is the order we work in when a business asks us to make a site faster. You can follow most of it yourself.

If you want the background first — what the numbers mean, and how we found the real cause on our own site — read why your website is slow, and what it is costing you. This post is the hands-on version: a fix plan, not the diagnosis.

Step 1: Measure before you touch anything

Guessing is how people spend money on the wrong fix. Measure first.

1. Open PageSpeed Insights, paste your homepage URL and choose Mobile.
2. Run it three times. The score moves between runs, so note the range, not one number.
3. Write down three numbers: Largest Contentful Paint (LCP), Total Blocking Time (TBT) and Cumulative Layout Shift (CLS).
4. Repeat for your most important money page, such as a service page or product page.
5. If your site is in Google Search Console, open the Core Web Vitals report. That uses real visitors’ data, which matters more than any one test.

Google’s “good” thresholds for real visits are LCP under 2.5 seconds, Interaction to Next Paint (INP) under 200 milliseconds and CLS under 0.1. If you are already inside them on mobile, speed is probably not your biggest problem.

Step 2: Read what the test is telling you

Each slow number points to a different cause:

• Long “Initial server response time” or Time to First Byte. The server is slow to start sending the page. Look at hosting and caching (step 3).
• High LCP with large images in the “Opportunities” list. Images are too big (step 4).
• High Total Blocking Time. Too much JavaScript, often from a page builder, sliders, chat widgets or tracking scripts (step 5).
• High CLS. Things jump around as they load, usually images without set sizes, late-loading fonts or banners (step 6).

Fix the biggest problem first, then measure again. Changing five things at once means you will never know which one helped.

Step 3: Hosting and caching

If the server takes more than about a second to respond, nothing you do in the browser can win that time back.

• Turn on page caching. On WordPress that is a caching plugin or your host’s built-in cache. It serves a ready-made copy of each page instead of rebuilding it for every visitor.
• Use a CDN. A content delivery network serves your files from a location near the visitor. Many hosts include one, and Cloudflare has a free plan.
• Check your hosting plan. The cheapest shared plans put hundreds of sites on one server. If response times are still slow after caching, a better plan or host is a real fix.
• Update PHP and the platform. Old software versions are slower and less secure. Your host’s control panel usually shows the PHP version.

Step 4: Images

This is the most common cause we see on small business sites, and the easiest to fix.

• Resize before uploading. A photo straight from a phone can be 4,000 pixels wide. Most website images display at under 1,600 pixels.
• Compress and use a modern format. WebP or AVIF files are usually much smaller than JPEG or PNG at the same visual quality. Our free image compressor does this in your browser without uploading the file anywhere.
• Lazy-load below the fold. Images further down the page should load only when the visitor scrolls near them. Do not lazy-load the main image at the top, because that delays LCP.
• Set width and height on every image so the browser reserves space and the layout does not jump.
• Be careful with background videos. An autoplaying video header is one of the heaviest things you can put on a phone. A still image with a play button is often better.

Step 5: JavaScript, plugins and third-party scripts

High Total Blocking Time means the phone is busy running code and cannot respond to taps.

• Audit your plugins or apps. List everything installed and remove what you do not use. Deactivated is not enough on some platforms; delete it.
• Question every third-party script. Chat widgets, heatmaps, multiple analytics tags, social feeds and review carousels all add weight. Keep the ones you actually look at.
• Delay what is not needed at first paint. Chat widgets and some tracking can load after the page is usable, or after the first interaction.
• Watch for heavy page builders. Some builders load code for every feature they offer, used or not. If the builder is the main cost, tuning only goes so far (see step 8).

Step 6: Fonts and layout shift

• Use fewer font files. Each weight and style is a separate download. Two families and three or four weights is plenty for most sites.
• Self-host fonts and use font-display: swap so text appears immediately in a fallback font.
• Reserve space for anything that loads late, such as banners, embeds and ads, so the content below does not jump.

Step 7: Measure again, and keep measuring

Re-run PageSpeed Insights three times on the same pages and compare with your notes from step 1. Then check the Search Console Core Web Vitals report over the following weeks, because that is what real visitors experience. Add a reminder to re-test after every big change, such as a new plugin, a new theme or a new tracking tag. Speed tends to decay slowly as things get added.

Step 8: Know when to stop tuning and rebuild

Sometimes a site is slow because of how it was built: a theme that loads everything everywhere, a builder that produces heavy markup, or years of plugins layered on top of each other. You can spend months tuning it and still fail the mobile thresholds.

Signs a rebuild is the cheaper option:

• Total Blocking Time stays high on mobile even after removing unused plugins and scripts.
• The theme or builder cannot be changed without rebuilding most pages anyway.
• You are paying monthly for speed optimisation with no measured improvement.

A rebuild does not have to mean a bigger site. Often it is the same pages on a leaner theme or a static framework. Our comparison of WordPress, Webflow and custom code covers the trade-offs.

A one-page checklist

• Measured mobile LCP, TBT and CLS three times on two key pages
• Checked Search Console Core Web Vitals
• Page caching on, CDN on, current PHP or platform version
• Images resized, compressed to WebP or AVIF, lazy-loaded below the fold, sizes set
• Unused plugins and scripts removed; chat and tracking delayed
• Two font families or fewer, self-hosted, font-display: swap
• Re-measured and noted the change

Want us to look at it? Maxverse Lab speeds up and rebuilds small business websites. Send us the URL and we will tell you which step above would make the biggest difference, and whether tuning or a rebuild makes more sense. Get a quote.