Speed up a website

A site that takes three seconds to show its first line loses visitors before displaying anything. Measure, fix the most profitable lever, then measure again with the same tool. Without a before/after, you cannot tell whether a change helped.

Measure response time

Time to first byte (TTFB) tells you whether the server is slow; Largest Contentful Paint (LCP) tells you whether the full page is slow. Both appear in the browser's Network tab and Performance panel. From a shell:

curl -o /dev/null -sS -w "dns=%{time_namelookup} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" https://your-domain.com/

If TTFB is well above 300 ms, look at the server. If it is fine but the page is still slow, look at the content.

Server side: PHP, compression, headers

On NeoHeberg web hosting, PHP 8.4 and MySQL are provided through KeyHelp. In the panel, confirm the domain runs PHP 8.4 and that OPcache is enabled for PHP sites.

Then check compression and protocol:

curl -sI -H "Accept-Encoding: gzip, br" https://your-domain.com/ | grep -iE "content-encoding|HTTP"
curl -sI --http2 https://your-domain.com/ | head -n 1

A content-encoding: br or gzip line cuts HTML and CSS weight. HTTP/2 lowers latency when many resources are requested.

For the database, find slow queries before adding a cache: a column used in WHERE or JOIN without an index costs time on every page, and an unnecessary SELECT * moves data you never use.

Content side: images and requests

Serve each image at its real display size in WebP or AVIF, and lazy-load images below the fold — never the hero image, which should stay a priority. Bundle CSS and JS, defer non-critical scripts, and self-host fonts with font-display: swap so text does not wait on a third-party domain.

Versioned static files (app.a1b2c3.css) can use a long cache:

Cache-Control: public, max-age=31536000, immutable

CDN and verification

A CDN brings static files closer to visitors and can terminate TLS. It forces DNS record changes: do it after the server itself is stable, otherwise you measure the CDN instead of your application.

Finish with the same measurement you started with, in a private window and with a throttled mobile profile. Compare TTFB and LCP, check that no layout breaks, and keep a backup before changing a PHP setting or a cache header. Keep one cache mechanism per layer: stacking two plugins or two cache layers produces stale pages that are hard to diagnose.