Why a Website Opens Slowly

The three feelings do not go to the same repair. If the cover arrives late, the place to look is the image and the server's first reply. If a button lags, the place to look is code added to the page later. If a line shifts, the place to look is an image with no space reserved, or a banner that arrives late. Which feeling matches which name in a measurement, and what threshold counts as good, is the other article's job. There is no threshold table here.

Opening the page once and finding it fast is not a diagnosis either. The same page can wait differently on a phone, on a thin connection. Walking the job on a phone is a separate test. That test looks at whether the job finishes. This article looks at the wait.

When a visitor opens the page they wait for a frame. If that frame is still the size it left the camera, the wait is the file's time, not the design's. A photograph that looks small on the screen downloads the large file if the file is large. Shrinking the frame does not shrink the download.

web.dev writes that, for images, the fastest request is the one never made. Leaving images that will sit below the screen until later lightens the first open. The same delay, placed on the cover that is visible as soon as the page opens, makes the cover late on purpose. The time a visitor spends looking at an empty area comes, on many pages, from that decision.

A slideshow, a video that plays itself in the background, and several covers stacked on each other share the same first second. The visitor sees one. The others still queue to download. An image that does not stand on the first screen is still charged to that screen's wait.

A chat bubble, a map, a heat map, an extra counter, an experiment tool. These are not the site's sentence. They are code from other services, added later. web.dev names third-party scripts as a common cause of slowdown. It gathers the cause in two places: many requests going out to other servers, and JavaScript keeping the main work busy. When the script comes from somewhere you did not write, the page can be light and the wait still belongs to that code.

One of the routes web.dev lists is to remove a script that does no clear job. The other routes are that the script should not hold up the drawing of the page, and that the page should not stay tied to a slow outside server. This article does not give the code for those routes. The question it gives is what this code shows the visitor. If the answer is only that it was added once, the code is the page's load more than the page's job.

If a map does not show where the office is, a picture can do the same job. If nobody watches the chat, the bubble only covers the button. If a counter is not read, it can leave the first second. Each one looks small alone. Together they fill the time a click waits.

Before the page is drawn, the server's first reply is waited on. Its name is TTFB, the time to the first byte. web.dev does not write it as a Core Web Vitals measurement. As a rough guide it says most sites should aim for a TTFB of 0.8 seconds or less. A value counted as good is 0.8 seconds or under, and a value counted as poor is over 1.8 seconds. The same page also writes that meeting the good threshold is not required on its own. The threshold is not a decision by itself, as long as it does not stretch the experience that follows.

A redirect is added to this time. If the address bar changes once or twice before the page arrives, the visitor is stopping at other addresses first. web.dev writes that field data shows the redirect, while the lab often measures the final address and can miss this extra time. A lab result that looks fast may not be describing a visit in which the address jumps.

If the server is far, if a cache is not held, or if every open builds the page from scratch, the first reply lengthens. Separating those is measurement work, and the names are in the other article. The sign seen here is that the page is late to start even while it is empty. If the blank lasts a long time before the image downloads, the wait is in the first reply, not in the file.

When loss and waiting sit side by side, the cause gets reduced to one word. The scene below is there to show three causes standing on the same page. It is not a client record.

The items below are not a repair recipe. They are the observation written down before it is handed to a developer. Without the observation, the repair is a guess. A guess can also end by adding yet another piece of code to the page.

At N2 Creative we think it is right, in site and software work, to open the sentence the site is slow with this observation. The names and the thresholds stay in the measurement article. What stays here is the thing the visitor waited for.