Most Marketing Websites Do Not Need a CMS
We have built and operated our own content management systems for years, and they are fast ones. That is what makes the observation worth writing down: for a site like this one, we were logging into a CMS in order to type HTML into a text box. The system was efficient, well built, and entirely unnecessary for the job at hand. It was not managing content. It was standing between an engineer and a file.
The Web Got Fat
Open the network tab on a typical small business website and count what arrives. Dozens upon dozens of individual requests. Stylesheets from a theme, stylesheets from a page builder, stylesheets from six plugins, three icon fonts where one would do, a slider library on a page with no slider, an analytics stack, a chat widget, a cookie consent framework, and a jQuery build that survives because nothing dares remove it. One to two megabytes of resources routinely arrive in service of a page whose actual content is a headline, four paragraphs, and a photograph.
None of that weight is doing work for the visitor. It is doing work for the tooling that produced the page. Somebody pays for it anyway: the person on mobile data, the person on a rural connection, the search ranking, the conversion rate, and the bandwidth bill. A large share of the modern web is fat for no defensible reason, and the reason is almost never that the content demanded it.
What Page Builders Do to a Clean Website
The pattern we see most often is a small marketing site, five or ten pages of essentially fixed content, running WordPress with a visual page builder such as Divi or Elementor layered on top. It is a reasonable decision on day one. It is rarely a reasonable outcome.
Page builders work by serializing a visual layout into markup, and the markup they emit reflects the editing interface rather than the document. A section that a competent engineer would express as a heading and two paragraphs arrives as six nested container elements carrying generated class names, inline styles, and data attributes describing the builder's own state. Each builder ships its own stylesheet and script framework, because it has to render its layout system in the browser. Each plugin added over the years appends more of both, and almost none of them are removed when the feature that justified them is forgotten.
The failure is not that WordPress is bad software. WordPress runs an enormous share of the web and does so competently. The failure is applying an authoring platform designed for continuous editorial publishing to a document that changes three times a year, then adding a layout abstraction on top of it that guarantees nobody will ever again know what the page actually contains.
But Our Team Collaborates in the CMS
This is the objection we hear most, and it was a fair one in 2010. It is not a fair one now.
Free, mature editors solve this directly. Visual Studio Code connects straight to a server over SSH or SFTP, so several people can work against the same environment without anyone installing a stack locally. Live Share puts multiple editors in the same file simultaneously, which is closer to real collaboration than any administrative form has ever been. Put the site in git and you get branching, review before anything ships, a complete history of who changed what and why, and a rollback that takes seconds.
Compare that to what a CMS actually provides for collaboration in practice: a text field, a save button, and a revisions table that most teams have never successfully restored from. The workflow that felt like an advantage is usually the weaker of the two options, and it costs a database, an authentication surface, and a runtime to keep it.
There Is a Time and a Place for a CMS
We are not arguing that content management systems are wrong. They exist because a real problem exists. A newsroom publishing twenty pieces a day, a retailer maintaining thousands of product records, a marketing team where non technical staff genuinely need to publish weekly without an engineer in the loop: those are the cases a CMS was built for, and in those cases it earns its cost several times over.
The decision comes down to two questions most teams never ask out loud. Who edits this content, and how often does it change? If the answer is non technical staff producing material every week, keep the CMS. If the answer is an engineer, or a marketing lead perfectly comfortable handing copy to an engineer, on a site revised a few times a year, then the CMS is an interface nobody needs at a cost that never stops accruing.
The majority of the web is the second case. Most informational and small business websites are a set of documents that change deliberately, and documents are well served by files.
If You Need a CMS, Stop Serving Pages From It
Where a CMS is genuinely warranted, the correct architecture is to treat it as an authoring tool rather than a runtime. There is no reason to put a database query and a template render between every visitor and a page that has not changed since last quarter.
Put a caching layer in front and serve visitors from cache rather than from PHP. Varnish is the mature answer and will return a cached page in a fraction of a millisecond without waking the application at all. A well configured full page cache accomplishes much of the same. Better still, where the content model allows it, add a build step that compiles the CMS output to static files and publish those, so the authoring system can be down, patched, or firewalled off entirely without a visitor noticing.
The distinction matters for security as much as speed. An administrative interface exposed on the same origin as your public site is an attack surface that exists so a handful of people can log in occasionally. Caching hard in front of it, or compiling past it, means the public never touches the application at all.
Static Does Not Mean Motionless
The most common objection after collaboration is that a static site cannot be interactive, which confuses where a page is assembled with what it can do once it arrives. A statically served page can carry as much JavaScript as the design calls for. It can call APIs, open WebSocket connections, stream data, render charts, and validate forms. The home page of this site plays background video, animates counters as they scroll into view, and runs a continuous logo marquee, all from files sitting on a disk.
What static removes is the server side render on every request. What it preserves is everything the visitor actually experiences. The work that remains is covered in What Actually Makes a Website Slow.
Why We Moved This Site
We moved mkn.us off our own content management system, which was already lean and fast, onto a simplified static structure our team edits directly. The content here changes deliberately rather than continuously, every person who touches it is an engineer, and the authoring step was the only part of the stack not earning its place. Removing it made the site simpler to reason about and faster to work on. We applied the same standard to ourselves that we apply to client architecture, and the standard said the layer was not needed.
What Static Asks of You in Return
This is not a free trade and we will not present it as one. When you serve files directly, defaults you never chose become your security posture, and directory listing behavior, redirect rules, cache headers, and error handling are all yours to get right. That is a fair exchange for owning the stack, but it is an exchange, and it rewards teams who verify configuration against the running system rather than assuming it.
Build It Properly and the Question Disappears
A well built static site does not need a content management system, because there is nothing left for the system to manage. There is no administrative login, no plugin to update, no builder abstraction between the design and the markup, and no runtime between the request and the response. Deployment is copying files. The attack surface is the web server.
That is the same principle behind everything we describe as infrastructure independence: own the layers that matter, understand everything you ship, and refuse to carry complexity that is not doing work for you.
If you are running a CMS and a page builder on a site that changes twice a year, we can tell you what it is costing you in weight, in attack surface, and in hours nobody bills for. Contact us and we will take a look.