Why is your website slow to load? Eight causes and how to spot them.

The most common reasons a website loads slowly are a server that responds late, an address that redirects several times, large images, style and script files that hold up the page, too much JavaScript, third-party code, web fonts and the phone’s processor. Which of these applies to your site is found not by guessing but with three free tools: PageSpeed Insights, Search Console and the browser’s Network tab.

“The site is slow” sounds like a single complaint, but visitors experience three different things as slowness: the screen staying blank for a long time, the page responding late to clicks even once it has arrived, and the content jumping around while it loads. Google measures these three separately under the name Core Web Vitals: how long the main content takes to appear (LCP), how long the page takes to respond to an interaction (INP) and layout shift (CLS). According to web.dev, the thresholds counted as good are 2.5 seconds, 200 milliseconds and 0.1 respectively; the measure checks whether the threshold holds for 75 percent of visits.

This article was written with the question of the person who commissions the site in mind: how do I find out why it is slow, and what do I ask my web team? For each cause there is a check you can do on your own. The technical details are in the web performance guide; if you would like us to do the measuring and fixing, the site speed optimization page describes the method.

Which tools do you use to look at slowness?

Three free tools are enough, and each answers a different question. The first is PageSpeed Insights: you enter the page’s address; the upper section shows data from the last 28 days collected from real Chrome users, and the lower section shows a lab test run on a single simulated phone. The score from 0–100 in the lower section changes a little on every run; we explain why in how to measure site speed.

The second is the Core Web Vitals report in Search Console. It looks not at a single page but at the whole site: it sorts addresses into groups of similar pages labeled poor, needs improvement and good, and reports mobile and desktop separately. This is where you see which family of pages has a problem. The third is the Network tab in the browser’s own developer tools: in Chrome it opens with F12, and when the “Disable cache” box is checked and the page is reloaded, every downloaded file is listed as one row; the summary line at the bottom gives the total number of requests, the data transferred and the load time.

1 · Is the server responding late?

The time between the browser requesting the address and the first byte arriving from the server is called Time to First Byte (TTFB), and the rest of the page is stacked on top of it. web.dev recommends that most sites aim for 0.8 seconds or less. Typical reasons for it taking long are a crowded shared server, a setup that rebuilds the page from the database on every request, and a server far away from the visitor.

How to spot it: in the Network tab, the top row of the list is the page itself. Click it and go to the Timing section; the “Waiting for server response” row shows this time. If it is consistently long across several reloads, the problem is not the design but the server side. Details: TTFB and server response.

2 · How many times does the address redirect?

When a visitor types “http://firmaniz.com”, the browser may first be redirected to https, then to the www address, then to the address with a trailing slash. Each redirect is a separate round trip, and the page has not even been requested yet. Old campaign links and addresses from a previous site make this chain longer.

How to spot it: in the Network tab, check the “Preserve log” box and type the address in its longest form, with http and without www. Rows with 301, 302, 307 and the like in the Status column are redirects; if there is more than one before you reach the page itself, there is a chain. On 22 August 2026, Google knew 93 addresses for this site, while the site had 58 pages: the difference was the same pages without www, on http, without a trailing slash and ending in “/index.html.” All of them were consolidated onto a single address with permanent redirects.

3 · Are the images larger than they need to be?

If a photo shown a few hundred pixels wide on a phone screen has been uploaded at the size it came out of the camera, the visitor downloads pixels they never see. The largest image on the page is often also the LCP element; if it arrives late, the page counts as having loaded late.

How to spot it: the diagnostics section of PageSpeed Insights shows which element is the LCP element. In the Network tab, select the Img filter and sort by the Size column, and the heaviest files rise to the top. If a single image weighs more than the rest of the page combined, that is the first place to look.

4 · Is the page waiting for a file?

The browser does not draw anything on screen until it has downloaded and processed the style files and some of the scripts called at the start of the page. These are called render-blocking resources. The more of them there are, and the more of them come from different servers, the longer the blank screen lasts.

How to spot it: PageSpeed Insights lists these files separately in its diagnostics section. In the Waterfall column on the right of the Network tab, you can see how many style and script files are downloaded before the page is first drawn; a long staircase means a waiting page.

5 · Is there too much JavaScript on the page?

