Speed up your websiteWhere loading time is really lost - and what helps

Published on October 20, 2026

Measure first, then adjust

Before you change anything, you need a baseline - otherwise you will not know afterwards whether the change helped. Free measuring tools such as PageSpeed Insights or WebPageTest deliver both: a rating and a list of bottlenecks sorted by effect.

Three values are worth a look:

• LCP - when the largest visible element has loaded. Almost always an image, and almost always the value with the greatest potential for improvement.
• CLS - how much the content still shifts while loading. Usually caused by images without size information or ads loaded later.
• INP - how quickly the page responds to clicks. Suffers from too much JavaScript.

Measure on a subpage, not just on the home page - it is often the best-optimized page of the whole site. And measure several times: the first request after a change is regularly the slowest, because nothing is cached yet.

Images: by far the biggest lever

On a typical website, images account for 60 to 80 percent of the transferred data volume. Starting here gains more than everything else combined - and requires no special knowledge.

1. Upload at the right size. The most common mistake of all: a photo 4000 pixels wide is uploaded and displayed at 800 pixels in the layout. The browser still loads all 4000. Scale images beforehand to the size at which they actually appear.
2. Use a modern format. WebP delivers much smaller files than JPEG at the same visible quality. Every current browser displays it, and common CMS generate the variants automatically on request.
3. Compress sensibly. For photos, a JPEG quality around 80 percent is the usual compromise - the difference is hardly visible on screen, but the file is much smaller.
4. Enable lazy loading. Images below the visible area do not have to load immediately. Most CMS set the loading="lazy" attribute by themselves - with one important exception: the topmost image on the page should not get it, otherwise the LCP value gets worse.
5. Specify width and height. If they are in the markup, the browser reserves the space immediately and the content no longer jumps while loading.

A side effect: smaller images need less space. If your plan becomes tight, it is often worth looking at the media library before switching to a bigger one - see How much web space do I need.

Set browser caching via .htaccess

Static files - images, stylesheets, fonts - rarely change. Transferring them again on every page view is wasted time. With an expiry setting, the browser stores them instead and uses its own copy:

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/png "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
    ExpiresByType font/woff2 "access plus 1 year"
</IfModule>

The entry belongs in the .htaccess in the document root - how to create it and what can go wrong is described in the guide .htaccess & redirects.

A point that is often overlooked: long expiry times mean that visitors do not notice changes to a file. If you change a stylesheet, change the file name too or append a version parameter - otherwise returning visitors see the old version for weeks.

PHP version and database

Keep PHP up to date. Between an old and a current PHP version, there are noticeable differences in execution speed for dynamic sites - without you having to change anything on your site itself. You switch the version yourself per domain; the guide is in Change the PHP version. Take a backup beforehand: extensions that rely on removed functions otherwise fail without warning after a version jump.

Clean up the database. With WordPress, the database grows unnoticed over years: post revisions, entries in the trash, leftovers of uninstalled extensions, expired transients. That does not slow things down dramatically, but measurably - and can be cleaned up safely, as long as a backup exists beforehand.

You limit the number of revisions in wp-config.php:

define('WP_POST_REVISIONS', 5);

Clear out instead of upgrading

The least popular but most effective step: run less.

• Remove unused extensions. Do not deactivate them - delete them. Every active plugin loads code on every page view, and deactivated ones remain a security risk because they no longer get updates.
• Check page builder extensions. Extensive page builders for WordPress bring a lot of design freedom and just as much ballast. If a page consists only of text and images, it does not need one.
• Reduce fonts. Every font family and every weight is a separate file. Two weights are almost always enough - and include them locally instead of via a third-party service; that saves an additional connection and is simpler in terms of data protection.
• Count external embeds. Map services, video embeds and analytics services load code from foreign servers - you have no influence on their speed. A preview image that only loads the video on click is the simplest improvement here.

If a WordPress site becomes slow or unstable after removing plugins, Fix WordPress errors helps narrow it down.

What the server already brings

Part of the work is already done on the web hosting:

• NVMe SSD in RAID 1. Database queries and file access run much faster than on conventional hard drives.
• HTTP/2 via nginx. Several files are transferred in parallel over one connection, which particularly benefits pages with many images and scripts. The prerequisite is an active SSL certificate - that is included free in every plan, see Set up SSL. We currently do not offer HTTP/3.
• Current PHP versions. All available and switchable per domain.

If the site permanently hits limits despite clean optimization - for example because an application needs more memory than a shared environment can sensibly provide - the next step is a VPS with its own resources. That is the exception, however: most sites are slow before optimization and fast enough afterwards.

Frequently asked questions