Why is your website slow? Find server and front-end delays with AI

The response takes time

Purpose: Find out what happens before useful content starts arriving.

Possible server-side causes include an expensive database query, a busy application or a slow external service. A database query is a request to retrieve or change stored information. A cache, which reuses a previously prepared response, can affect how much work is needed.

Time to First Byte (TTFB) measures how long it takes to receive the first byte of a response. For a page navigation, it can include redirects, connection setup and network travel as well as server processing. A high TTFB is a clue to investigate, rather than proof that hosting is the cause. See web.dev’s explanation of TTFB.

To narrow this down, compare the browser timing with server logs or monitoring for the same request and time. If you cannot access those records, ask your developer or host for that evidence.

The files arrive late

Purpose: Separate a late request from a slow transfer.

An image can be late because it is large, the connection is slow, or the browser only discovers it after running a script. These need different fixes. Look at when the request starts as well as how long it lasts.

Lazy loading postpones non-essential resources until they are needed. That can help with images further down the page. Applying it to the main image visible immediately can delay content readers came to see. MDN explains how lazy loading works.

The browser has more work to do

Purpose: Check the gap between receiving a resource and showing it.

Downloaded does not always mean visible. CSS can block rendering, which means drawing content on screen. JavaScript can occupy the browser’s main thread, where much of the work needed for scripts and rendering happens. Content may also remain hidden until a script reveals it.

Largest Contentful Paint (LCP) measures when the largest eligible image or text block in the visible area appears. It does not mean every feature is ready. Its breakdown separates TTFB, resource load delay, resource load duration and element render delay. This helps distinguish late delivery from late display. See web.dev’s guide to investigating LCP.

1. Find TTFB in Network

1. Select Network before reloading the page. Check that recording is active. If the list is empty, reload again while this panel is open.
2. Choose the Doc filter to show document requests. Select the main page under Name. For a slow data response instead, use Fetch/XHR and select that request.
3. Open the request’s Timing tab. Find Waiting for server response, sometimes labelled Waiting (TTFB).
4. Record that duration separately from Content Download. The Time column gives the request’s overall duration, rather than just its waiting phase.

Read it carefully: this request-level waiting phase includes network travel and response preparation. Navigation TTFB can also include earlier redirects and connection setup. The screenshot includes Service Worker activity, which can intercept requests; your breakdown may have different rows. Use server-side evidence before concluding that hosting is the cause.

2. Check when an image is requested

1. In Network, choose Img. Reload from the top of the page and find the affected image. Use the Filter box if you know part of its filename.
2. Look across to Waterfall. Compare when the image starts with the document and other early resources. The screenshot is a general waterfall view; it has not yet been filtered to images.
3. Select the image and open Timing to separate waiting from downloading. Use Initiator to investigate what triggered the request.
4. To investigate an image further down the page, scroll towards it and watch for a new request. Keep cache and throttling settings consistent when repeating the test.

What this tells you: a late request start differs from a long transfer. A request appearing near a scroll can support a lazy-loading explanation, but the browser may start fetching before the image becomes visible. Cache hits and custom scripts can also affect what you see.

3. Find an image’s lazy-loading setting

1. Right-click the image on the page and choose Inspect. Chrome opens Elements and highlights an item in the page’s structure, called the Document Object Model (DOM).
2. Find the actual <img> element. If Chrome selected a surrounding link or container, expand it using the small triangle until you reach the image.
3. Look inside that tag for loading="lazy". This asks the browser to defer the image until it approaches the visible area. loading="eager" requests normal loading without that deferral.
4. Check the image’s position and the Network evidence together. If no loading attribute is present, JavaScript may still delay loading or insert the image later. Absence of the attribute does not rule that out.

For example, this is the attribute you are looking for on an image:

<img src="course-image.webp"
     loading="lazy"
     width="800" height="450"
     alt="Course materials">

The code example is separate from Google’s Elements screenshot, which demonstrates node selection. MDN documents the image loading attribute. For a main image visible immediately, investigate whether lazy loading delays it. Do not remove lazy loading from every image as a blanket fix.

4. Find browser work in Performance

1. Open Performance and use Record and reload, the circular-arrow recording control. Let the load recording finish.
2. Find the LCP marker in the recording. It marks the largest eligible visible content appearing, rather than every feature becoming ready.
3. Expand the Main track if it is collapsed. Inspect tasks before LCP and click an event to view its duration and details.
4. Compare this activity with the image’s request timing. If its file has arrived but the content is still not visible, investigate the remaining script and rendering work.

The coloured blocks show different kinds of browser activity. A long task near LCP is a lead to test; timing overlap alone does not establish that it caused the delay. Chrome’s Performance reference explains the recording controls and Main track.

1. Ask for an investigation plan

Purpose: Get a useful next check from the evidence you have.

Help me investigate a slow page. Symptom: the main image appears late. Across three runs with the same test settings, the HTML starts arriving at about 0.4 seconds. The image request starts at about 2.1 seconds and finishes at about 2.5 seconds. The image appears at about 3.4 seconds. These timings are relative to navigation start. Separate observations from hypotheses. Rank three possible explanations, explain what each timing does and does not tell us, and give one check that could support or rule out each explanation. Do not assume the server is the cause.

Those example timings direct attention towards the wait before the image request and the wait after it finishes. They do not establish which script, style rule or loading setting caused either gap.

2. Review the relevant code

Purpose: Understand a proposed change before trying it.

Review the sanitised HTML and JavaScript below against these observations. Identify any code that could delay discovering or displaying the main image. Explain the mechanism in plain English and distinguish evidence from assumptions. Suggest the smallest reversible change to test on a staging copy, list possible side effects and describe how to measure the result. If the evidence is insufficient, tell me what to collect next.

A staging copy is a separate version used to test changes. Include only the code connected to the issue. Ask AI to explain why a change should affect the measured delay, rather than accepting a broad rewrite.

3. Compare the result

Purpose: Check whether the change improved the experience.

Compare these before-and-after measurements from repeated runs under matching conditions. Describe the variation, which loading stage changed and what remains uncertain. Check whether the evidence supports the proposed explanation. Suggest one next test only if there is still a clear unresolved problem.

Check the actual page as well as its timings. An improvement should preserve the image, layout, navigation and any affected interactions. A better score alongside a broken feature is not a successful fix.