When a small business site feels slow, the cause is rarely mysterious. The browser is downloading too much, running too much, or downloading the same files again on every visit. Finding out which takes ten minutes with tools already on your computer, and fixing the worst of it usually takes an afternoon, not a budget.
Write the numbers down first
Measure before touching anything, or you will never know which change helped. Open the page in Chrome, press F12 and go to the Network panel. Tick Disable cache, pick one of the slower presets from the throttling menu so you see what a visitor on mobile data sees, and reload. The bar along the bottom shows the number of requests, the amount transferred and when the page finished loading. Sort by the Size column and the worst offenders rise to the top.
Then run a mobile report in the Lighthouse panel and note Largest Contentful Paint: how long until the biggest thing on screen, usually the main image or headline, has appeared. Google counts 2.5 seconds or less as good. If the site has enough visitors, PageSpeed Insights also shows how real Chrome users experienced it over the previous 28 days, which beats any test you run yourself. Run each test three times and keep the middle result, because single runs wander.
Where the time goes
On a typical small site, four things account for most of the waiting.
Images
Usually the heaviest part of the page, and the easiest win. A photo straight from a phone is several thousand pixels wide; the page shows it a few hundred pixels across, and the browser downloads all of it anyway. Resize each image to about twice the largest size it is displayed at (enough for sharp phone screens), then compress it and save it as WebP, which every current browser reads. Give each img its width and height so the page does not jump as pictures arrive, and add loading="lazy" to images further down. Not to the main image at the top, though: lazy-loading the biggest thing on screen only makes it arrive later.
Too many scripts
Every chat widget, slider, social feed, analytics tag and page-builder add-on brings its own JavaScript, often from someone else's server. Each has to be downloaded and run, and while it runs the page can ignore taps. Filter the Network panel by JS to see how many there are and where they come from; the Coverage panel (three-dot menu, More tools) shows how much of each file the page actually used.
Then ask, for each one, who looks at what it produces. Two analytics tools counting the same visits, a carousel nobody clicks past the first slide: deleting a script is the only optimisation that makes it free. For those that stay, the defer attribute stops them holding up the page.
No caching
Click the logo or the stylesheet in the Network panel and look at the response headers for Cache-Control or Expires. If neither is there, the browser has to guess how long to keep the file, and returning visitors fetch or re-check it more often than they need to.
Plenty of small business sites live on shared hosting (this one does), and on Apache-based hosting a few lines in the .htaccess file fix it. The IfModule wrapper means nothing breaks if the host lacks mod_expires, and JavaScript appears twice because servers label it either way:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/html "access plus 0 seconds"
ExpiresByType text/css "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType image/webp "access plus 6 months"
ExpiresByType image/jpeg "access plus 6 months"
ExpiresByType image/png "access plus 6 months"
ExpiresByType font/woff2 "access plus 1 year"
</IfModule>One catch. A browser told to keep style.css for a month will do exactly that, even after you change it. When you update a cached file, rename it or add a version to the link, such as style.css?v=2. The HTML is checked on every visit, so visitors pick up the new link straight away.
Fonts
Two font families in four weights each is eight files before any text can be drawn in them, and browsers may hide the text while they wait. Use fewer weights (regular and bold cover most pages), serve WOFF2, and set font-display: swap so text appears at once in a fallback font. Or ask whether you need a web font at all: the system fonts on current phones and computers are perfectly good for body text.
What to fix first
Images first: the most weight, and shrinking them changes nothing visible. Then the scripts you can delete, a conversation more than a technical job. Then caching: one file, a few minutes, and every repeat visit is quicker. Fonts last; the gains are smaller, though they decide how soon anyone can read. A bigger hosting plan can wait until all four are done.
Measure again, the same way
After each change, repeat the test exactly: same page, cache disabled, same network preset, three runs. Compare requests, bytes transferred and Largest Contentful Paint with the numbers you wrote down. Then reload once with the cache switched back on. The Size column should now say "(disk cache)" or "(memory cache)" for the files you told the browser to keep.
Sites get slow one good reason at a time
Few sites launch slow. They get there gradually: a tracking tag for one campaign, a banner uploaded straight from the camera, a widget someone asked for once. Each arrived for a reason, and none was removed when the reason went away. Keep your numbers where you will find them, rerun the test whenever something new goes on the site, and decide each time whether it is worth what it costs. That habit is free, which is the right price for a small business.
