How to improve website speed

Your site feels slow on your phone, PageSpeed Insights shows a red score, and you wonder if that is why nobody buys. Here is how to improve website speed on a small site in about a week: test 5 pages, fix the few things that make them slow, then stop. Speed is rarely the only reason a site gets no sales or no signups, but a page that shows nothing for 4 seconds on a phone loses people before they read a word.

Do these three things

About 1 hour today, then 30 to 60 minutes a day for about a week. Once your pages pass, speed is no longer what stands between you and your next sale.

Show the three actions in fullHide the full list

1. 1Today: test your 5 main pages in PageSpeed Insights on Mobile, and write down each page's LCP, CLS and Total Blocking Time in one sheet. A page passes at LCP 2.5 seconds or less, CLS 0.1 or less and Total Blocking Time 200 milliseconds or less. These are the speed checks from your technical SEO checklist.
2. 2Every day: fix 1 page, starting with the slowest. Shrink its top image and remove the apps and scripts it does not need, until all 5 pages pass. Then test every new page, landing page and app before it goes live.
3. 3Every Sunday: test the 5 pages again, check your site builder's speed report and Google Search Console, and remove anything added that week that made a page slower.

Get help doing these

ChatGPT or Claude reads this guide and works through it with you.

Do this with ChatGPT(opens in a new tab)Do this with Claude(opens in a new tab)

1. Test your website speed on mobile with PageSpeed Insights

Test your 5 most important pages in Google's free PageSpeed Insights, on the Mobile tab, and write down three numbers for each. Most of your visitors are on a phone, and the phone test is the hard one, so it is the one that counts.

Pick your 5 pages. Use the pages a buyer sees on the way to paying you:

1. Your homepage.
2. The page you send people to most, such as a landing page or your best product page.
3. Your pricing page or a product page.
4. The page where people act: signup, contact form, booking or cart.
5. Your most visited blog post. If you have none, a second product or service page.

Run the test. Go to pagespeed.web.dev, paste the page's address and press Analyze. Stay on the Mobile tab. Run each page 3 times and keep the middle result, because the lab score moves a little each time from things like routing and ads.

Read the right part. The top of the report shows real visitors from the last 28 days, if Google has enough of them. A new site with a few hundred visits a month usually has none, and that is normal. Then use the lab test below it. Write down:

• LCP (Largest Contentful Paint): how long until the biggest thing at the top, usually an image or the headline, shows. Good is 2.5 seconds or less. Over 4 seconds is poor.
• CLS (Cumulative Layout Shift): how much the page jumps around while it loads. Good is 0.1 or less.
• TBT (Total Blocking Time): how long the page is too busy with scripts to react to a tap. Good is 200 milliseconds or less on mobile. Google's real-visitor measure for this is INP (Interaction to Next Paint, good at 200 ms or less), but the lab test cannot tap, so TBT stands in for it.

Also write down what the LCP breakdown says is the largest element. It tells you what to fix in step 2.

Use your site builder's own report too, if it has one. On Shopify, go to Analytics → Reports and type "contentful" in the search box for the LCP report. It uses your real visitors from the last 30 days and marks the day you installed an app or changed your theme. On Wix, open Site Speed in your site's dashboard; it needs 10 or more visits in the last 7 days.

Page | Address | LCP (s) | CLS | TBT (ms) | Largest element | Passes all 3? | Date
Home | | | | | | |
Most-visited page | | | | | | |
Pricing or product | | | | | | |
Signup, contact or cart | | | | | | |
Top blog post | | | | | | |

The decision. If all 5 pages pass all 3 numbers, stop here. Your speed is fine. Go back to the work that brings people, such as getting traffic to your site. If any number fails, carry on with step 2 on the slowest page.

• Tool: PageSpeed Insights and Google Sheets. Both free.
• Time: about 45 minutes for 5 pages, 3 runs each.
• You will have: a sheet with 5 rows, 3 numbers each, and the largest element named.
• It worked if: every row is filled in, and you know which pages fail and on which number.
• Common mistake: chasing the 0 to 100 score, or testing only on desktop. Google's lines are the three numbers. A page at 72 that passes all three is fine. The other mistake is testing once: one bad run is not a problem.

