PERFORMANCE AND PLATFORMS
FOR MEDIA AND SPORT.
Newsrooms that publish all day, traffic that arrives with the fixture list, and a server that has to answer either way. We diagnose what is actually slow, rebuild the caching around it, and move the whole thing somewhere it can breathe.
IT IS THE ORIGIN,
NOT THE READER.
Response time identical on mobile and on fibre means the device was never the problem.
-
Every post invalidates the cache
A caching strategy written for a static site collapses in a live medium, which is why publishers so often end up with caching switched on and nothing cached.
-
You cannot freeze a newsroom
Any intervention has to coexist with editors publishing and a wire importer running without pause. There is no maintenance window.
-
The archive is the asset
Fifteen years of articles and the rankings attached to them. A migration that loses either one costs more than the hosting ever did.
MEASURE FIRST.
THEN MOVE.
Caching that matches the server
Static HTML served without executing code on every visit, primed in the background on publish so nobody lands on a cold page, and proven with both configurations run on the same hardware under the same concurrent load.
Migrations with a live rollback
The whole install replicated into a controlled environment without touching production, the database moved in verifiable resumable ranges, and the old site held in place as the fallback until the cutover is clean.
The backlog the old host made impossible
Image weight, the metadata Google reads, live scoreboards and the internal links into statistics, each one worked in turn and measured before and after.
THE SAME TEAM,
WHICHEVER ONE YOU NEED.
FROM DIAGNOSIS
TO CUTOVER.
Five steps, and no step taken on a hunch.
- 01 Measure Lab and field, until the cause is isolated, never guessed.
- 02 Prove Both configurations, same hardware, same concurrent load.
- 03 Replicate The whole site rebuilt elsewhere with production untouched.
- 04 Cut over DNS moved with the old site standing as the rollback.
- 05 Then fix The backlog the previous host never had room for.
THE TOOLS
BEHIND THE SPEED.
Chosen for traffic that arrives all at once.
-
-
- Nginx
- Redis
-
-
-
-
-
- Core Web Vitals
- WebP
WHAT PUBLISHERS
ASK FIRST.
The questions that come up on almost every first call.
We answer that with a measurement instead of an opinion, and it is usually the first thing we do. If response time is identical on a throttled mobile connection and on desktop fibre, the device and the network are ruled out and the origin is the problem. On the last one of these the server was taking about 3.4 seconds before a single pixel reached anyone.
Yes, and the plan assumes it. The site is replicated into a controlled environment and production is not touched until the cutover, so editors and the wire importer keep running throughout. We validated the last importer live across five full cycles before moving anything.
It does not have to. On the last one, the day of the cutover was the only day below average and the next day was already above where the site had been, with clicks averaging 845 a day before and 906 after. That comes from planning the URLs and the redirects first, not from luck.
Only if it is built for it. A cache that is purged on every post and never regenerated is the same as no cache. We prime the front page and the sections in the background on publish, which is why 95% of visits stay under 22 milliseconds on a site that never stops publishing.
We read your own search data and turn it into a short set of titling and structure rules, argued from your own articles, with the title as published beside the title we would have written. It fits the routine the desk already has instead of asking for a new process.
Still have a question? Let's talk
WE WORK IN
OTHER ROOMS TOO.
The pattern changes by sector. The standard does not.
View all industries
TELL US WHAT
IS SLOWING YOU DOWN.
We will measure it before anyone promises you anything.