What actually makes a website feel slow

If your site feels slow, a speed “grade” or score won’t tell you why. Here’s how to trace real performance bottlenecks using Core Web Vitals, TTFB, and the browser’s own timeline.

A visitor lands on a campaign page. The browser shows a blank screen. A moment later, the headline appears, then an image, then the layout shifts as a font finishes loading. The visitor clicks the menu. Nothing happens straight away.

That experience feels slow, even if the site has an attractive performance score.

A score can tell you that something needs attention. It usually can't tell you which part of the request path is responsible, or whether the problem affects every visitor. For that, you need measurements tied to what people actually see and do.

Speed scores are a distraction. User-centric metrics are not

A generic speed grade compresses many technical checks into one result. That makes it useful as a quick warning, but poor as a diagnosis. A site can improve its grade by making changes that have little effect on the page people care about.

Core Web Vitals are more useful because they describe specific parts of the experience. The WP Engine performance architecture guide and Calibre's guide to slow websites both frame performance around metrics such as Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, and Time To First Byte.

Largest Contentful Paint, or LCP, measures when the main visible content appears. On a landing page, that might be the hero image or the main heading. A poor LCP often means the visitor is waiting for the page's actual purpose to become clear.

Interaction to Next Paint, commonly abbreviated as INP, describes how quickly the page responds after a visitor interacts with it. If a menu, filter, form, or checkout control feels stuck, long-running JavaScript may be involved.

Cumulative Layout Shift, or CLS, measures unexpected movement during loading. A button that moves just as someone tries to press it is not a cosmetic problem. It can cause errors and erode trust.

TTFB measures the time between a request being made and the first byte of the response arriving. It gives you an early indication of server, database, caching, or network delays.

These metrics connect technical behaviour to business effects. Late content can reduce engagement. Poor interaction response can interrupt enquiries. Layout movement can cause missed actions.

The rest of this article is about tracing causes. There isn't one magic tweak that fixes every slow site.

Start with symptoms. What “slow” feels like to real users

Begin with the experience, not the audit score.

If the browser shows a white screen for a long pause, suspect a delayed response or a render path that is blocked before visible content can appear. TTFB helps separate server delay from browser work. LCP shows when the main content finally becomes visible.

If the header appears but the main hero content arrives late, inspect the LCP element. It may be a large image, a background image, a custom font, or a stylesheet that prevents the browser from painting the page.

If the page jumps while someone is reading, investigate CLS. Images without reserved space are a common cause. Fonts can also alter text dimensions after the fallback font has already been displayed.

If clicks feel slow, look at INP and the browser's long tasks. A page may look fully loaded while its main thread remains busy processing scripts.

Write down the symptom before opening a tool. “The landing page is slow” is too broad to guide an investigation. “The headline appears late on mobile” gives you a starting hypothesis. So does “the filter responds slowly after the results load.”

The Calibre overview of common slow website causes makes this connection between user symptoms and metrics particularly clear. A diagnosis becomes easier when you know which behaviour you're trying to explain.

Measure the request path. TTFB and server-side delays

TTFB is not a measure of the entire page load. It measures the delay before the browser receives the first byte of the response.

That distinction matters. If TTFB is poor, optimising images won't remove the initial blank pause. The browser cannot render the response until the server starts sending it.

Common causes include slow hosting, an overloaded server, an HTML response that wasn't served from cache, and database queries that take too long. A back-end request to an external service can also hold up the response. Product data, search results, pricing, or personalisation may depend on that service.

You can inspect TTFB in PageSpeed Insights, WebPageTest, or the Network panel in browser DevTools. SiteGrade's audit guide covers these tools as part of a practical performance investigation.

DevTools helps separate network waiting from server processing. Select the document request and inspect its timing breakdown. A long wait before the server begins responding points towards connection or server delay. A request that starts promptly but takes a long time to complete may indicate server processing or a slow response stream.

Compare results from different locations and connection types. A server can appear quick from one region while users elsewhere wait much longer. Real user data is more reliable for understanding that variation.

If the document response is slow for every route, look for a shared cause. Hosting, page caching, the application framework, and database access are more likely suspects than a single image.

Identify what blocks rendering. HTML, CSS, and JavaScript

After the response arrives, the browser has to build and paint the page. It parses the HTML, discovers required resources, calculates styles, and runs scripts that affect the document.

Large stylesheets can delay the first render because the browser needs the relevant styles before it can safely display the page. Synchronous scripts can have a similar effect, particularly when they are loaded early or modify the document during parsing. Both WP Engine and Calibre identify heavy front-end resources as common causes of slow rendering.

Open the Performance panel in DevTools and record a page load. Look for a long gap before the first paint, then inspect the requests active during that period. In the Network panel, sort by timing and check which stylesheets or scripts begin early and remain active.

Coverage can show how much of a stylesheet or script is used on a particular page. A large file with very little executed or applied code may be shared across the site even though the current route needs only a small portion.

