Performance profile · SaaS Marketing & Docs Sites
Web hosting for saas companies — Measure the marketing site by template, not by homepage
Your docs, your pricing page and your blog have completely different performance profiles, and a single site-wide score averages all three into something useless.
The short answer
Measure a SaaS marketing site one template at a time. Docs and blog posts are cacheable documents that should return well inside Google's 800 ms TTFB threshold; the pricing page carries toggles, calculators and a checkout link, so it is judged on Interaction to Next Paint against a 200 ms threshold. Averaging the two hides both problems.
The platform underneath is deliberately dull: a LiteSpeed cache engine in the server on NVMe storage, Redis object caching for the queries that survive a cache miss, staging copies to test a template change, and SSH with Git so a marketing deploy has a commit behind it. From $2.42/mo, with a London origin 5 to 15 ms from a UK reader.
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
A SaaS site is really four sites: a homepage that changes weekly, a pricing page that carries interactive state, a documentation estate of hundreds of pages, and a blog that grows forever. They share a domain and nothing else. The pressure on each is different, and so is the fix.
That makes template-level measurement the only useful discipline. Time a docs article, a blog post and the pricing page separately: five runs of `curl -s -o /dev/null -w '%{time_starttransfer}'` for the server view, and three throttled Lighthouse passes on Slow 4G for what the visitor experiences. Three pairs of numbers, one file, dated.
The failure mode to avoid is optimising the homepage because it is the page the team looks at, while the docs search that support links to every day is the slowest thing you own.
A docs estate is a cache-hit-rate problem
Hundreds of documentation pages are ideal cache candidates: identical for every reader, rarely edited, heavily linked. Give them a long cache lifetime with a purge on publish and LiteSpeed will answer almost every request from stored HTML without waking PHP. What ruins the hit rate is a sidebar that shows recently updated articles, or a search box whose results share a URL with the page.
Search is the exception that needs thought. Every query is a different result set, so it cannot be cached usefully, and on a large knowledge base it is the query with the least attention paid to it. Time a real search term rather than the docs homepage, and if the median is poor, look at the index before the plan — Redis object caching helps, an unindexed LIKE query does not become fast on better hardware.
The pricing page is JavaScript, and INP is its metric
Monthly and annual toggles, seat sliders, currency switches, a comparison table and a chat widget: the pricing page is the most interactive page on a SaaS site, which makes Interaction to Next Paint the number that matters. Google's good threshold is 200 ms. Measure it with the third-party scripts blocked and then unblocked, and you will know exactly what the widgets cost.
Do it on a staging copy before a campaign, not during one. Marketing tends to add tags in the week a campaign launches, which is the week you least want to discover that two analytics scripts and a heat-mapping tool have pushed the buy button past a quarter of a second of delay.
Publishing velocity, without a release window
The reason to run marketing on a CMS rather than in the product's framework is throughput: a landing page goes live in an hour rather than in the next sprint, and engineering is not reviewing copy. Keep the deploy path honest anyway — SSH with Git and Composer means template changes carry a commit, and staging copies mean a new block gets measured before a visitor meets it.
Set a rule that survives contact with a busy quarter: after any template change, re-run the same three throttled Lighthouse passes on that template and record the median next to the previous one. Decay on a fast-moving marketing site is not a mystery, it is an unrecorded sequence of small additions.
The numbers to hand growth when they ask
Two per template, and say which tool produced them. Lab figures from Lighthouse answer today and reflect the change you shipped this morning. The Core Web Vitals block in PageSpeed Insights is field data from real Chrome users and lags a deploy by weeks, which is why a fix and a dashboard can disagree for a fortnight without either being wrong.
On the server side, watch cPanel's Resource Usage rather than a support ticket: CPU, memory and entry processes against your allocation over time. A docs estate that has grown into thousands of pages usually needs the object cache turned on rather than a bigger plan — and if it does need the plan, Nitro brings 2 cores and 4 GB of RAM in place.
A marketing stack that can be measured
Everything on this page is checkable from your own machine: the timing command, the throttling profile, the thresholds. HostingFast's job is to make the cacheable half genuinely fast and to keep the uncached half honest.
So the tooling is standard rather than premium: LiteSpeed in the server, Redis object caching on the WordPress tiers, staging copies, SSH with Git and Composer, and a resource graph that names the constraint.
- Long-lived page caching with purge-on-publish for docs
- Redis object caching for search and uncached queries
- Staging copies, so a pricing page change is measured first
- SSH with Git and Composer for template deploys
Why HostingFast
Standard on every plan
Docs served from cache
Hundreds of stable pages is the best case for a server-level cache: near-total hit rate, and PHP barely involved.
A number for the pricing page
INP measured with scripts blocked and unblocked tells you what each widget on your highest-intent page costs.
Search that has been looked at
Redis object caching plus NVMe storage for the one query on a knowledge base that no page cache can ever hold.
Velocity without a release train
A CMS on its own account lets marketing publish in an hour, while staging keeps the measurement discipline intact.
Deploys with an audit trail
SSH with Git and Composer, so a template change is a commit rather than a file somebody uploaded on a Friday.
Capacity as a setting
Nitro brings 200 GB of NVMe, 2 cores and 4 GB of RAM in place, so a growing content estate never needs a migration.
Quick Start
From order to online
- 1
Measure three templates, not one site
A docs article, a blog post and the pricing page. Five curl runs each for TTFB, three throttled Lighthouse passes each for LCP and INP.
- 2
Cache the stable half properly
Long lifetimes with purge-on-publish on docs and posts. Then time a real search query, which is the part that cannot be cached.
- 3
Gate template changes on the numbers
Stage it, re-run the same passes, compare medians, then ship. Record the result next to the last one so decay stays visible.
Built In
Loaded onto every plan
- Server-level LiteSpeed caching with per-template lifetimes
- Redis object caching and AccelerateWP on the WordPress tiers
- NVMe storage on every tier, entry plan included
- Staging copies for pricing and template changes
- SSH with Git and Composer, plus WP-CLI for bulk edits
- Per-site PHP version switching from the control panel
- cPanel Resource Usage: CPU, memory and entry processes over time
- Daily backups with self-service restores from the panel
- 99.9% uptime as the target, monitored around the clock
- In-place upgrades to Nitro: 200 GB NVMe, 2 cores, 4 GB RAM
Frequently Asked
What people ask us most often
Which page on a SaaS site should we measure first?
Not the homepage. Measure the template with the most traffic and the template with the most intent — usually a documentation article and the pricing page. They fail differently: docs fail on TTFB and cache hit rate, pricing fails on Interaction to Next Paint because of the scripts on it. A single site-wide score averages both into nothing.
Can a documentation search be cached?
Not usefully, because every query is a different result set. What helps is an index that suits the query, a sensible result limit, and Redis object caching for the repeated lookups around it. Time a real search term with curl rather than assuming the docs homepage figure applies — on a large knowledge base they are rarely close.
Why is our pricing page the slowest thing we own?
Because it is the most interactive. Toggles, calculators, comparison tables, chat and analytics all compete for the main thread, and INP measures exactly that competition. Run a throttled Lighthouse pass with third-party scripts blocked, then again with them on, and the gap is the price of the widgets.
Should the marketing site be built in the product's framework?
Only if you enjoy reviewing copy in pull requests. A CMS on a separate account gives marketing an hour-long path to publication, keeps campaign pages out of the release cycle, and means a traffic spike on a landing page cannot touch the resources your logged-in customers depend on.
Keep reading
Food Trucks — Hosting Guide
A short, image-led site where the whole measurement is one photograph and a phone.
Music Teachers — Hosting Guide
A small teaching site with the same publishing question at a fraction of the scale.
Uptime (Glossary)
What the uptime figure means, with the arithmetic and the remedy spelled out.
Drupal Hosting — Built for SaaS Companies
Drupal with Composer, Drush and per-site PHP control when the docs estate needs it.
Web Hosting
cPanel hosting on NVMe with LiteSpeed included from the entry tier upward.
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.
Measure per template.
Docs, blog and pricing, timed separately — three pairs of numbers and you know where the work is.
View Drupal Hosting — Built for SaaS Companies plans