Uncached work · Zurich
The Zurich problem: none of it is cacheable
Private client areas, document libraries and secure logins are the workload here, and page caching is no help to a single one of them.
The short answer
Most speed advice assumes a logged-out visitor, and most Zurich sites are not that. A client portal, a document library behind a login and a secure enquiry desk all run uncached, which means every request goes the whole way to the origin and is built on demand. Cache hit rate is the wrong metric; time to first byte on an authenticated request is the right one.
Measure it with curl printing time_starttransfer against the logged-in URL rather than the homepage. Anything much beyond 600 milliseconds on a page the server should already have warm is contention or code, not distance — and the platform under it is NVMe storage, per-site PHP, and PHP X-Ray on CloudLinux Pro on the top shared tier to say which of the two it is.
By the HostingFast team · Reviewed 15 August 2026
99.9%
Availability target
24/7
Engineers on shift
Free
SSL, every plan
NVMe
Drives as standard
Private banking and asset management at a density found nowhere else, insurance and reinsurance beside it, and a deep-tech pipeline out of ETH that now produces companies rather than only papers. What those businesses put on the web is mostly gated.
Which changes the brief entirely. This page covers how to time an authenticated request, why the usual optimisation advice does nothing here, what the wire actually costs from Switzerland, and where .ch and the certificate sit in that picture.
Time the request nobody tests
Public pages get measured because they are easy to measure. Open a terminal and run curl against the URL your clients actually live on, printing time_namelookup, time_connect, time_appconnect and time_starttransfer, and read the gaps between them rather than the total. DNS, the TCP handshake and the TLS negotiation are one story; the space before the first byte is the server thinking.
Do it twice, once at a quiet hour and once at four in the afternoon. A figure that flies in the morning and drags after lunch is contention on the machine, not your application, and no amount of front-end work touches it. A figure that is uniformly slow is your own code, which is better news because you can fix it today.
Why the usual advice does nothing for a portal
Page caching, edge delivery and a CDN all solve the same problem: handing an identical response to many people. A logged-in client area produces a different response for every session, so none of that machinery ever engages. The dashboard, the account screen and the file listing take the full journey each time, by design.
What does move the number is smaller and less glamorous: an object cache so repeated database lookups stop being repeated, current PHP rather than a version kept for one legacy dependency, indexes on the columns the portal filters, and NVMe underneath so the reads that remain are quick. Those are the levers; everything else is decoration on this workload.
What the wire costs from Switzerland
Switzerland sits inside the Western and Northern Europe band we publish for the London origin: 10 to 35 milliseconds of round trip. For a document that is one trip and irrelevant. For a portal screen that issues forty uncached requests, it is forty of them, and that is the arithmetic worth doing before you blame the distance.
It is also why we would rather publish the figure than describe the speed. A number you can check against your own connection is worth more than an adjective, and if the workload genuinely needs something a single London facility cannot give it, you should hear that before you buy rather than in a ticket afterwards.
.ch, the certificate, and one hostname
Swiss establishment reads in .ch, and it registers alongside the hosting on one account with a single renewal date and DNS aimed correctly from the start. International arms run .com in parallel without either one being weakened.
For the portal specifically, keep the login on the same hostname as the marketing site wherever the architecture allows it. Every extra origin costs a fresh DNS lookup, a fresh handshake and a fresh TLS negotiation before a single byte of your application runs. Free SSL issues automatically as soon as the name resolves here and reissues ahead of expiry, so nobody has a diary reminder for it.
The parts that matter on an uncacheable workload
Every account is NVMe-backed with a LiteSpeed cache in the server for the pages that can use one, and per-site PHP switching for the application that cannot.
On the top shared tier, PHP X-Ray on CloudLinux Pro points at the slow call directly, which turns a week of theorising about a portal into an afternoon of fixing it.
- Per-site PHP switching, legacy and current side by side
- PHP X-Ray on CloudLinux Pro on the top shared tier
- SSH with Git and Composer for reading a slow query log
- .ch registered and renewed on the hosting account
Why HostingFast
Standard on every plan
Profiling instead of guessing
PHP X-Ray on CloudLinux Pro on the Nitro tier names the slow function, so a portal investigation ends in a fix rather than a theory.
Two PHP versions, one account
Per-site switching means a legacy application and a current one run side by side without either holding the other back.
Disk speed where it is felt
Uncached requests read from disk on every view, so NVMe storage is standard on every tier rather than an upsell on the top one.
Shell access as standard
SSH with Git and Composer on the developer-focused plans, so a slow query log is something you read rather than something you request.
Restores without a queue
Daily backups you restore yourself from the panel — files, databases or both — at whatever hour the mistake was made.
Support that answers on the detail
Engineers on shift around the clock, first reply inside two hours and inside one when a site is down, with the scope to discuss which layer is responsible.
Quick Start
From order to online
- 1
Measure the authenticated path
curl with time_starttransfer against a logged-in URL, twice: once at a quiet hour, once at peak. The spread between them is the diagnosis.
- 2
Attack the two real levers
Object caching for repeated queries and a current PHP version for everything else, then re-run the identical command and compare against what you wrote down.
- 3
Move it with the record intact
Free migration with the existing site serving throughout, DNS on your sign-off, and the same measurement repeated afterwards so the change is evidenced.
Built In
Loaded onto every plan
- Per-site PHP version switching from the control panel
- PHP X-Ray on CloudLinux Pro on the top shared tier
- NVMe storage as the floor on every tier, never an upgrade
- SSH, Git and Composer on the developer-focused plans
- Free SSL issued on connection and reissued before expiry
- Daily backups with self-service restores from the panel
- cPanel, which most of the industry settled on years ago
- In-place tier upgrades, with no migration when you change plan
- Domain mailboxes bundled in, not billed separately at the till
- A renewal price identical to the one you signed up at
Frequently Asked
What people ask us most often
Our client area is behind a login. Does any caching help it at all?
Page caching, no — every session produces a different response, so there is nothing to reuse. Object caching does help, because the repeated database lookups behind those different responses are frequently identical. The practical target is to cut the number of queries a portal screen issues and to make the ones that remain read from NVMe rather than from a spinning queue behind other tenants.
What first-byte figure should I be aiming at on an authenticated page?
Treat roughly 600 milliseconds as the line where the platform becomes the suspect. Below it, the remaining time is your application and worth profiling. Above it, and especially if the figure moves by hundreds of milliseconds between morning and mid-afternoon, you are sharing a machine with something noisy and no front-end change will rescue the number.
We publish long PDFs to clients. Does that need anything special?
Mostly it needs the file served with sane cache headers and compression left off content that is already compressed. The part that catches people is access control: a PDF behind a login is uncacheable at every layer, so it is delivered from the origin each time. If those documents are large and frequently read, that is a bandwidth and disk conversation rather than a caching one.
Four languages are in play here. Does that slow the site down?
Only through the fonts and the extra templates, not through the language count itself. Parallel trees under hreflang cost nothing at runtime. What does cost is loading four font weights for a script most visitors never see — subset the faces, self-host them so they come from the same origin as the page, and measure the difference rather than assuming it.
Keep reading
Web Hosting in Glasgow
Glasgow, where the same authenticated workload has a much shorter trip.
Web Hosting in Cork
Cork, and what an Irish professional-services audience sees from London.
TTFB (Time To First Byte) (Glossary)
Time to first byte defined properly, with the worked example this page leans on.
VPS Hosting
KVM virtual servers with root access, when a portal outgrows shared execution limits.
DirectAdmin Reseller Hosting
Lightweight DirectAdmin reseller accounts at a lower monthly rate.
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.
Time the page nobody tests.
NVMe under every account, profiling on the top tier, and shell access to prove what you changed.
View VPS Hosting plans