How to Check If Your Website Is Actually Slow

October 17, 2026 • NOFYI Editorial Team

Your website feels slow, but is it actually slow? A site that feels sluggish on your laptop may load quickly for most visitors, and a site that feels fine to you may be frustrating for someone on a slow mobile connection. Feelings are a starting point, not a measurement.

To know whether your site is actually slow, you need to test it in a consistent way, look at the right metrics, and compare results from realistic conditions. This guide explains how to do that. It covers the metrics that matter, a step-by-step test you can repeat, a worked example, and the most common fixes: caching, images, and careful priorities. It ends with honest limitations and answers to common questions.

What Slow Really Means

Slow is not one number. A visitor experience has several stages. The browser must find the server, wait for the first response, download the page, and render the content so it can be read and used. A delay at any stage can make the site feel slow, but the fix depends on which stage is slow.

Two metrics are especially useful for beginners, because they separate server delay from page rendering delay.

TTFB: Time to First Byte

TTFB measures how long the browser waits before it receives the first byte of the response. It reflects server response time, DNS

Other metrics can help once you understand the two above. First Input Delay and its successor Interaction to Next Paint describe how quickly a page responds when a visitor taps or clicks. Cumulative Layout Shift describes how much the visible layout moves as the page loads. A page can load quickly and still feel broken if buttons jump just as a visitor tries to tap them. Total page size and number of requests describe how much the browser must download, but they are causes, not experiences. Focus on what the visitor sees and feels first, then use size and request counts to explain why.

How to Test Your Site Properly

Follow the same steps each time so results are comparable. Testing once from one device is a snapshot, not a diagnosis.

Test in a private or incognito window to reduce the effect of extensions and logged-in state. Extensions c

Worked Example: A Blog Post That Feels Slow

Imagine you run a small blog. A reader says your most popular article takes forever to load on their phone. On your laptop, the same article feels fine. You decide to test properly instead of guessing.

First, you open PageSpeed Insights and test the article URL. On mobile, the report shows an LCP of 4.8 seconds and a TTFB of 1.1 seconds. On desktop, the same page shows an LCP of 2.1 seconds and a TTFB of 0.6 seconds. The difference tells you something useful. The server is not extremely slow, but the mobile experience is much worse. That points to page weight, images, and rendering rather than only the server.

Next, you look at the details. The report lists a hero image that is 2.4 megabytes and wider than any phone needs. It also lists three scripts that block rendering, including a chat widget a

Caching: Why a Second Visit Is Faster

Caching stores a copy of a page or resource so the server does not have to build it from scratch each time. Browser caching lets a visitor device reuse images, styles, and scripts on repeat visits. Page caching lets the server store a ready-made HTML page and serve it quickly, instead of running database queries for every visitor. Object caching stores pieces of data that are expensive to compute.

Caching helps most when a page is expensive to build and changes rarely. A blog article that is updated once a month is a good candidate. A shopping cart page that is different for every visitor is not. If you use caching, make sure you can clear the cache when you update content. A common beginner mistake is to update a page, check it while logged in, and not realise that visitors still see the old cached version until the cache expires or is cleared.

Content delivery networks, or CDNs, are a form of caching spread across locations. A CDN stores copies of static files in servers close to visitors, so a visitor in one country does not have to fetch every image from a server in another country. A CDN helps with distance and with large files, but it

Frequently Asked Questions

What is a good LCP time?

As a general guide, an LCP under 2.5 seconds is considered good for most pages. Between 2.5 and 4 seconds needs improvement, and over 4 seconds is poor. These are guides, not guarantees. A page that meets the target on desktop may still be slow on a low-end phone, so test on mobile.

What is a good TTFB?

A TTFB under about 0.8 seconds is often used as a rough target for a responsive server, with lower being better. A TTFB over 1.5 seconds usually deserves attention, especially if it affects many pages. A low TTFB does not guarantee a fast page, because images and scripts can still delay LCP.

Why is my site fast for me but slow for visitors?

You may be logged in, close to the server, on a fast network, or seeing a cached version. Visitors may be farther away, on mobile data, on slower devices, or visiting for the first time. Test in a private window, on mobile, from a location near your audience, and with cache cold to see the visitor view.

Will installing more speed plugins make my site faster?

Not necessarily. Speed plugins can help with caching, compression, and optimisation, but too many can conflict, add overhead, or hide the real cause. Fix the largest cause first, such as images or render-blocking scripts, and add tools one at a time, measuring after each change.

Conclusion

To check if your website is actually slow, test it the way visitors experience it: on mobile, in a private window, several times, and on the pages that matter. Look at TTFB to judge server response and LCP to judge when main content appears. Work through the largest causes first, especially images, caching, and heavy scripts.

Do not chase a perfect score. Aim for a fast, stable, usable page that loads its main content quickly and responds promptly. Measure before and after each change, and keep notes. That habit turns speed from a vague feeling into a problem you can see, explain, and improve.

