An industrial catalog site has a particular shape: hundreds of product and application pages, deep technical content, updated occasionally, read constantly. Our position after building several of them: render every page as a fully static file. Build the whole site once at deploy time and serve it as finished HTML.
This is not a small-site trick. IMS runs 492 URLs in its sitemap, every one prerendered. Belzona Baton Rouge generates 460 static pages. AAS prerenders 185 routes. On each of those sites, the only dynamic code in production is the API route that delivers leads.
And "static" here means the real thing: the HTML for every page exists before the first visitor arrives. Not cached on first request, not rendered and then memoized. Built, verified, and shipped as a finished artifact.
Speed you do not have to earn twice
A static page is a file on a CDN. No database query, no CMS API call, no server rendering on demand. The slowest thing between the visitor and the content is the network itself, and that is true for every page equally: the 400th application page responds like the homepage.
That consistency is the point. Catalogs get entered sideways. A buyer lands on page 371 from a search result, and that page has to be as fast as the one you would demo. Static rendering makes the fast path the only path.
Nothing to go down
A static catalog has no runtime database, no CMS API, and no admin backend in the request path. There is nothing to crash under load and nothing to go down at 2 a.m. If the site gets linked from a big industry forum, the CDN absorbs it without anyone getting paged.
Compare that with a traditional CMS, where software sits between every reader and every page, and each request is another chance to fail. We have migrated clients off those platforms, and the operational silence afterward is its own reward: no maintenance windows, no plugin update taking the site down on a Friday.
Zero CMS attack surface
The security argument may be the strongest one. A static site has no admin login to brute-force, no plugin queue to patch, no database behind the public pages to inject into. The endless CMS-vulnerability treadmill simply does not apply to a site that ships as files.
Static does not mean casual, though. Every response still carries a full security-header suite: a content-security policy with a written rationale for each directive, two-year strict transport security, frame denial, and the rest. On IMS those headers are applied statically, precisely so caching survives them. The one genuinely dynamic surface, the lead endpoint, gets rate limiting, size caps, and injection hardening of its own.
That split keeps the risk where we can see it. The attack surface is one hardened endpoint, not an entire content platform.
But how do you edit anything?
Content lives in typed data files in the repository, and the site regenerates when the data changes. A page cannot render from broken data, because a broken build fails before deploy instead of failing in front of a visitor. What you tested is exactly what visitors get, byte for byte, until the next deploy. Deploys are atomic too: the new build replaces the old one whole, so nobody ever catches the site half-updated.
And when a client genuinely needs live editing, we make a surgical exception instead of abandoning the model. On Polymer Nation, product pages render against a live database so edits made in our client portal appear on the site within seconds, and a static snapshot stands behind it as a fallback so the site never breaks even if the database is unreachable. Static by default, dynamic by exception, resilient either way.
Where static earns its keep
- Speed: pages are files on a CDN. No query, no render, no cold start in the read path.
- Consistency: deep catalog pages respond like the homepage, which matters when buyers enter sideways from search.
- Resilience: no database or CMS API at request time means nothing to crash under a traffic spike.
- Security: no admin login, no plugin patching, no injection surface on the public site.
- Honesty: a static build cannot drift after deploy. What passed the checks is what ships.
The honest boundary
If your content changes by the minute, or every visitor sees different data, static is the wrong tool and we would tell you so. Industrial catalogs are the opposite case: deep content, long shelf life, high stakes on speed and uptime, and a buyer who does not care how the page was rendered, only that it loaded before they lost patience.
For a 200-to-500-page catalog, static is not a compromise we accept. It is the correct answer, and the page counts above are the proof that it scales.
