Load time: why it matters for your website

Speed is not a feeling but something you can measure. Google assesses three metrics that together describe how a page feels to real visitors. They differ in what they measure, and therefore also in their causes and remedies.

You should distinguish two kinds of measurement: lab data is produced in a simulated test (for example in PageSpeed Insights or Lighthouse) and is good for troubleshooting. Field data comes from real visitors and shows how the page is actually experienced. The two can differ; looking only at the lab result can give you the wrong picture. Measure on mobile and more than once, because values fluctuate.

An image is made up of pixels. The more pixels, the more data. A photo straight from a camera or phone often has several thousand pixels in width, whereas only a few hundred to a few thousand are usually needed on screen.

Five steps for images

1. Create suitable dimensions. One variant for each display size, not the original file.
2. Choose a modern format. WebP or AVIF are usually much smaller than JPEG at the same quality, with a classic format as a fallback for old browsers.
3. Weigh up the compression. Light compression is barely visible to the naked eye but saves a lot. Check important images on screen.
4. Lazy loading. Images below the visible area are only loaded when the visitor scrolls towards them. The first large image, by contrast, is not: it should arrive immediately.
5. Specify the size. Width and height in the code, so the browser reserves space and the page does not jump.

How to look after images over the long term without having to think about it every time is described in the guide Optimising images for your website. Questions of design are covered in Imagery and photos.

Not everything can be solved in the page content. The way a server delivers files also determines how quickly a page starts. The most important points:

Server response time. How long the server takes to respond at all. With dynamic systems (such as WordPress), the server rebuilds the page on every request unless a page cache is active. Statically generated pages are ready and waiting and are delivered almost instantly.

Compression. Text files (HTML, styles, scripts) can be made much smaller before transfer. Methods such as gzip or Brotli are standard and should be switched on.

Cache headers. With suitable settings, the server tells the browser how long it may keep files such as the logo, styles and images. On repeat visits there is then no need to load them again. Pages that change often get shorter times so that changes come through.

Current protocols. HTTP/2 and HTTP/3 bundle many requests more efficiently than earlier versions. Most hosts offer them; it is worth checking.

Location and delivery network. A server close to the visitors responds faster. A content delivery network (CDN) distributes files across many locations. For regional businesses with visitors in Germany, a good host in Germany is often enough; for an international audience a CDN is worthwhile, but it should be assessed from a data protection point of view.

Hosting plan. Very cheap plans share resources with many other sites. If the response time is permanently high, a change can help, but only once images and scripts are in order.

This is what an optimisation project for a company website might look like. It is a pattern, not a series of measurements with invented results.

1. Baseline measurement: measure the five most important pages (home page, two services, contact, one guide) on mobile. Record the values, the date and the device.
2. List of causes: for each page, note the three biggest bottlenecks (for example: hero image too large, chat script, three font styles).
3. Sort the levers by effort and impact: adjust images (low effort, big impact), remove a third-party script (low effort, medium impact), set up a server cache (medium effort, big impact on systems with a database), reduce font styles (low effort, small impact).
4. Implement in small packages: measure again after each package. That way you can tell what achieved how much.
5. Final measurement and documentation: the same pages, the same device, several runs. The results go to you, with a note of what is still open.
6. Repeat after changes: after every major addition (new page, new plug-in, new image collection), briefly check the core pages.

The order prevents the most common mistake: spending months polishing details while a single oversized image determines the result.

1. Open PageSpeed Insights, enter the address of your home page and choose the mobile view. Note LCP, INP and CLS.
2. Look at the list of recommendations and find the three that are meant to save the most time. Images are usually at the top.
3. Open your page on your phone over the mobile network. How long does it take until you can read?
4. Check in the source code (right-click, view page source) whether scripts are loaded from third-party servers. Look for the addresses of outside providers.
5. Test a page with many images, for example your references. How quickly do the first images appear, and how quickly the last?
6. Tap a menu item while the page is still loading. Does it respond immediately?

If you would like help with the evaluation, a measurement including a list of measures is offered separately and described in the quote (projects start from €2,500). Closely related is the technical side of search engine optimisation, see Technical SEO.

Pages get heavier over time: an image here, a script there. A performance budget sets limits so that this does not creep up unnoticed. It consists of a few clear rules known to everyone who publishes content.

• Images are uploaded only in prepared sizes; a maximum file size applies to every photo.
• New scripts or plug-ins need a justification and are measured on a test page beforehand.
• Videos do not play automatically and are loaded only after a click.
• No more than one large hero element is used on each page.
• Core pages have target values (for example the green ranges of the Core Web Vitals), which are checked quarterly.
• Breaches are not reprimanded but fixed: whoever finds an oversized image replaces it and reports it.

The budget does not protect against every mistake, but it makes the subject visible. The team understands that every addition sets off a time calculation.

Changing host is a bigger decision than optimising an image. It is worthwhile in these cases:

1. The server response time is permanently high, even on a slimmed-down page with the cache active.
2. The plan limits resources so heavily that peak times lead to error messages.
3. The host offers no current PHP version, no HTTP/2 or no way of setting cache options.
4. The location is far from your target audience, and delivery via a network is not an option.
5. Security or data protection requirements are not met, for example a data processing agreement is missing.

Before changing, check the contract term, migration support and how your domain and email addresses will move across. Have the move planned so that there is no downtime. Aftercare is described under Website maintenance.

TTFB (Time to First Byte)

The time until the server delivers the first byte of the response. Shows how quickly the server reacts.

Render-blocking

Files that the browser must load before it can display the page.

Lazy loading

Loading images only when they are needed.

Cache

Temporary storage: files that have already been loaded are reused.

Minification

Removing unnecessary characters from code files to make them smaller.

CDN

Content Delivery Network: a network of servers that delivers files close to the visitor.

Main thread

The part of the browser that executes code and builds the page. When it is busy, the page responds with a delay.

Field and lab data

Measured values from real visitors as opposed to measured values from an artificial test.