Most small business websites are slow for the same handful of reasons, and about half of those reasons can be fixed in an afternoon without touching a line of code. The problem is that nobody tells you which fixes actually move the needle and which ones are a waste of a Saturday.
This website speed optimization checklist solves that. Every item below is ranked by two things: how long it takes (10-minute fix, afternoon job, or developer required) and the realistic load-time gain you can expect. Work top to bottom, stop when the numbers look good, and only pay for help once you have exhausted the free wins.
Before you start: get your baseline
You cannot prove an improvement without a starting number. Spend five minutes here before touching anything.
- Run your homepage, one service or product page, and one blog post through PageSpeed Insights (both mobile and desktop tabs).
- Run the same pages through GTmetrix or WebPageTest for a waterfall chart, which shows you exactly which file is holding things up.
- Screenshot the results or paste the numbers into a spreadsheet with today’s date.
- Check the Core Web Vitals report in Google Search Console for real-user data, not lab data.
The numbers you are aiming for
| Metric | What it measures | Good | Needs work |
|---|---|---|---|
| LCP (Largest Contentful Paint) | When the main content appears | Under 2.5s | Over 4s |
| INP (Interaction to Next Paint) | How fast the page responds to clicks and taps | Under 200ms | Over 500ms |
| CLS (Cumulative Layout Shift) | How much the layout jumps around | Under 0.1 | Over 0.25 |
| TTFB (Time to First Byte) | Server response speed | Under 800ms | Over 1.8s |
| Total page weight | Size of everything downloaded | Under 1.5 MB | Over 3 MB |
Note: the gains listed in this checklist are typical ranges observed on small business sites. Your mileage depends on your starting point. A site already loading in 1.8s will see smaller absolute gains than one stuck at 7s.
The full checklist at a glance
| # | Fix | Effort | Typical gain |
|---|---|---|---|
| 1 | Compress and resize images | 10 min | 0.5s to 2.5s |
| 2 | Turn on page caching | 10 min | 0.3s to 1.5s |
| 3 | Enable lazy loading below the fold | 10 min | 0.2s to 1.0s |
| 4 | Delete unused plugins and scripts | 20 min | 0.2s to 1.2s |
| 5 | Add width and height to images | 15 min | CLS fix, no jumping |
| 6 | Put a CDN in front of the site | 30 min | 0.2s to 0.8s |
| 7 | Fix and preload the LCP image | 1 hour | 0.4s to 1.5s on LCP |
| 8 | Clean up font loading | 1 hour | 0.2s to 0.7s |
| 9 | Defer and delay third-party scripts | 1 hour | 0.5s to 2.0s |
| 10 | Minify CSS and JS, unblock rendering | 1 hour | 0.2s to 0.6s |
| 11 | Clean the database | 45 min | 0.1s to 0.5s on TTFB |
| 12 | Remove sliders, maps and video backgrounds | 2 hours | 0.5s to 2.0s |
| 13 | Upgrade hosting and PHP version | Developer | 0.3s to 1.5s on TTFB |
| 14 | Strip unused CSS and JS, inline critical CSS | Developer | 0.3s to 1.0s |
| 15 | Fix INP by breaking up long JS tasks | Developer | 100ms to 400ms on INP |
Tier 1: the 10-minute wins (do these today)
These six fixes require no coding knowledge, no staging site, and in most cases no money. On a typical small business site they account for 60 to 70 percent of the total achievable speed gain.
1. Compress and resize your images
Images are the single biggest cause of slow small business sites. The classic mistake is uploading a 4,000 pixel wide photo straight from a phone or a stock library and letting the browser shrink it on screen. The visitor still downloads the full 4 MB file.
- Resize first: no image needs to be wider than about 2,000 pixels, and most content images need no more than 1,200.
- Convert to WebP or AVIF: these formats typically cut file size by 30 to 70 percent with no visible quality loss.
- Use a plugin or tool: ShortPixel, Imagify, Squoosh or TinyPNG will do this in bulk in a few clicks.
- Quality setting: 75 to 82 is the sweet spot. Below 70 you start to see artefacts on photos.
Expected gain: 0.5s to 2.5s. If your homepage is over 3 MB, this one fix alone can halve your load time.
2. Turn on page caching
Without caching, your server rebuilds every page from scratch for every visitor. Caching stores a finished copy and serves that instead.
- WordPress: WP Rocket (paid), LiteSpeed Cache (free, if your host runs LiteSpeed) or WP Super Cache.
- Shopify, Wix, Squarespace: caching is handled for you, skip this step.
- Check your host first: many managed hosts already run server-level caching, and stacking two caching layers causes conflicts.
Expected gain: 0.3s to 1.5s, mostly on TTFB and repeat visits.
3. Enable lazy loading for below-the-fold content
Lazy loading tells the browser not to download images, iframes and videos until the visitor scrolls near them. Modern browsers support the native loading="lazy" attribute, and most platforms apply it automatically now.
Critical rule: never lazy load the image at the top of the page. Doing so delays your LCP and makes your score worse, not better. Exclude your hero image and your logo.
Expected gain: 0.2s to 1.0s on long pages with many images.
4. Delete unused plugins, themes and tracking scripts
Open your plugin list and be ruthless. Every active plugin can load its own CSS and JavaScript on every page, including pages where it does nothing.
- Deactivate and delete anything you have not deliberately used in the last three months.
- Remove old tracking pixels from campaigns that ended (Facebook, LinkedIn, Hotjar trials, abandoned chat widgets).
- Delete inactive themes. They do not slow the site down directly but they are a security liability.
- Look for duplicate functionality: two SEO plugins, two form plugins, two analytics setups.
Expected gain: 0.2s to 1.2s. Always back up before deleting anything.
5. Add width and height attributes to images and reserve space for ads
This does not make the page load faster, but it stops content jumping around while it loads, which is what visitors actually perceive as a broken, sluggish site. It also fixes your CLS score.
Most page builders add dimensions automatically. Check your manually inserted images and any embedded third-party content such as ad slots, review widgets or booking iframes, and give them a fixed container height.
Expected gain: CLS drops toward zero. No load-time change, big perceived-quality change.
6. Put a CDN in front of your site
A content delivery network serves your images, CSS and JavaScript from a server near the visitor instead of from your single origin server. Cloudflare’s free tier takes about 30 minutes to set up through your domain registrar.
This matters most if you serve customers across a wide geographic area. If 95 percent of your traffic is within 200 km of your server, the benefit is smaller, though you still gain HTTP/3 support and image delivery improvements.
Expected gain: 0.2s to 0.8s, more for distant visitors.
Tier 2: the afternoon jobs (a confident owner can do these)
These need a bit more care. Work on a staging copy if you have one, and change one thing at a time so you can identify what broke if something breaks.
7. Fix the element that causes your LCP
PageSpeed Insights tells you exactly which element is your Largest Contentful Paint. On small business sites it is almost always the hero image or a headline sitting on a background image.
- Make sure that image is not lazy loaded.
- Add
fetchpriority="high"to it. - Add a
<link rel="preload">tag for it in the head (most caching plugins have a checkbox for this). - Serve it at the right size for mobile, not the desktop version scaled down.
Expected gain: 0.4s to 1.5s on LCP specifically. This is the highest-leverage single change for Core Web Vitals.
8. Clean up font loading
Custom fonts are a quiet killer. A typical site loads four or five weights of two font families from an external server, each one blocking text from appearing.
- Cut the weights: you almost certainly need regular, bold and maybe one italic. Not nine weights.
- Self-host rather than calling Google Fonts externally. It removes a DNS lookup and a connection to a third-party domain.
- Use
font-display: swapso text shows in a fallback font immediately instead of staying invisible. - Preload the one or two font files used above the fold.
- Subset to the character sets you actually need.
Expected gain: 0.2s to 0.7s, plus a noticeable improvement in how quickly text appears.
9. Defer and delay third-party scripts
Chat widgets, booking tools, review carousels, heat maps, ad pixels and analytics tags are frequently responsible for a third of total page weight. They also run on the main thread, which wrecks INP.
- Delay until interaction: most caching plugins can hold scripts until the user scrolls or moves the mouse. Chat widgets are the perfect candidate.
- Defer: anything not needed for the initial render should carry
deferorasync. - Load conditionally: a booking script only needs to run on the booking page, not on every blog post.
- Audit ruthlessly: if you cannot name the business reason a script exists, remove it.
Expected gain: 0.5s to 2.0s on script-heavy sites, and often the biggest INP improvement available without a developer.
10. Minify CSS and JavaScript and remove render-blocking files
Minification strips whitespace and comments from your code files. Combining used to be standard advice but matters less under HTTP/2 and HTTP/3, so test both ways.
Every caching plugin has these toggles. Turn them on one at a time and reload the site after each, because aggressive minification occasionally breaks sliders, forms or menus.
Expected gain: 0.2s to 0.6s. Modest, but cheap.
11. Clean the database
Relevant mainly for WordPress and WooCommerce sites that have been running for a few years. Post revisions, expired transients, orphaned metadata and spam comments bloat the tables your server queries on every page load.
- Run a database cleanup tool (WP-Optimize, Advanced Database Cleaner or the equivalent in your caching plugin).
- Limit future revisions to 3 to 5 per post.
- Delete spam and trashed comments permanently.
- Back up the database first. This one is not reversible with an undo button.
Expected gain: 0.1s to 0.5s on TTFB, larger on old, content-heavy sites.
12. Remove sliders, video backgrounds and embedded maps
This is a design decision as much as a technical one. A homepage slider typically loads four large images that 96 percent of visitors never scroll through. An embedded Google Map pulls in hundreds of kilobytes of JavaScript to show an address you could display as a static image linked to the map.
- Replace sliders with a single strong hero image and one clear call to action.
- Replace embedded maps with a static map image that links out.
- Replace autoplay video backgrounds with a still frame, or load the video only on click.
- Use facade loading for YouTube embeds so the player only loads when clicked.
Expected gain: 0.5s to 2.0s. Conversion rates usually go up too.
Tier 3: call a developer
If you have done everything above and your LCP is still above 2.5s, the bottleneck is now structural. This is the point where paying for help is genuinely worth it, and you will get a much better quote because you can show exactly what has already been done.
13. Upgrade hosting and the PHP version
Budget shared hosting at a few euros a month puts you on a server with hundreds of other sites. If your TTFB is above 1.2s after caching is enabled, hosting is the problem and no plugin will fix it.
- Move to a managed or cloud host with server-level caching and NVMe storage.
- Make sure you are running a current, supported PHP version. Sites still on PHP 7.x are leaving significant performance on the table and are a security risk.
- Check that HTTP/3 and Brotli compression are enabled.
Expected gain: 0.3s to 1.5s on TTFB. Budget a few hours of migration work.
14. Strip unused CSS and JavaScript and inline critical CSS
A typical page builder site loads 300 to 600 KB of CSS of which the visible page uses maybe 30 KB. Automated tools promise to fix this and frequently break the layout. A developer will identify what is genuinely unused, inline the critical above-the-fold CSS and load the rest asynchronously.
Expected gain: 0.3s to 1.0s, plus a meaningful jump in your PageSpeed score.
15. Fix INP by breaking up long JavaScript tasks
Interaction to Next Paint is the metric most small business sites now fail, and it is the hardest to fix yourself. It measures how quickly the page responds when someone taps a menu, opens an accordion or submits a form. Long JavaScript tasks block the main thread and make the site feel frozen.
A developer will profile the main thread, break long tasks into smaller chunks, remove redundant event listeners and replace heavy JavaScript components with native HTML or CSS equivalents.
Expected gain: 100ms to 400ms on INP. Prioritise this if your Search Console report flags INP as poor on mobile.
What order should you actually do this in?
If you only have one afternoon, here is the sequence that produces the largest result for the least effort:
- Measure and record your baseline.
- Compress and resize images (fix 1).
- Turn on caching (fix 2).
- Delete unused plugins and stale tracking scripts (fix 4).
- Fix the LCP image (fix 7).
- Delay third-party scripts (fix 9).
- Re-measure and compare.
That is roughly three hours of work and, on a site currently loading in 5 to 7 seconds, it commonly lands you under 3 seconds. Everything else is refinement.
Three things not to waste time on
- Chasing a 100/100 score. PageSpeed Insights is a diagnostic tool, not a target. A score of 85 on mobile with an LCP of 2.1s is a fast site. Going from 92 to 98 changes nothing for your customers.
- Testing only your homepage. Your homepage is often the most optimised page you have. Test the product page, the contact page and a blog post, because that is where the traffic converts.
- Stacking optimisation plugins. Two caching plugins, two image optimisers and an extra minifier will fight each other and produce a slower, less stable site than one well-configured tool.
How to keep it fast
Speed decays. New pages get built with uncompressed images, a marketing campaign adds three pixels, a plugin update ships a new stylesheet. Put a recurring reminder in your calendar:
| Frequency | Task |
|---|---|
| Every upload | Resize and compress images before adding them |
| Monthly | Check the Core Web Vitals report in Search Console |
| Quarterly | Audit plugins and third-party scripts, run a full speed test |
| Yearly | Review hosting plan, PHP version and theme bloat |
FAQ
How fast should a small business website load?
Aim for a Largest Contentful Paint under 2.5 seconds on mobile using a mid-range phone on a 4G connection. Total load time under 3 seconds is a reasonable practical target. Beyond that, bounce rates climb sharply, particularly on mobile.
Which fix on this website speed optimization checklist gives the biggest gain?
Image compression and resizing, in almost every case. Images usually make up 50 to 70 percent of page weight on small business sites, and fixing them requires no technical skill. Caching is a close second. There’s a good explainer over at pressidium.com.
Do I need a paid caching plugin?
No. Free options like LiteSpeed Cache (on compatible hosting) or the caching built into your host cover the fundamentals. Paid tools mostly save you configuration time and bundle extra features such as script delay and critical CSS generation, which is worth the cost if your time is limited.
Does site speed really affect my Google rankings?
Core Web Vitals are a confirmed ranking signal, but they are a tiebreaker rather than a primary factor. Relevant content still wins. The stronger business case is conversion: faster pages produce measurably more enquiries and sales from the same traffic.
Will optimising speed break my website?
It can, which is why you change one setting at a time and reload the site after each. The risky steps are aggressive minification, unused CSS removal and database cleaning. Take a full backup before you start and test your contact forms, menus and checkout after any change.
How much should I expect to pay a developer for speed work?
For a small business site, a focused performance audit and implementation typically runs between a few hundred and a couple of thousand euros depending on the platform and how much custom code is involved. Doing the Tier 1 and Tier 2 items yourself first will noticeably reduce that quote because the developer spends their time on the hard problems, not on ticking checkboxes you could have handled.
Start with the ten-minute fixes
The gap between a slow site and a fast one is rarely a mysterious technical problem. It is four oversized images, a caching setting nobody switched on, and three tracking scripts from a campaign that ended two years ago. Work through Tier 1 this week, re-run your tests, and only then decide whether you need to pay anyone.