What we had before
The previous nel404labs.co.za was a WordPress site. Nothing unusual about that. It had Elementor for layout, WooCommerce inactive (we had thought about selling a product), Yoast SEO, a couple of security plugins, and the usual accumulation of plugins that comes from two years of adding things and not removing them.
It worked. It got the job done. But every time we needed to make a change, we were navigating an admin panel designed for a content editor, not a developer. The block editor is genuinely good for some things. For building a bespoke landing page with precise layout requirements, it is not.
The actual reasons we switched
Speed
The WordPress site scored 68 on PageSpeed Insights mobile. That is not terrible for WordPress but it is not good. The new static site scores 97-99 consistently. The difference is not compression or image optimisation (we had those on the WordPress site too). The difference is that static HTML has no PHP execution time, no database queries, no plugin chain to run through on every request. The server just sends a file.
On a R100/month cPanel plan, that matters. There is no Redis cache, no Varnish, no CDN with smart caching rules. Static files are as fast as it gets on budget hosting.
Cost
The WordPress stack was costing us about R800/month in plugin licenses. Elementor Pro (R1,200/year), a premium security plugin (R600/year), a backup plugin (R400/year), and a few smaller ones. These are not unreasonable prices for what they provide, but we do not need them for a 6-page brochure site.
The static site costs R0 in additional licenses. The only recurring cost is the hosting we were already paying for.
Control
When something looks wrong on the WordPress site, the debugging path is: check the block editor, check Elementor overrides, check the parent theme, check the child theme, check which plugin is injecting CSS. On the static site, when something looks wrong, it is in one of three files: the HTML, the CSS, or the JS. That is it.
We can deploy a change by uploading one file over FTP. No build pipeline, no WordPress deployment plugin, no database migration. For a small team that needs to move fast, this matters.
Security surface
WordPress is the most targeted CMS on the internet. Not because it is insecure by design, but because it is everywhere and the ecosystem of plugins creates a large attack surface. We were running 8 plugins. Each plugin is a potential vulnerability. We have seen the scan results. South African WordPress sites get probed constantly.
A static HTML site with a couple of PHP endpoints has a much smaller attack surface. The PHP files handle form submissions and API proxying. They do not touch the database. They do not accept file uploads. The worst a successful attack on a scan proxy endpoint does is run extra API calls we do not want. Not ideal, but contained.
What we gave up
The main thing we lost is a CMS. If a client wanted to edit their own site content, WordPress makes that possible without requiring developer access. Our site does not have that requirement because we are the client. For anyone whose website needs to be edited by non-developers on a regular basis, this is a real cost of going static.
We also lost the WordPress ecosystem of plugins for things like contact forms, newsletter signup, and booking systems. We replaced our contact form with a PHP endpoint and a mailto fallback. It is less featured than a proper form plugin but it does what we need.
Who should still use WordPress
Most people, honestly. WordPress is the right choice if:
- Someone other than a developer needs to edit content regularly.
- You are running a WooCommerce store. The plugin ecosystem for e-commerce in WordPress is genuinely difficult to beat at the price point.
- You need a blog with a proper editorial workflow, categories, scheduled posts, and author management.
- Your client has a budget and wants a full-featured site without custom development.
WordPress is not going anywhere. It powers a large proportion of the web for good reasons. We switched because our specific site had specific requirements that static HTML serves better. That is not a general recommendation to rewrite everything.
The practical result
The new site loaded in 0.9 seconds on a cold request from Johannesburg (tested with a local connection, not a synthetic CDN measurement). The WordPress site loaded in 3.2 seconds on the same test. We are paying less in plugin licenses. We deploy changes in under a minute. The site has not had a single downtime incident related to plugin conflicts or update breakage since the rebuild.
For a brochure site, that is the right outcome.