2. Shrink the big image at the top of each page

The fastest way to improve website speed on a small site is to shrink the large image at the top of each slow page. In 2025, the biggest thing at the top of a phone page was an image on 3 out of 4 pages, so this is usually your LCP.

Find the image. In the report, open LCP breakdown to see which element it is, and Improve image delivery to see how much smaller each image could be. If LCP request discovery says the image is lazy-loaded, that is a fix of its own (below).

Shrink it in Squoosh. Squoosh (squoosh.app) is a free image tool from Google that works in your browser and does not upload your files. For each image:

1. Download the image from your site, or use the original.
2. Drop it into Squoosh.
3. Under Resize, set the width to the size it shows on a computer screen. A full-width banner rarely needs more than 2,500 pixels (Squarespace's own advice), and a product photo needs far less.
4. Set the format to WebP and lower the quality until you can see a change, then go one step back up.
5. Download it. Aim for under 500 KB, and much smaller if you can without the picture looking worse.
6. Upload it in place of the old one.

Load the top image first, not last. "Lazy loading" means an image waits until you scroll to it. That is right for images lower down, and wrong for the one at the top. Google says lazy-loading the top image "will always lead to unnecessary resource load delay". In 2025, about 1 in 6 pages still did it. On a builder, check the image block's settings for "lazy load" and turn it off for the first image only. If you can edit the code, add fetchpriority="high" to that one image.

Swap sliders and autoplay videos at the top for one still image. A slider loads several big images before anyone sees the first. Put your short video lower down the page, so it only loads when someone taps it.

If you run a D2C store: do every product photo, not only the top one. Shopify's advice is to size images to the size they show and to show fewer images on heavy pages. Follow Shopify's own format advice: upload a JPG for photos and a PNG only where you need a see-through background. Do not let shrinking cost you the detail shoppers zoom in on; that is part of a product page that sells.

If you run a SaaS: the top image is often a large product screenshot or a demo video, and the page after it is the signup that starts your free trial, so test that page too. Use a still screenshot, cut to the part that matters, and put the demo below it. If your page stays blank until its scripts load, the page is built in the browser, which is a problem for Google too: check it with the indexing guide.

• Tool: Squoosh (free) and the PageSpeed Insights report.
• Time: about 15 minutes a page.
• You will have: a top image under 500 KB on every failing page, sized to fit, and not lazy-loaded.
• It worked if: a new test shows LCP at 2.5 seconds or less, and Improve image delivery no longer lists that image.
• Common mistake: lazy-loading every image, including the top one, because a plugin or a blog post said "lazy-load your images". The other mistake is uploading stock photos at full size. Library images can be several MB.

3. Remove the apps, plugins and scripts you do not need

Every app, plugin, chat box, popup and tracking tag adds code that a phone must download and run before the page reacts. Remove every one that has not earned its place. This is usually what fixes a high Total Blocking Time.

Make the list. Open your apps or plugins page and write every one in your sheet. Then open 3rd parties and Render-blocking requests in the PageSpeed report. They show the outside scripts that load and how long each one holds the page up. Add any you did not know about. If you cannot tell what a script is, paste its address into ChatGPT or Claude and ask which tool it belongs to, then check that answer against your apps page.

Mark each one keep or remove, with this rule. Keep it only if one of these is true:

• It brought a sale, signup or enquiry in the last 30 days, and you can show it. Conversion tracking, where each sale came from or the app's own report will tell you.
• Checkout, payments, your forms, the law (such as a cookie notice) or your one analytics tool needs it.
• It is the one email signup form you use to build your list, or the tool that sends your welcome and cart emails.

Everything else goes: the second analytics tool, the chat box nobody uses, the countdown timer, the "someone just bought" popup, the old retargeting tag for ads you no longer run, the review app you replaced. Real trust signals, such as reviews and a clear returns policy, do more than a popup that says someone just bought. Keep one popup at most.

Remove them properly.

• Shopify: uninstall the app in Settings → Apps. Shopify says "uninstalling an app doesn't automatically remove its code from your theme". So go to Online Store → Themes, duplicate your theme, and edit the copy with Edit code. Look in layout/theme.liquid and the snippets folder for the app's name, remove the line that loads it, then preview your home page, a product page, the cart and checkout before you publish the copy. If you are not sure, ask the app's developer how to remove its code. Shopify's free Horizon and Online Store 2.0 themes are built for speed; if yours is an old paid theme, try one of them.
• WordPress: deactivate the plugin, then delete it. WordPress's own advice is to "deactivate and delete any unnecessary plugins".
• Wix, Squarespace and other builders: remove the app or the code block, and remove any code you pasted into the site's header settings for a tool you no longer use.

Cut fonts to 2 families. Each extra font and weight is another file. One for headings and one for text is enough.

If you run an agency: speed checks are a fast way to help a prospect. Run their 5 pages, and in your first message name one fix with its number, such as "your top image is 3 MB". It fits the "gap you can see" approach in getting your first client, and it can turn a website job into monthly work or SEO work for your web design clients.

• Tool: your apps or plugins page, and the 3rd parties part of the report.
• Time: 1 to 2 hours once, including checking the preview.
• You will have: a list of every app and script marked keep or remove, with the remove ones gone.
• It worked if: a new test shows Total Blocking Time at 200 milliseconds or less on mobile, and checkout or signup still works on your phone.
• Common mistake: installing a "speed booster" app to fix a site slowed by too many apps. It is one more app. The other mistake is uninstalling on Shopify and leaving the code behind.

4. Stop your page jumping while it loads

A page "jumps" when something loads late and pushes the text down, so a visitor taps the wrong thing. Give every image and video a fixed space, and make banners sit on top of the page instead of pushing it down. That brings CLS to 0.1 or less.

Find what jumps. Open Layout shift culprits in the report. It names the elements that moved the page.

Fix the usual three:

1. Images and videos with no size. Google's advice is to "always include width and height size attributes on your images and video elements". Most builders do this for you when you use their image block. Check images you pasted in with your own code or an embed.
2. Banners, popups and cookie notices that push the page down. Set them to show on top of the page (often called "overlay" or "floating"), or at the bottom, not inserted above the headline. A popup should also wait and stay small. Google's advice is: "Don't obscure the entire page with interstitials."
3. Embeds that load late, such as a review widget, a booking calendar or a social feed. Give their box a fixed height in the builder, or move them lower down the page.

• Tool: the Layout shift culprits part of the report.
• Time: about 30 minutes.
• You will have: the elements that moved the page fixed, moved or removed.
• It worked if: a new test shows CLS at 0.1 or less.
• Common mistake: a "free shipping" or discount bar that slides in at the top after the page loads. Load it with the page, or show it at the bottom.

5. Speed up a slow server, only if the test says so

Fix your hosting only if the report flags Document request latency, which means your server is slow to send the first part of the page. On Shopify, Wix and Squarespace, skip this step: they already run the servers, caching and a CDN (a network that sends your files from a server near each visitor) for you.

Shopify says its scanners' suggestions about "CDN, compression, caching, and server configuration" may not apply, because it already handles them. If you are on a hosted builder and a scanner tells you to "add a CDN", ignore it.

On WordPress or your own host:

1. Turn on caching. A caching plugin saves each page as a ready-made file, so the server does not build it for every visitor. Look in your hosting dashboard for a caching setting first. If there is none, install WP Super Cache (free, by Automattic) and turn on caching.
2. Add a free CDN. Cloudflare's Free plan includes a CDN and costs nothing. You point your domain's settings at Cloudflare, and it sends your files from its servers.
3. If it is still flagged, move host. WordPress's own advice says your hosting hardware "will have a huge impact on your site performance". Very cheap shared hosting is the usual cause.

If you run a B2B company: this is the step most likely to matter for you, because many B2B sites run on WordPress with an old theme and a cheap host. Do it before you spend on getting more leads from your website.

• Tool: your host's caching setting or WP Super Cache, and Cloudflare Free. All free.
• Time: about 1 hour.
• You will have: caching on, and a CDN if you added one.
• It worked if: Document request latency passes on a new test, or it was never flagged.
• Common mistake: paying for a faster host or a CDN on a site builder that already includes them.

6. Fix one page a day, and test every new page before it goes live

Fix 1 page a day, starting with the slowest, until all 5 pass. Then test each new page, app or theme change on Mobile before it goes live. Speed gets worse one small addition at a time, so the only way to keep it is to check every addition.

At about 30 to 60 minutes a page, a week is enough for most small sites. Work in the order of steps 2 to 5 on each page, and retest after each fix so you know which one worked.

Once the 5 pages pass, the job changes. You are going to keep adding pages: a new blog post every day, new landing pages for each campaign, new apps. Test each one on Mobile on the day you make it, and write its numbers in your sheet. If a new app makes any of your 5 pages fail, remove it or decide it is worth the cost, in writing.

If you are testing two versions of a page, test both for speed first. A slower version can lose for that reason alone. If you pay for ads, test the page they land on before the ad goes live: a slow page is one cause of ads that get clicks but no sales.

• Tool: PageSpeed Insights and your speed sheet.
• Time: 30 to 60 minutes a day for about a week, then about 5 minutes for each new page or app.
• You will have: 5 of 5 pages passing, and a row in the sheet for every new page.
• It worked if: all 5 pages pass all 3 numbers, and every page added since has a test on its first day.
• Common mistake: adding an app late in the week and never testing it, then wondering a month later why the site is slow.

7. Check your speed every Sunday

Every Sunday, test your 5 pages again and write the numbers in your sheet. Then check your builder's speed report and Search Console for anything that changed, and undo it.

1. Retest the 5 pages on Mobile and add a row for each. A number that is a little worse in one run is normal. A number that crosses its line two Sundays in a row is a problem.
2. Open your builder's report. On Shopify, the web performance chart marks app installs and theme changes as numbered lines, so you can see which change came before a jump.
3. Open the Core Web Vitals report in Search Console. A small site often shows "No data available", because Google has too few real visits to measure. Once it shows data, fix any page marked "Poor" first. After a fix, open the issue and press Start Tracking: Google then watches real visits for 28 days. Check the rest of your Search Console numbers in the same sitting, as in the Search Console guide.
4. Undo what slowed it. Remove or replace the app, image or embed added before the drop.

Add the result to your monthly marketing review as one line: pass or fail. If sales or signups drop in a week when speed did not change, look elsewhere first, as in getting growth moving again.

• Tool: PageSpeed Insights, your builder's speed report, and Google Search Console. All free.
• Time: about 20 minutes each Sunday.
• You will have: one row a week for each of your 5 pages.
• It worked if: all 5 pages still pass, or you know which change made one fail and have undone it.
• Common mistake: treating one bad run as a crisis and spending Sunday on it. Look for a number that stays over its line.

When speed passes and people still leave, the problem is the page, not the load time. Go to the guide for your business: a store with traffic but no sales, a SaaS with traffic but no signups, or a B2B website with no enquiries. If your store loses people at the cart, work on reducing abandoned carts.

Your website speed checklist for this week

0 of 11 done

Work through this list with an AI assistant

It drafts the work and keeps track of what is done.

Do this with ChatGPT(opens in a new tab)Do this with Claude(opens in a new tab)

Step 1 · Test your website speed on mobile

• Test your 5 main pages in PageSpeed Insights on Mobile and write down LCP, CLS and Total Blocking Time.

Step 2 · Shrink the big image at the top of each page

• Resize and compress the top image on each failing page, and upload it in place of the old one.
• Turn off lazy loading for the top image on each page.

Step 3 · Remove the apps, plugins and scripts you do not need

• List every app, plugin, widget and tracking tag, and mark each keep or remove.
• Remove every app marked remove, with its leftover code, and check the preview.

Step 4 · Stop your page jumping while it loads

• Fix, move or remove each element listed under Layout shift culprits.

Step 5 · Speed up a slow server, only if the test says so

• If Document request latency is flagged, turn on caching and add a free CDN.

Step 6 · Fix one page a day, and test every new page

• Every dayFix 1 failing page, starting with the slowest, until all 5 pass.
• Every dayTest each new page, app or theme change on Mobile before it goes live.

Step 7 · Check your speed every Sunday

• Every SundayRetest your 5 main pages on Mobile and write down the numbers.
• Every SundayCheck your builder's speed report and Search Console, and undo what slowed a page.

Copy listDownloadReset