The cost of JavaScript is not just downloading it: the phone parses, compiles and runs it, and in the meantime the page cannot respond to clicks. The user’s feeling of “I clicked but nothing happened” often comes from here and shows up in the INP measure. Slideshows, animation libraries and page builders are typical items that inflate the JavaScript load.

How to spot it: with the JS filter in the Network tab you see the total script size. The Coverage panel in the developer tools shows how much of the downloaded code is never used on that page. Total Blocking Time in the lab section of PageSpeed is the lab equivalent of this load. The way to set an upper limit: JavaScript budget.

6 · How much load does third-party code add?

A live chat bubble, ad and analytics tags, an embedded map or video, a social media feed: all of these come from another company’s server, and you do not control their speed. Each may look small on its own, but together they can be the heaviest part of the page.

How to spot it: in the Network tab, right-click a column header and turn on the Domain column. Rows from anything other than your own domain are third-party code; here you count how many there are and how much data they download. The question to ask is not technical but commercial: does each of them deliver business value, and is it needed on every page?

7 · Are the fonts holding things up?

Brand fonts are lovely, but every family and every weight is a separate file. Until the file arrives, the text is either not shown at all or drawn in a fallback font and swapped later; in the second case, lines shift.

How to spot it: select the Font filter in the Network tab and look at the number of files. If, when you open the page on a slow connection, you see the text appear only after a delay, or lines move as the font changes, this is the cause.

8 · Why is it fast on desktop but slow on a phone?

The same page is usually slower on a phone, and the main reason is not the network but the processor: a mid-range phone runs the same JavaScript far more slowly than a laptop. That is why measuring on desktop and saying “we’re fast” is misleading.

How to spot it: when PageSpeed Insights opens a result, it shows the mobile tab; compare it with the desktop tab. Search Console also reports mobile and desktop separately. If the gap is large, prioritize the fifth and sixth causes above.

What if the page loads fast but jumps around?

That is not slowness but layout shift, yet visitors experience it as a bad experience too: the line they are reading moves, and they press something else instead of the button they wanted. The most common causes are images without declared dimensions and banners that settle in later. If you paste the source code of part of your page into the layout shift risk checker, the tool lists, one by one, the images, videos and frames that have no space reserved in advance.

Why measure instead of guessing?

Because the cause of slowness is often not where you look first. On this site, after one round of work, the home page’s blocking time suddenly rose; the first suspect was the JavaScript added in that round. The browser trace said something else: about 70 percent of the total blocking time came from a single CSS selector, and that selector painted nothing at all on that page. The full story is in how a :has() selector affected blocking time.

We saw the same lesson from another angle: when the two libraries that controlled scrolling on the site were removed, compressed JavaScript dropped from 51.1 kilobytes to 33.5 kilobytes, because the browser itself could do that job. Today this site’s median lab performance score is 99, the median Total Blocking Time is 21 milliseconds, lab layout shift is 0; the worst LCP measured from the live address with a real Chrome browser is 420 milliseconds. The limit we set ourselves is 0.8 seconds, and it is measured before every release.

The cause of slowness is not guessed; it shows up in the trace.

What should you do once you have found the cause?

The order matters. First, check in Search Console which measure is failing, in which page group, and whether on mobile or desktop. Then open a page from that group in PageSpeed Insights and read the diagnostics section. Finally, use the Network tab to confirm which of the eight causes above stands out. If your site is built with WordPress, the method for separating the share of plugins, theme and server is in a separate article: WordPress site loading slowly.

When you talk to your web team or an outside specialist, these questions help:

• Which measure is failing — LCP, INP or CLS — and does this come from field data or a lab test?
• Which page group has the problem, and is it on mobile or desktop?
• What are you basing the cause on — a browser trace or a guess?
• After the fix, will the same measurement be repeated under the same conditions?
• What will stop speed from degrading again when a new plugin or image is added?

The last question is the one most often skipped. If speed is fixed once and then left alone, every new plugin and every new campaign image takes a little of it back. The lasting solution is to write down limits the site may not exceed and to measure them with every release.

If you want your own site measured and fixed at the source, our Core Web Vitals optimization starts from real-user data and delivers LCP, INP and CLS against a budget.