Do Not Chase a Perfect Score

Speed tools give scores, and scores can be addictive. A score of 100 is not a requirement for a good site, and a score of 100 does not guarantee that visitors are happy. Scores change with test conditions, tool versions, and third-party scripts. A site with a score of 85 that loads its main content quickly and responds promptly can feel better than a site with a score of 95 that still delays its main heading.

Use scores as a guide, not a goal. Set a target that matches your audience and your content. For example, aim for LCP under 2.5 seconds on mobile for your most important pages, and for a stable layout with no large shifts. If a change improves LCP but drops an unrelated score by a point, that trade-off may still be worth it. If a plugin promises a perfect score by hiding content or delaying important scripts, ask whether it improves the real experience or only the test.

Third-party scripts deserve special attention. Analytics, ads, chat widgets, social embeds, and video players can each add weight. Audit them once a quarter. Remove tools you no longer use. Load the remaining ones after the main content when possible. One heavy widget can undo the benefit of all your image optimisation.

Limitations

Speed testing has limits, and honest reporting should name them.
- Lab tests simulate a device and network. Real visitors use many devices, networks, and locations, so lab results are estimates, not exact experiences.
- Field data from real users is more realistic, but it is noisy and arrives slowly. It may not show the effect of a change for days or weeks.
- Scores vary between runs. A difference of a few points between two runs may be noise, not improvement.
- Optimising for a tool can distort priorities. A fast score does not fix confusing content, broken links, or a poor checkout flow.
- Hosting, theme, and plugin limits matter. A very cheap shared host or a very heavy page builder may limit how fast a page can become without a larger change.
- Caching can hide a problem during testing. A page that is fast when cached may be slow on the first build after a cache clear.
Because of these limits, test several times, test from realistic conditions, and judge a change by LCP, TTFB, and real visitor behaviour, not by a single score.

does not fix a slow database query or a badly built page.

Images: The Most Common Cause of Slow Pages

Images are often the largest part of a page. A photo taken on a modern phone can be several megabytes. Uploading that file directly to a blog post means every visitor must download several megabytes, even if the image is displayed at a small width.

Good image habits are straightforward. Resize images to the largest size they will actually be displayed at. Compress them with a reputable tool or plugin, and choose a modern format when your platform supports it. Use lazy loading so images below the fold do not block the first view. Add width and height attributes so the browser reserves space and the layout does not jump. Use a featured image that is large enough to look sharp, but not larger than the theme needs.

Do not rely on the browser to shrink a huge image. A 4000-pixel image displayed at 800 pixels still downloads the full file unless you serve a smaller version. Responsive images, which let the browser choose a suitable size, solve this problem. Most modern WordPress setups generate several sizes automatically, but you should still start with a sensibly sized upload.

nd two tracking scripts. The image is the largest visible element, so it drives LCP. The scripts delay the moment the browser can paint the content.

You make three changes. You resize the hero image to a sensible width, compress it, and serve a modern format. You remove one tracking script you no longer use. You defer the chat widget so it loads after the main content. You do not change the hosting or the theme.

You test again three times on mobile. The LCP falls to 2.4 seconds, and the TTFB stays near 1.0 seconds. The page feels faster, and the numbers support that feeling. You note the before and after values in a simple log, so you can compare again next month.

This example shows the right order. Measure first, find the largest cause, fix that cause, then measure again. If you had started by buying a bigger hosting plan, you might have spent money without fixing the image and scripts that were actually driving the slow LCP.

an slow a page and distort results.
Test on mobile, not only on desktop. Many visitors arrive on phones with slower processors and slower networks. Use a mobile test setting or a real phone.
Test the same page three times and look at the range, not just one number. Speed varies with network, server load, and cache state.
Test with cache cold and warm. A first visit, when nothing is cached, shows the worst case. A repeat visit shows how caching helps.
Test the pages that matter: the home page, a popular article, and a page with a form or checkout. A fast home page does not prove that a heavy product page is fast.
Test from a location close to your audience. A site hosted far from its visitors will look slower from that region, even if it is fast near the server.
Write down the date, device, network, page, TTFB, LCP, and overall score. Without notes, you cannot tell whether a change helped.

Free tools from Google, such as PageSpeed Insights, and independent tools such as WebPageTest, can run these tests and show filmstrips of how the page loads. Use them to compare before and after a change. Do not rely on a single score from a single run.

lookup, connection time, and redirect time. A high TTFB often points to hosting, server configuration, uncached database queries, or a distant server. A low TTFB does not guarantee a fast page, but a very high TTFB makes a fast page almost impossible.

LCP: Largest Contentful Paint

LCP measures when the largest visible content element, such as a hero image or main heading, becomes visible. It reflects how quickly a visitor can see the main content. A slow LCP can be caused by a slow server, a large hero image, render-blocking scripts, or a late-loading font. LCP is useful because it matches what a visitor notices: when does the page look ready?