Skip to main content
.com domains from $2.99 — free WHOIS privacy on every name

Load profile · Berlin

Berlin: stop installing cache plugins and read the header

You have three caching plugins stacked on a platform that already caches, the site is not faster, and nobody has checked whether any of them is doing anything at all.

The short answer

Read the response header before you install anything else. On this platform LiteSpeed caching is built into the server, so a served page returns x-litespeed-cache: hit on the second request — and a plugin-level cache stacked on top of it usually adds a layer of invalidation bugs rather than speed. Remove the duplicates, confirm the hit, then measure.

Underneath that: NVMe storage, OPcache on current PHP 8.x so uncached pages are still cheap, and a published round trip of 10–35 ms from Western Europe to our London origin. Free SSL, free migration and engineers on shift at any hour come with every plan.

By the HostingFast team · Reviewed 12 August 2026

99.9%

Uptime target, monitored

24/7

Engineers on shift

Free

SSL, every plan

NVMe

Drives, every tier

Founders from forty countries do business here in English, the D2C brands ship across the continent, and a consumer-tech scene has produced several of Europe's largest platforms. The improvisational habit survived the rent rises, and so did the habit of stacking one more plugin on a problem.

This page is the opposite approach: find out what is already running, measure the effect of removing something, and only then add. It covers bilingual caching, the parts of a shop that never cache, and the arithmetic on the London hop.

Two language trees that both cache

German and English belong on separate URLs with hreflang declared in both directions, and each address then becomes its own cache entry so neither tree is the slow one. Confirm it rather than assume it: request the German page twice and read the cache header on the second response, then do the same for English. Two hits means the structure is right.

The pattern that breaks it is language switching on a single URL by cookie or Accept-Language. The response varies per visitor, so the cache either stores the wrong copy or refuses to store at all, and every reader pays for a full PHP render. On a bilingual site that mistake is expensive twice over, because it applies to your whole audience rather than half of it.

Where a D2C store stops caching

Catalogue pages, category listings and content cache beautifully. The cart, the checkout and the account area do not, by definition — they are personal, they write to a database, and they run the full round trip on each request. A store that loads a cart fragment on every page, including the ones nobody is shopping on, has accidentally made its entire catalogue uncacheable.

Check for that first, because it is common and it is invisible until you look. Then keep the checkout short: fewer steps means fewer round trips, and browser-side validation stops a missing postcode making the journey to London to be rejected. Nitro's 2 cores and 4 GB give the uncacheable half the headroom it actually needs.

The hop, in numbers rather than adjectives

Berlin sits inside the band we publish for Western and Northern Europe: 10–35 ms round trip to London, indicative for a well-connected consumer network. Against the 800 ms that counts as a good time to first byte, the distance is spending a few per cent of the budget, and a server inside Germany would not measurably change what a visitor feels.

What does change it is whether the page was built in advance. A cache hit costs the round trip plus the server's handling; a miss costs the round trip plus a full application boot, a database round of its own and whatever the theme does before it emits any HTML. That is the difference people describe as slow, and it has nothing to do with the map.

Measure before you install anything

The cargo-cult version of performance work is a list of plugins somebody recommended in a forum. The method is: record a baseline, change one thing, record it again. Three curl runs printing time_starttransfer, the field LCP from PageSpeed Insights at the 75th percentile, and the cache result on the second request — that triplet is enough to make every later argument settleable.

Do it on staging so the experiment never meets a customer, and keep the changes atomic. Nitro also carries PHP X-Ray on CloudLinux Pro, which traces a slow request function by function and identifies the responsible code far quicker than disabling plugins one at a time and hoping.

An aisle of racks inside the London datacentre

What is already running before you add anything

Server-level LiteSpeed caching, NVMe storage, OPcache on current PHP 8.x and HTTP/2 — all of it on by default, on every plan, with a header you can read to prove it.

Then the tools to work with: per-site PHP versions, staging copies, SSH with Git and Composer, and daily backups you restore yourself from the panel.

  • x-litespeed-cache readable on every response
  • .de registered and renewed on the same account
  • OPcache on current PHP 8.x, keeping misses cheap
  • Staging copies for one change at a time

Why HostingFast

Standard on every plan

Caching that is already there

LiteSpeed built into the server rather than patched in by plugin, which means one cache layer to reason about instead of three arguing.

A header that settles arguments

Hit or miss, reported on every response, so cache ratio becomes an observation rather than a matter of opinion.

Cheap cache misses

NVMe storage with OPcache on current PHP 8.x, so the cart and account pages that can never be cached are still quick to build.

Tracing on the top tier

PHP X-Ray on CloudLinux Pro follows a slow request through the code and names the function responsible, which beats guessing.

Staging on every relevant plan

Clone, change one thing, measure, promote. The discipline is free; the plugin roulette it replaces is not.

Migration at no charge

Engineers move the whole site across free, keep it serving throughout, and change delegation only once you have signed it off.

Quick Start

From order to online

  1. 1

    Inventory what is already caching

    Read the response header, then list every plugin claiming to cache. On this platform most of them are duplicating work the server already does.

  2. 2

    Remove one, measure, repeat

    Atomic changes on staging, with the same three numbers recorded each time. Removing things is an optimisation and it is usually the cheapest one available.

  3. 3

    Check both language trees

    Two requests per tree, cache hit confirmed on the second. If one language never hits, the language switcher is the thing to fix.

Built In

Loaded onto every plan

  • LiteSpeed caching built into the server rather than patched in by plugin
  • Current PHP 8.x with OPcache enabled from the start
  • NVMe SSD storage on every tier, not just the expensive ones
  • Per-site PHP version switching from the control panel
  • Staging environments for testing changes before they ship
  • PHP X-Ray on CloudLinux Pro for tracing slow requests on Nitro
  • Daily backups, with self-service restores you run from the panel
  • WordPress and 400+ other applications installed in one click
  • Free SSL on every plan, renewed automatically before it can expire
  • 99.9% uptime as the target, monitored around the clock

Frequently Asked

What people ask us most often

Do I still need a caching plugin on a LiteSpeed server?

Usually not, and stacking several is actively harmful — you get competing invalidation rules and stale pages nobody can explain. Read the response header first: a hit on the second request means the server is already serving pre-built pages. Remove the duplicates on staging, confirm the header still says hit, and keep the simpler stack.

Why does my whole shop refuse to cache?

Nine times out of ten a cart fragment or a session cookie is being loaded on every page, not just the shopping ones. That makes the response vary per visitor and the cache stops storing anything. Restrict the cart logic to the pages that need it, then re-request a category page twice and check the header.

Would a German data centre make the site faster?

Not measurably. Our published band is 10–35 ms round trip to London against an 800 ms budget for a good first byte, so the hop is spending a few per cent. If the site feels slow, the cost is in the application boot on an uncached page, and moving the server does not change that at all.

What does the Impressum requirement mean for hosting?

Nothing technical. Legal pages are ordinary content under your control, SSL issues automatically on every hostname, and the contracting party is a UK-registered company on English-law terms. Your counsel decides what has to be published; the platform simply does not get in the way of publishing it.

Keep reading

Changing hosts? Run through our checklist first.

A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.

You'll get the checklist email, then occasional pointers on keeping a site running fast. Unsubscribe the moment you want out — the privacy policy covers the rest.

Read the header, then decide.

Server-level LiteSpeed caching on NVMe, OPcache on current PHP 8.x, free SSL and a free migration — with staging to test one change at a time.

View Domain Names plans