All posts
Engineering 4 min read

Why your website loads slowly

Almost every slow website has the same four causes. None of them needs a relaunch, and the first one is usually done in an afternoon.

When a website is slow, the backend is rarely the reason. In almost every case I have come across, the delay traced back to four things, and none of them required a rebuild. This post works through them in the order that pays off.

The four causes, in order of impact

  1. Images at original size

    A photo straight out of the camera is several megabytes and wider than any screen needs. Embed it unchanged and the visitor downloads the full file for the browser to scale down. On home pages, images are the single largest share of page weight, ahead of JavaScript and fonts1. Starting here is not a matter of taste, and the work is mechanical: right size, modern format, defined loading behaviour.

  2. Scripts that block rendering

    Analytics tools, chat widgets, font loaders: a <script> without defer or async stops the parser, downloads, executes, and only then does parsing resume2. Much of it can be deferred, some of it dropped entirely.

  3. Missing caching

    Without the right headers every visit reloads everything, including files that have not changed in months. A missing Cache-Control header does not switch caching off, by the way, it leaves the browser to guess how long to keep a response3. This is pure configuration and costs nothing beyond the time to set it once.

  4. Too many font weights

    Four typefaces at three weights each is twelve files. On a median mobile home page, fonts alone account for around 111 KB of weight4. Fonts do not block rendering as such, but by default the browser renders text in an invisible fallback while the file is still missing, rather than swapping in a substitute5. Two weights are enough for almost any project, and font-display: swap takes the edge off the rest.

The difference between a slow website and a fast one is usually not a better server, but less ballast.

Measure, or you optimise blind

Measure before and after. Without a baseline there is no way to say whether a change did anything, and it is easy to keep optimising in the wrong place.

  • A baseline exists before the first change is made
  • Testing happens on a throttled connection, not on office wifi
  • The page measured is the one visitors actually land on
  • Each measure is re-tested on its own, not all of them at the end

What this has to do with visibility

Load time does feed into ranking. Google states plainly that Core Web Vitals are used by its ranking systems, while other aspects of page experience do not directly help a page rank higher6. A perfect score on its own is not a lever.

The more tangible part is visitor behaviour anyway. Nobody waits long in front of a blank page, and a visitor who leaves before the first content appears never shows up in a conversion report.

  • Four causes explain almost every slow website.
  • Images first: on home pages that is where most of the page weight sits.
  • On inner pages JavaScript is usually the larger item.
  • Caching is configuration, not development work.
  • Measure before and after each change, or you optimise blind.

Sources

  1. HTTP Archive, Web Almanac 2025, Page Weight chapter. The median home page weighed 2.86 MB on desktop and 2.56 MB on mobile, with images accounting for the most bytes on both.

  2. MDN, Render blocking and Critical rendering path.

  3. Google, Prevent unnecessary network requests with the HTTP Cache, and MDN, HTTP caching.

  4. HTTP Archive, Web Almanac 2024, Page Weight chapter. Median mobile home page: 900 KB images, 558 KB JavaScript, 111 KB fonts, 73 KB CSS, 18 KB HTML. On inner pages JavaScript outweighs images.

  5. MDN, font-display. During the font block period an element using the font renders an invisible fallback face.

  6. Google Search Central, Understanding page experience in Google Search results.

Check your website for free: load time, accessibility and SEO in two minutes

Read next

The tab test: ten minutes to find out where your website breaks Accessibility6 min

A question about one of these topics? contact@primaris.at