Why your site is slow, and what to fix first

Last updated 14 October 2026

By the FocalScore team at Astrolabix LLC. First published 14 October 2026. Sources last checked October 2026.

The short answer

Most small-business sites are slow for the same few reasons: photos far bigger than the space they fill, a server that is slow to answer, scripts from other companies that the page waits for, and files that are sent uncompressed or downloaded again on each visit. Fix them in that order. The biggest picture at the top of the page is usually the first thing to look at.

What "slow" means here

Speed is measured as a handful of moments in a page load. The three the free scan leans on most are Google's own measures:

Largest Contentful Paint (LCP): when the biggest picture or block of text at the top of the page has appeared. Google counts 2.5 seconds or less as good.
Total Blocking Time (TBT): how long, while the page loads, scripts keep it from responding to a tap or click. Google counts under 200 milliseconds on an average phone as good.
Time to First Byte (TTFB): how long your server takes to start answering. Google's guidance is 0.8 seconds or less.

These numbers come from a lab test: Google loads your page on a simulated mid-range phone and a slower connection. Your own visitors on office broadband will often see something faster, and visitors on a weak phone signal something slower.

Why it matters to a small business

A visitor who taps your link from a search result or a message sees a blank or half-drawn screen until the page arrives. Some wait; some go back and choose the next result. Speed is also one of the things Google measures about a page. It will not lift a page with nothing useful on it, but a page that is slow to show anything starts behind one that isn't.

How the free scan decides

The scan reads Google's PageSpeed results for your homepage and looks at the files your pages download. The lines it uses, from the check catalogue:

Largest Contentful Paint (LCP) fails when the main picture or text block appears after 2.5 seconds on Google's phone test.
Total Blocking Time (long tasks) fails above 600 milliseconds of blocking time; 200 milliseconds or less is good.
Time to First Byte (TTFB) fails when the server takes more than 0.8 seconds to start answering.
Unoptimized images, Modern & responsive images and Photos aren't bigger than the space they fill look at the format and size of your photos against the space they are shown in.
Text files are compressed and Your images, fonts and files are cached long enough read the headers your server sends with each file: whether text is compressed and whether browsers are told how long to keep a copy.
Your page isn't hidden while it loads fails when a testing snippet or a full-screen loader keeps the page invisible while it loads.

Each finding in the report names the files behind it, largest first, so you can see which photo or which script is the problem rather than guess.

What to fix first

The photos. Save each one at about the size it is shown on the page, in a modern format (WebP or AVIF), and let phones download a phone-sized copy. Chrome's image guidance explains the savings it reports. Don't lazy-load the main picture at the top of the page: it should load first, not last.
The server. If the server is slow to answer, everything after it waits. A page cache (on WordPress, a caching plugin) or a content delivery network in front of the site helps; if neither does, the hosting plan itself may be the limit. Google's TTFB guide lists the usual causes.
Other companies' scripts. Chat widgets, old tracking tags, review carousels and video embeds each bring their own files. Remove the ones you no longer use; for the rest, ask whether they need to load before the visitor can see the page.
Compression and caching. Text files (the page, its stylesheets and scripts) should be sent compressed, and images, fonts, stylesheets and scripts should carry a caching rule so a returning visitor doesn't download them again. web.dev's caching guide explains the Cache-Control header.
Anything that hides the page. An old Google Optimize snippet (look for async-hide in the page's head) or a theme's full-screen loader keeps the page blank even after it has arrived. Remove it.

The fixes, by platform

WordPress

Use an image plugin that resizes uploads and serves WebP, and re-save the largest photos the report names before uploading them again.
Use one caching plugin, not several: it gives you the page cache, compression and browser caching from its settings.
Deactivate and delete plugins you no longer use. A plugin that adds a slider, a pop-up or a font site-wide loads its files even on pages that don't show it.

Shopify, Wix and Squarespace

The platform runs the server, the compression and the delivery network, so the findings about headers are usually not yours to change. What you control is what you add: the size of the photos you upload, the apps and embedded widgets, extra fonts, and any code pasted into the site's header. On Shopify, check that an app you removed hasn't left its script in the theme.

Windows hosting (IIS and ASP.NET)

Compression and browser caching are switched on in web.config, the settings file in your site's top folder. Make a copy of it before you change anything: one malformed line takes the site offline. These lines go inside <system.webServer>; if your file already has a <staticContent> or <urlCompression> element, merge the lines into it rather than adding a second one.

<system.webServer>
  <urlCompression doStaticCompression="true" doDynamicCompression="true" />
  <staticContent>
    <clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="7.00:00:00" />
  </staticContent>
</system.webServer>

That asks browsers to keep images, fonts, stylesheets and scripts for seven days. Compression only works if the server has the compression features installed; Microsoft's page on URL compression says which, and your host can switch them on. On ASP.NET MVC, make sure the live site runs with <compilation debug="false"> so its bundles are combined and minified.

Apache, nginx and Cloudflare

On Apache, compression and caching are mod_deflate and mod_expires rules in .htaccess; on nginx, the gzip and expires settings; on Cloudflare, compression is on by default and the Browser Cache TTL setting sets the caching rule. When the scan recognises your server, the speed findings carry the lines to paste.

How to check yours

Run the free scan and open the Speed section. Each finding shows Google's measurement, the files behind it and the fix. The sample report shows what a finished report looks like. After a change, scan again: lab results move a little from one run to the next, so look at the trend rather than a single reading.

Checklist

The main picture at the top of the homepage is saved at the size it is shown, in WebP or AVIF.
The main picture is not lazy-loaded; pictures further down are.
Scripts you no longer use, from plugins, apps or old tags, are removed.
Text files are sent compressed.
Images, fonts, stylesheets and scripts carry a caching rule.
Nothing keeps the page hidden while it loads.
The server starts answering within Google's 0.8 second guidance, or you have asked your host why not.

What the free scan checks for this

These are the FocalScore checks that cover this guide's subject. Each one in your report says what it found, shows the evidence and gives the fix.

Largest Contentful Paint (LCP)
Time to First Byte (TTFB)
Unoptimized images
Render-blocking resources
No caching / no CDN
Third-party script load
Unused JavaScript & CSS
Total Blocking Time (long tasks)
Total page weight
Modern & responsive images
Text files are compressed
JavaScript weight on a phone
Your images, fonts and files are cached long enough
Photos aren't bigger than the space they fill
Your page isn't hidden while it loads

Sources

Last checked October 2026. Documentation, settings and rules change; if one of these pages now says something different, it is right and this guide is out of date. Tell us at info@focalscore.com.