“My website is slow” can describe several different problems. The first HTML response may take too long, or the browser may receive the page quickly and then wait for images, scripts or fonts. A single page may be affected while the rest of the site is fine. Work out which delay you are seeing before changing the host, plugin or code.

A useful diagnosis starts with two questions: how long does the browser wait for the page response, and how long until the main content appears? Those measurements point to different parts of the stack.

Make a repeatable baseline

Choose one page that feels slow and test it more than once. Use the same device, browser and network for each comparison. If the issue appears only on a phone or only for visitors in one region, record that too. A result from a laptop on fast Wi-Fi may not explain what a mobile visitor sees.

Open Chrome DevTools and select the Network panel. Reload the page and inspect the main document request, then look at the requests that follow it. Note the time spent waiting, the size of large files and whether a particular image, script or font takes much longer than the rest. Repeat on a second page so you can tell whether the problem is page-specific or site-wide.

Run one test with a warm cache and one with a fresh browser cache if you need to compare first visits with repeat visits. Keep the conditions written down; otherwise, a faster result may simply come from a file the browser already has.

Separate server response from page rendering

Time to First Byte (TTFB) measures the time until the browser receives the first byte of a response. It reflects connection setup and server responsiveness, but it is not a direct measure of CPU speed. DNS lookups, redirects, network distance, TLS setup and application work can all contribute to the wait.

Largest Contentful Paint (LCP) measures when the largest image or text block in the visible area is rendered. Web.dev considers an LCP of 2.5 seconds or less good at the 75th percentile of page loads. That field measure is more useful than assuming one lab test represents every visitor.

  • Slow first response: investigate the route, cache behaviour, application work, database queries and hosting resource limits.

  • Fast first response, late visible content: inspect the main image, render-blocking CSS, JavaScript, fonts and third-party requests.

Read the request waterfall

The Network panel lays out requests over time. If the main HTML document is delayed, later assets cannot start until that response arrives. If the document arrives promptly but a large image starts late or takes a long time to download, focus on the image request and the chain of files that must load before it.

Compare a slow route with one that loads quickly. If only a search page or account dashboard is slow, the difference may be in the work that route performs. If the home page, posts and other dynamic pages all slow down together, look for a shared cause such as a cache miss, a busy database, resource contention or a network issue. These patterns narrow the search; the waterfall does not identify the underlying cause by itself.

Check file sizes as well as timings. A large hero image can delay the largest visible content even when the server responds promptly. A chain of scripts can also hold up rendering. If the page is slow only on a first visit, check which files are fetched before anything is displayed and which ones can be postponed until later.

When the first response is slow

Compare several URLs and note whether the delay affects cached and uncached pages alike. If one page is an outlier, ask a developer to inspect its database queries, external API calls and plugin work. If many dynamic pages are slow at the same time, review application logs and ask the host about recent CPU, memory or process limits. A high TTFB alone does not prove that you need a new hosting plan.

Static files can help as a comparison. If an image or stylesheet loads quickly but the HTML document does not, the delay is more likely in the request path or page generation than in the file transfer itself. If everything is slow, consider the network, DNS, CDN and origin together.

When the browser is the bottleneck

If the HTML arrives quickly, look at the largest above-the-fold image first. Resize it to the space it occupies, use a suitable image format and avoid loading several large assets before the main content. Then check whether CSS, JavaScript, custom fonts or third-party widgets block rendering. Remove or defer files only after confirming that they are responsible; changing several things at once makes the result hard to interpret.

Change one thing, then measure again

Start with the largest confirmed delay. Resize an oversized image, remove a script the page does not need, check whether a dynamic page can be cached, or investigate a slow query. Retest the same page under the same conditions and compare the waterfall. If the first document request remains slow across routes and tests, share the URLs and timing details with your host.

A faster server may help when the evidence points to server response or resource limits. It will not fix a slow image, a long script chain or an external service that holds up the browser.

Sources: web.dev's TTFB guide, web.dev's LCP guide and Chrome DevTools Network documentation.