A website that fails under load usually fails the same way. Traffic arrives faster than the application server can render pages, the database queues up, and response times climb until requests start to fail.
Serve pages that are already built
A static site does its rendering once, when content is published. The build writes every page as an HTML file, and a CDN serves those files. When a surge arrives, visitors get files already cached at an edge location near them, and nothing behind the CDN has extra work to do.
Visor serves static builds from 200+ edge locations, with caching and image optimisation in front. With no live database answering public requests, there is also less for an attacker to reach.
Publishing stays immediate
The usual worry about static sites is stale content. In Visor, publishing a page or entry queues the change and triggers a static build automatically. Editors publish from Studio as they would on any CMS, and the build log records each trigger and each frontend build.
Three ways to build pages, chosen per site
Some pages change too often for a static build. The Visor template supports three models, picked with one environment variable at build time:
- SSG renders once at build time and exports plain HTML. It suits content-stable sites and CDN hosting.
- SSR renders on every request from a Node server. It suits pages whose content changes constantly.
- ISR serves static pages and refreshes them in the background, every 60 seconds by default.
Protection in front of the site
Static delivery handles volume. The layers in front of it handle hostile traffic. Every request passes DDoS protection, a web application firewall, and network firewalls before it reaches the site, and traffic is encrypted end to end.
A static build can also be hosted anywhere that serves files. Nginx, S3, or any static host will do, at the root of a domain or under a sub-path.
