Why is my website slow? Seven causes and how to check each

Most slow business websites are slow for a few ordinary reasons: photos that are far too big, too much code, too many add-ons from other companies, heavy fonts, weak hosting, no caching, or pages that get built inside the visitor’s phone. You can check each one with free tools, and fix several without a developer.

Three free tools to start with

Google PageSpeed Insights (pagespeed.web.dev) tests any page you give it. It returns a score for mobile and desktop and a list of specific problems with the files responsible. Look at mobile first, since phones are where a slow site hurts most. If your site gets enough traffic, it also shows data from real Chrome users, which matters more than the score.

Google Search Console, if you have it set up, has a Core Web Vitals report built from real-visitor data across your whole site. Core Web Vitals are Google’s three measures of how a page feels: Largest Contentful Paint (how quickly the main content appears), Interaction to Next Paint (how quickly the page responds when you tap something) and Cumulative Layout Shift (how much the layout jumps around while loading). Google uses page speed as one ranking signal among many.

The third tool is in your browser. In Chrome, right-click the page, choose Inspect, open the Network tab and reload. You will see every file the page loaded, its size and how long it took. You can filter by type and sort by size.

Causes in what the page downloads

1. Images that are too large

This is usually the biggest single cause. A photo straight from a phone or camera is often several megabytes and thousands of pixels wide. If it fills a space a few hundred pixels across, the visitor downloads all that extra size for nothing.

How to check: look for image items in PageSpeed Insights and the savings beside them. In the Network tab, filter to images and sort by size.

Who fixes it: often you. Resize the photo to about twice the width it is shown at (so it stays sharp on high-resolution screens), export it as a compressed JPEG or WebP, and re-upload it.

2. Too much JavaScript

JavaScript is the code that makes a page interactive. The browser must download it and then run it, and on an ordinary phone the running can take longer than the download. Page builders, themes and code libraries often include far more than a page uses.

We found this on our own homepage, which used a general-purpose 3D library for a particle animation. We replaced it with a small renderer written for that one job, and the script visitors download went from 137 KB to 12 KB compressed, with no visible change.

How to check: PageSpeed Insights flags JavaScript that goes unused or keeps the page busy. In the Network tab, filter to JS and read the total at the bottom.

Who fixes it: usually a developer. You can help by switching off theme features and builder sections you do not use.

3. Plugins, widgets and third-party scripts

Chat boxes, pop-ups, trackers, social feeds, review widgets. Each one is code loaded from another company’s server, and each can pull in more files of its own. If one of those servers is slow, so is your page.

How to check: PageSpeed Insights has a section on third-party code showing which outside companies loaded what. The Network tab shows the web address each file came from. You can also remove add-ons one at a time and test after each.

Who fixes it: often you, in your platform’s settings. Keep only the add-ons somebody actually uses. A developer can make the rest load after the main content is up.

4. Fonts

A site that loads three font families in four weights each is asking for a dozen downloads before the text looks right. While they arrive, the browser may hide the text or show a stand-in font and then swap it, which makes the layout jump.

How to check: filter the Network tab to fonts and count the files. PageSpeed Insights may also flag text that stays invisible while fonts load.

Who fixes it: a developer, or you if your theme has font settings. Use one or two families, only the weights the design needs, hosted on your own site.

Causes on the server

5. Slow or cheap hosting

Before the browser can do anything, your server has to answer. On crowded budget hosting, or a server doing heavy work for every visit, that first answer can be a noticeable pause, and everything else waits behind it.

How to check: PageSpeed Insights reports how long the server took to respond and flags it when slow. In the Network tab, click the first item (the page itself), open the Timing tab and look at “Waiting for server response”.

Who fixes it: choosing a host is your decision, and moving is usually developer work. On a hosted builder such as Squarespace, Wix or Shopify, the platform runs the servers and there is little to change.

6. No caching or content delivery network

Caching means keeping a ready-made copy of a page so the server does not rebuild it for every visitor. A content delivery network (CDN) keeps copies of your site on servers in many places, so a visitor in Seattle gets it from a server near Seattle.

How to check: look in your hosting or platform settings for caching and CDN options, or ask your host. If the server response is slow on every visit, missing caching is a likely reason.

Who fixes it: often your platform’s settings. Many hosts include a CDN and caching you only need to switch on. Otherwise a developer can set it up.

A cause in how the site is built

7. Pages built in the visitor’s browser

Some sites send an almost empty page, then use JavaScript to build the content inside the visitor’s browser. On a mid-range phone that can mean a blank screen while the code runs. Search engines also have to run that code to see your content. Google can, though it may take longer to pick up changes, and some other tools that read your pages may not see the content at all.

How to check: right-click the page and choose View page source. If your headings and paragraphs are there, you are fine. If it is mostly script tags and an empty container, the page is built in the browser.

Who fixes it: a developer, and it is rarely a small job, because it concerns how the whole site is put together.

You do not need a perfect score

Chasing the last few points of a PageSpeed score, which comes from one simulated test and moves between runs, is rarely worth paying for. What matters is that real visitors on phones are not kept waiting: the main content shows up quickly, the page responds when tapped, and nothing jumps under their thumb. If the real-visitor data in Search Console or PageSpeed Insights rates your pages as good, you can stop there. Speed is also only one part of search; our technical SEO work covers it alongside the other technical things search engines look at.

When rebuilding is cheaper than repairing

Older sites built on heavy themes and page builders often have speed problems built into their foundations. Two signs you are in that situation:

• The same problems come back after every fix.
• The fixes require removing things the site depends on, such as the page builder every page was made with, or the theme that controls the layout.

At that point you are paying for repairs that do not last, and a redesign on a lighter base can cost less over time than repeated patching.

What to do next

Run your homepage and your most important page through PageSpeed Insights on mobile. Start with images and add-ons, which you can often fix yourself, then test again. If the problem is the server, fonts, JavaScript or how the site is built, that is developer work. If you would like someone to watch speed, updates and plugins over time, that is what a maintenance plan is for, and you are welcome to get in touch with your test results.