Your website opens, but on a phone it takes a while. It looks fast to you because you always open it from the same computer, with a full cache and the office fibre connection. The customer looking for you on a smartphone, perhaps in the car between Ponte San Giovanni and the city centre, sees something else: a white screen, then images appearing in pieces, then the button moving just as they tap it.
In this guide you’ll see how to measure it in five minutes with a free Google tool, what the numbers mean and what you can do yourself.
How can I tell if my website is slow?
All you need is PageSpeed Insights, Google’s free tool. Here are the steps.
- Open pagespeed.web.dev.
- Paste in the address of the page you want to check. Start with the home page, then try the page that brings in the most enquiries (services, menu, products).
- Press “Analyze” and wait a few seconds.
- Stay on the Mobile tab: that’s the one that counts, because most people looking for a local business do so on their phone.
- Look first at the top section, with the real-user data. Then scroll down to the performance score and the list of suggestions.
The report has two parts, and mixing them up is the most common mistake.
- Real-user data. These are genuine visits made with Chrome over the last 28 days. As the PageSpeed Insights documentation explains, this data describes the real experience, while the simulated test is there to find the cause of problems. If the site gets few visits, this section may not appear.
- Simulated test (the score from 0 to 100). Google loads the page on a mid-range phone over a slow network. A score of 90 or above is good, 50 to 89 needs improvement and below 50 is poor.
If the top section says the Core Web Vitals assessment has passed, you’re fine for most visitors, even if the score isn’t 100. If it hasn’t passed, the problem is real and your customers are experiencing it.
Do you have a Google Search Console account? The “Core Web Vitals” report shows you which groups of pages have problems, not just the home page.
LCP, INP and CLS: what do they mean in plain terms?
They are the three Core Web Vitals, the measures Google uses to assess the experience of people visiting a page. The thresholds are published on web.dev and apply to 75% of visits: if three visitors out of four fall under the threshold, the value is good.
| Measure | What it tells you | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | How long the main element takes to appear, usually the large photo or the heading | up to 2.5 s | 2.5-4 s | over 4 s |
| INP (Interaction to Next Paint) | How quickly the page responds when you tap a button or open a menu | up to 200 ms | 200-500 ms | over 500 ms |
| CLS (Cumulative Layout Shift) | How much the content moves around while the page loads | up to 0.1 | 0.1-0.25 | over 0.25 |
A simple way to remember them:
- LCP is “when do I see something useful?”.
- INP is “when I tap, does something happen straight away?”.
- CLS is “does the text run away from me while I’m reading?”. The typical case is the cookie banner, or an image without set dimensions that pushes everything down.
Why is my WordPress website slow?
WordPress isn’t slow in itself. It becomes slow because of what gets added on top of it over the years. These are the causes we find most often.
- Oversized images. Photos uploaded straight from the camera or phone, several megabytes each, shown in a small box.
- Page builders. Elementor, Divi, WPBakery and the like load a lot of code even for simple pages.
- Too many plugins. Each one can add CSS and JavaScript files to every page, even where they aren’t needed.
- Third-party scripts. Chat widgets, embedded Google Maps, Instagram widgets, advertising pixels, YouTube videos on the home page.
- Fonts loaded from elsewhere. Several font families and weights, downloaded from external servers before the text is shown.
- Slow or overloaded hosting. The server takes too long just to respond, before it has even sent the page.
- No caching. Every visit makes the page rebuild from scratch by querying the database.
One of our own cases: on the filippoangeloni.com website, the home page went from around 270 KB to around 21 KB by removing the page builder and plugins and switching to static pages. We did the same work, on a larger scale, for Athena SCF.
What can I fix myself and what needs a developer?
Some things you can do yourself, without touching any code. Others are best left to someone who knows how to roll back if something breaks.
| Task | Yourself | With a developer |
|---|---|---|
| Resize and compress photos before uploading them | Yes | |
| Deactivate and delete plugins you don’t use | Yes, after a backup | |
| Remove sliders, autoplay videos and social widgets from the home page | Yes | |
| Convert images to WebP or AVIF and load them only when needed | With a plugin, carefully | Better |
| Set up caching without breaking forms and the shopping basket | Yes | |
| Reduce CSS and JavaScript, load third-party scripts later | Yes | |
| Replace the page builder or the theme | Yes | |
| Change hosting or configure the server | Yes |
Before touching anything, take a full backup. If you don’t know where your website’s backups are, that alone is a sign you need someone looking after it: it’s part of our WordPress maintenance.
Where to start: the 5-step checklist
- Measure the home page and your most important page on PageSpeed Insights, mobile tab. Save a screenshot.
- Check the images: in the list of suggestions, look for the ones flagged as too large and replace them with smaller versions.
- Clean up your plugins: back up, then deactivate and delete the ones you don’t use.
- Look at third-party scripts: ask yourself whether the chat, the map and the Instagram feed are really needed on every page.
- Measure again after a few days and compare with the screenshot. Real-user data takes up to 28 days to update fully.
If the values are still red after these steps, the problem lies in the theme, the code or the server.
Why does website speed matter to Google and to customers?
For Google, Core Web Vitals are one of the signals used to rank results. However, Google’s own guide to page experience makes clear that relevance comes first: Google shows the most useful content even if the page isn’t perfect, and a good score on its own doesn’t guarantee the top spot.
For customers, on the other hand, speed makes a difference straight away. As web.dev sums it up, sites that load quickly and respond to taps hold on to their visitors better, while slow ones lose enquiries and sales. This matters even more if you pay for advertising campaigns: every click on a page that won’t open is a cost with no return.
A fast website also helps with AI assistants: light pages in simple HTML are easier to read for the systems that cite them.
Is it better to fix it or rebuild it?
It depends on how heavy the foundations are. If the problem is images and a few plugins, targeted work is enough. If the site relies on a page builder, a theme that is no longer updated and dozens of plugins, rebuilding it sometimes costs less than chasing the problems.
If you’d like an opinion backed by numbers, ask for the free audit: we measure your website, tell you what is slowing it down and whether it’s worth acting on. The optimisation work itself is described on the website speed page, with starting prices on the pricing page. We can look at it together at our office in Perugia or on a video call.

Comments
No comments yet. Questions and experiences are welcome.