Performance profile · Publishing & Online Magazines
Web hosting for magazines — Cache a site that changes hourly, without going stale
Readers need instant article pages and editors need to see a change land — those two requirements pull in opposite directions, and the resolution is a cache policy per template.
The short answer
A publication is cached by template, not by site. Article pages barely change once published, so cache them aggressively and a hit never wakes PHP; the front page and section indexes get a short lifetime measured in minutes, so an editor sees their change land without every reader rebuilding the page from scratch.
Then measure the other side of the newsroom. The dashboard is logged-in traffic, so no page cache and no CDN will ever touch it: that speed comes from CPU, NVMe and a Redis object cache, all of which ship here — with cPanel's Resource Usage graph to show you which of the three is actually short.
By the HostingFast team · Reviewed 24 August 2026
99.9%
Uptime target, monitored
24/7
Support, any hour
Free
SSL, every plan
NVMe
Drives, all tiers
Two audiences share one server. Readers arrive logged out, ask for finished HTML and can be served from cache thousands of times without the origin noticing. Editors arrive logged in, and every screen they touch — list tables, revisions, the media library, autosave — is built fresh, every time, from the database.
That split explains most publishing complaints. The site is fast but the CMS is unusable is not a contradiction; it is the expected outcome of a page cache doing its job while nothing helps the uncached half. Time both separately: a curl median against an article URL, and a stopwatch on saving a draft.
The trap is treating an editorial site like a brochure and caching everything for hours. The desk stops trusting the site, someone disables caching entirely to make previews work, and a publication that was fast becomes one that falls over the first time a feature travels.
One cache policy per template
Articles are the easy case: once published they are the same bytes for every logged-out reader, so give them a long cache lifetime and let LiteSpeed answer from stored HTML. The front page, section indexes and any latest widget need a short TTL — minutes, not hours — because they are the pages an editor checks after publishing and the ones that must not show yesterday's lead.
The LiteSpeed Cache plugin is the control surface for this on WordPress: page caching, ESI for the fragments that genuinely vary, and purge rules on publish. Run exactly one caching plugin. Two do not cache twice; they fight, and the symptom is a stale front page nobody can explain.
Why the desk feels slower than the site
Every dashboard screen is personalised, so it is uncacheable by definition. A post list with revisions, a media library with thousands of items and an autosave firing while somebody types all land on the database directly. Redis object caching is the only layer that helps here, because it stores the results of individual queries rather than finished pages — and it ships on every WordPress tier.
Before blaming a plugin, read cPanel's Resource Usage. It plots CPU, memory and entry processes against your allocation over time, which separates two very different problems: slow code, or an account sitting at its ceiling during ordinary hours. If it is the ceiling, Nitro brings 2 cores and 4 GB of RAM and applies in place.
Measuring an archive that keeps growing
Thousands of articles put the pressure on queries, not on disk. Time three URLs separately: a cached article, the same article with a cache-busting query string, and a deep tag or date archive. The first tells you cache and distance, the second tells you CPU and disk, and the third is usually where an unindexed query is hiding.
Google's threshold for TTFB is 800 ms; on a cached article from a London origin with a 5 to 15 ms round trip you should be nowhere near it. If the uncached figure is many times the cached one, the fix is the object cache and the query, not a bigger plan — and the difference is worth knowing before you spend money.
The day a feature goes everywhere
A lead story picked up widely is a wave of logged-out readers asking for the same cached HTML, which is the cheapest traffic there is. What ruins it is an uncached element on the template — a live comment count, a personalised sidebar, an unbounded search box being crawled — because each one drags a full page build behind it.
Prove the arrangement in advance. Hit an article with a cache-buster and watch the resource graph; then hit it normally and watch nothing happen. Publish with the same tests, at the same hour, and note the medians. Behaviour under load you have measured is a plan; behaviour you assume is a story you tell afterwards.
Engineered for a newsroom that ships all day
Publishing teams get the parts a page cache cannot help with: NVMe storage, a Redis object cache, real logs over SSH and a resource graph that names the constraint instead of implying one.
And the parts that keep the reader side cheap on HostingFast: a server-level LiteSpeed cache on every tier, built-in WebP conversion for the photography, and free SSL that reissues itself long before it can lapse.
- LiteSpeed page caching with purge-on-publish control
- Redis object caching, the layer that helps wp-admin
- Resource Usage graphs for CPU, memory and entry processes
- In-place upgrades to 2 cores and 4 GB when the desk needs it
Why HostingFast
Standard on every plan
Cache by template, not by site
Long lifetimes on articles, minutes on the front page: readers get instant pages and editors still see their change land.
The only cache that helps editors
Redis object caching stores query results, which is what speeds up the logged-in screens no page cache can store.
A graph instead of an argument
Resource Usage plots CPU, memory and entry processes against your limits, so slow becomes a specific, fixable claim.
Photography that stops costing LCP
Built-in WebP conversion keeps a picture-led template honest without a second image plugin in the mix.
Capacity applied in place
Nitro brings 200 GB of NVMe with 2 cores and 4 GB of RAM as an account change, not a migration on deadline day.
Roles, staging and a way back
Editorial roles, staging copies for template work and daily self-service restores, so a bad deploy is a ten-minute rewind.
Quick Start
From order to online
- 1
Time three URLs, not one
A cached article, the same URL with a cache-buster, and a deep archive page. Five curl runs each, medians written down. Those three figures describe the whole site.
- 2
Set the TTLs per template
Long on articles with purge-on-publish, short on the front page and section indexes. Exactly one caching plugin, with ESI for anything that genuinely varies.
- 3
Fix the uncached half deliberately
Turn on the object cache, re-time the cache-busted URL, and only then consider more CPU. Read Resource Usage before you buy a tier.
Built In
Loaded onto every plan
- Server-level LiteSpeed caching with per-template lifetimes and purge rules
- Redis object caching and AccelerateWP on the WordPress tiers
- NVMe storage on every tier, not only the expensive ones
- cPanel Resource Usage: CPU, memory and entry processes over time
- Staging copies for template and plugin work before it reaches the desk
- Built-in WebP conversion for a picture-led publication
- Daily backups with self-service restores from the panel
- 99.9% uptime as the target, monitored around the clock
- SSH access with real error and slow query logs
- In-place upgrades to Nitro: 200 GB NVMe, 2 cores, 4 GB RAM
Frequently Asked
What people ask us most often
How long should a news front page be cached for?
Minutes, with a purge on publish. Article pages can hold a long lifetime because they rarely change once live, but the front page and section indexes are the ones an editor checks straight after publishing. A short TTL plus purge-on-publish gives readers cached speed without the desk losing confidence in what it sees.
Why is wp-admin slow when the public site is fast?
Because none of it is cacheable. Every dashboard screen is personalised, so it is rebuilt from the database on each request while a page cache handles readers for free. Redis object caching helps because it stores individual query results, and CPU and NVMe do the rest. A CDN will not touch it.
Do two caching plugins make the site twice as fast?
No, they make it unpredictable. On a LiteSpeed platform the cache lives in the server and the LiteSpeed Cache plugin is its control surface; a second plugin adds another set of rules for the same HTML. The usual symptom is a stale front page or a preview that will not update, and the fix is deactivating one of them.
Which figure should we quote in an editorial meeting?
Say which one you are quoting. A throttled Lighthouse run answers today and reflects the change you just shipped; the Core Web Vitals block in PageSpeed Insights is field data from real Chrome users and lags by weeks. Recording that difference in the document prevents an argument you would otherwise have twice.
Keep reading
Jewellers — Hosting Guide
A photography-heavy template where image weight, not query time, owns the first paint.
Dog Trainers — Hosting Guide
A smaller content site with the same cache-by-template question and fewer editors.
How to Test Your Website Speed
The walkthrough for the three URLs above, with the exact commands and thresholds.
Web Hosting — Built for Online Magazines
cPanel hosting on NVMe with the LiteSpeed cache engine included from the entry tier.
Agency Hosting
Client accounts, staging and care-plan tooling for teams looking after several publications.
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 three URLs.
A cached article, a cache-busted one and a deep archive page — three medians tell you what to buy and what to fix.
View Web Hosting — Built for Online Magazines plans