Critical CSS can help by placing the styles needed for the initial view directly in the HTML. That removes a request from the early render path. It isn't free, though. Too much inlined CSS makes the document larger and can worsen TTFB. Duplicated styles can also increase the amount of data sent on every page.

The right fix depends on the bottleneck. If the server response is already slow, adding more HTML may make the problem worse. If the response is quick but the browser waits for a large stylesheet, reducing or restructuring that stylesheet may have greater value.

Heavy images and fonts. Largest Contentful Paint’s usual suspects

Images are often the first place to look when LCP is poor, especially on pages built around a large hero area. A source image may be much larger than the dimensions displayed in the browser. The file may also use a format that sends more data than necessary.

Start by checking which element the performance tool reports as the LCP element. Don't assume it's the largest file. It may be a heading, a product image, or a background image applied through CSS.

If the LCP element is an image, inspect its intrinsic dimensions, transferred size, and format. Check whether the browser requested it early enough. A hero image marked for lazy loading can be deferred until after the browser has started looking for content below the fold. That saves work in the wrong place.

Lazy loading should usually target content that starts outside the initial viewport. Applying it indiscriminately can delay the content visitors came to see.

Fonts create a separate set of problems. A font file loaded early can compete with the hero content for bandwidth. A font loaded late can cause text to reflow, contributing to CLS. Font display settings, fallback choices, and reserved text space all affect the result.

SiteGrade's discussion of slow website causes highlights large images and unoptimised assets as practical audit findings. Confirm them in the waterfall rather than changing every image by default. The useful question is whether this asset delays the visible experience.

Third party scripts and trackers. Quiet bottlenecks

A page can contain little application code of its own and still perform badly because of external scripts.

Analytics tools, advertising tags, chat widgets, and social pixels add network requests. Some execute early and compete with rendering. Others run after the page appears but occupy the main thread when someone tries to interact with it.

The Calibre guide identifies third party scripts as a common source of extra work, long-running tasks, and layout changes.

Use the Network panel to group requests by domain. Then record a Performance trace and inspect long tasks on the main thread. If a vendor script appears during the period when LCP is delayed, it may be part of the render problem. If it runs after the page is visible and blocks input, it is more likely to affect INP.

Coverage can help show whether a third party resource is doing useful work on the current page. Treat that result as evidence, not an automatic reason to remove the script. A chat widget may support sales. An analytics tag may be needed for reporting.

The tradeoff is timing. A commercially valuable script may not need to load before the headline and primary action. Deferring it, loading it after consent, or removing it from low-value pages can preserve its purpose without making every visitor wait.

Use the right tools. Lab tests and real user data

Synthetic tests and real user monitoring answer different questions.

PageSpeed Insights and WebPageTest run controlled tests against a selected page. They're useful for reproducing a problem, comparing a change, and inspecting the request waterfall. DevTools adds detail from the browser itself, including layout shifts, long tasks, resource timing, and unused code.

Real user monitoring shows what happens outside the test environment. Devices vary. Networks vary. Visitors may be distributed across regions, and some routes may perform well while others do not. SiteGrade and WP Engine both distinguish controlled testing from performance observed in the field.

A practical workflow starts with PageSpeed Insights for a quick overview of the main metrics. Next, use DevTools on the affected template and inspect the document request, waterfall, LCP element, and long tasks. Then compare the result with field data if your analytics or monitoring setup reports Core Web Vitals from actual users.

Don't treat a single lab run as a universal truth. It is a controlled sample. Repeat tests after changes and check whether the improvement appears in real user data too.

Turn findings into a backlog. Prioritise by impact, not effort

A performance backlog should describe a measured problem, its likely cause, and the metric it affects.

Group the work by where it occurs. Server-side improvements might include response caching, database work, or an external API that holds up HTML. Render-path fixes might include reducing blocking stylesheets or moving nonessential scripts. Asset and third party clean-up might cover images, fonts, tags, and widgets.

Prioritise shared causes over isolated symptoms. An improvement to TTFB across a site may help every route, while resizing an image on a rarely visited template may affect very few people. The WP Engine architecture guide makes this broader point. Performance is often an architectural concern, not a collection of unrelated front-end chores.

Record the baseline before making a change. Afterward, measure the same page and check the relevant metric. A smaller image that improves LCP but causes a visible quality problem may not be a good trade. Inlining CSS that speeds the first render but increases TTFB may simply move the delay.

If you're planning a rebuild, our approach to Next.js performance and Jamstack builds covers how server rendering and static generation can change the request path. If performance is tied to search visibility, Technical SEO and Core Web Vitals support connects the measurements with organic traffic work.

For further technical breakdowns of performance and architecture decisions, you can browse the Stack Innovations blog.

Start with one affected page. Capture its symptoms, TTFB, LCP, CLS, and INP. Inspect the waterfall and the long tasks. Then turn the clearest cause into a measured change.

That gives you a useful next step. A score alone doesn't.