Sites
How to Tell if Your Website Is Slow (and What to Do)
6 min read
Most people find out their website is slow the worst way: someone tells them. A client who “tried to open it yesterday and it took forever,” a friend who sent a message to warn you, or you yourself, out on the street, trying to show your address on your phone while the page is still loading.
Anyone searching how to tell if your website is slow wants a yardstick that does not depend on opinion. It exists, it is free and it takes about ten minutes. The hard part is usually the next step: understanding what the result means.
Short answer: open your site on your phone, on mobile data and not on your home wi-fi, and watch what happens. Then run the address through PageSpeed Insights, Google’s free tool, and look at the mobile tab. If Search Console is connected, check its Core Web Vitals report too. If all three point the same way, the problem is real.
Test 1: open the site the way your client does
Take your phone, turn off wi-fi and open your site from the link you share, not from a browser bookmark. Count slowly until the page shows up in full and you can tap something.
Do it on two pages: the home page and a service page. And do it when you are not in a hurry, because what matters is the feeling of someone out on the street, deciding who to call or where to have lunch. If you felt like giving up, your client does too.
This test has no number, but it is the most honest of the three. The other two give a name to what you already noticed.
Test 2: PageSpeed Insights
It is a Google site. You paste the address, wait for the analysis and get two readings: what happens to real visitors, when Google has enough data about the address, and a simulated test run on the spot. Always open the mobile tab, because that is where most visits happen.
Three names show up in the report, and they are worth translating:
- LCP: how long it takes for the largest element on screen, usually the main photo or the headline, to appear.
- INP: how long the page takes to respond when you tap something.
- CLS: whether the page “jumps” while loading, pushing away the button you were about to press.
These three make up what is known as Core Web Vitals. Google marks each one green, yellow or red, and that colour is what matters to you. Red on LCP, for example, almost always means a heavy image.
Run a service page too, not only the home page. The home page tends to be the most polished one, and the slowness shows up on the others.
Test 3: the Search Console report
If your site is connected to Search Console, it has a Core Web Vitals report that groups your pages by status. The advantage over the previous test is that it looks at the whole site at once, instead of one page at a time.
If you have never opened Search Console, leave this step for later. The first two tests already answer the question.
What usually makes a site slow
It is almost never a mysterious defect. The most common causes are well known:
| What you see | Likely cause | Who fixes it |
|---|---|---|
| The main photo takes a while to appear | Image uploaded at original size, uncompressed | Whoever looks after the site |
| The page jumps while loading | Images and fonts without reserved space | Whoever looks after the site |
| A delay before taps work | Too many scripts, plugins and widgets | Whoever looks after the site |
| Everything is slow, even a simple page | Weak hosting, or a site too heavy for it | Hosting and whoever looks after the site |
| Only the phone suffers | Page designed for a big screen and adapted later | Design and development |
Notice the last column. Almost all of this is solved in the build, not with a “speed up” button installed afterwards.
How it went on the MUSA Rio case
On the MUSA Rio website, the problem came from the nature of the business itself. People choose a restaurant with their eyes, and large images are exactly what slows a site down the most. Since almost every visit comes from a phone, often out on the street on 4G, every extra second is someone giving up before the page opens.
The answer came from structure, not from cutting images: modern formats, step-by-step loading and a hierarchy that makes clear what has to appear first. The visitor still sees the coffee, the food and the view, just without waiting for everything at once.
That is how we work on every project: we measure speed, indexing and conversion before and after launch, and show the client the numbers. Speed is not a finishing touch, it is part of how the page is designed.
Can it be fixed, or is it better to rebuild?
It depends on where the weight is. If the problem is images and a few scripts, it can usually be fixed without touching the look. If the whole structure was designed for a big screen, with layers and stacked plugins, patching becomes an endless chore, and rebuilding tends to be simpler than it sounds.
A practical way to decide: ask whoever looks after your site to list what they plan to change and what they expect to gain from each item. If the list fits in an afternoon, fix it. If the answer is vague, be wary.
Speed is also not the only reason to change a site, nor the first. If the slow site also does not explain what you do or lead anyone to contact you, the subject is bigger. In that case, landing page or website and custom website or template help you decide what comes first.
What to do this week
- Open your site on your phone, on mobile data, on two pages, and note what bothered you.
- Run the home page and a service page through PageSpeed Insights, on the mobile tab.
- Note which of the three indicators (LCP, INP, CLS) are red.
- Take those notes to whoever looks after the site and ask for a plan, with a deadline.
If you want a site that is born measured, see our custom web design or ask for a quote in four steps. And if you want to see how speed was handled on a real project, see how the MUSA Rio site came together.