WordPress vs Static Website: Security, Speed and Real Costs

WordPress powers roughly 40% of all websites on the internet. That’s an impressive number, and also the main reason nearly every agency proposes it sight unseen — whether you’re building a portal with thousands of articles or a five-page brochure site for a plumbing company. The trouble is, those two cases have almost nothing in common. A portal needs a database, an editorial dashboard and a permissions system. A brochure site needs five pages that don’t change for months.

For that second situation, WordPress is using a sledgehammer to crack a nut. And it’s a sledgehammer you have to clean, oil and keep an eye on regularly, so it doesn’t go off in your own hand.

In this article I break both architectures down into their parts: how they work, where the risks lie, how much upkeep really costs, and — honestly — when WordPress still wins anyway.

How WordPress works, or what happens after you type in the address

When someone opens a site built on WordPress, the server doesn’t send a finished file. Instead a whole chain kicks off: the web server passes the request to the PHP interpreter, PHP loads the WordPress core, the theme and every active plugin, queries the MySQL database for content, assembles an HTML document from all of it, and only then sends it back to the browser.

This process repeats on every visit (caching plugins shorten it, but don’t eliminate it — and they’re themselves one more thing to maintain). Every link in this chain is code that has to be up to date, correctly configured and free of holes. And there are plenty of links:

• the WordPress core — updated every few weeks,
• the theme — often bought once, updated rarely or never,
• plugins — a typical business site has a dozen or more: a form, SEO, cache, gallery, backup, cookies…,
• PHP on the server — successive versions lose support every few years,
• MySQL and the web server itself.

This isn’t a bad architecture in itself. It simply solves a problem a simple business site doesn’t have: assembling content dynamically from a database on demand.

WordPress security: an attack surface, not a single hole

The phrase “WordPress security” returns millions of results not because the core itself is full of holes. The core is developed by a large team and patched quickly. The problem is everything around it.

Plugins — the main way in

Reports from firms that specialise in WordPress security have shown the same picture for years: the vast majority of successful break-ins come through vulnerable plugins — most often out of date, sometimes abandoned by their author, sometimes with a zero-day for which no patch exists yet. The logic is simple: a plugin is often written by one person, no one runs a security audit, and then half a million sites install it. For an attacker it’s a lottery where every ticket wins — you just scan the internet for a specific version of a specific plugin.

And here we get to the heart of it: security on a WordPress site isn’t a state, it’s a process. Someone has to log in to the dashboard, check for updates, install them, verify nothing broke (because a plugin update can take a site down), make backups before every change. Every week, every other week. For years.

The admin panel exposed to the world

Every WordPress has a login page at a predictable address — /wp-admin or /wp-login.php. Bots hit these paths en masse and try passwords by dictionary attack, day and night. You can defend yourself: change the login address, two-factor authentication, attempt limits, an application firewall. But each of these defences is usually… another plugin. The attack surface grows in order to defend the attack surface.

What happens after a break-in

A hijacked business site is rarely just wiped — that wouldn’t pay. More often it quietly starts sending spam, hosting phishing pages or slipping malicious redirects to visitors. The owner is the last to find out: from Google (a “this site may be dangerous” warning in the search results), from the hosting provider (account suspension) or from a customer whose antivirus blocked the visit. Cleaning up after such an incident means hours of a specialist’s time and a real loss of trust.

A static website: nothing to hack

A static website is a set of ready-made files — HTML, CSS, a bit of JavaScript, images — sitting on a server and sent to the browser in exactly the form they were saved. Nothing runs on the server side. There’s no PHP. There’s no database. There’s no login panel at a public address.

The security consequences are fundamental:

• No database — an entire class of SQL injection attacks disappears, because there’s no database to inject a query into.
• No code running on the server — remote code execution disappears, the most dangerous type of vulnerability.
• No admin panel — bots have nothing to brute-force. Managing the site happens off it (more on that shortly).
• No plugins — there’s no dependency chain in which one expired link opens the door.

To swap out the content of such a site, an attacker would have to take over the hosting infrastructure itself — for example an AWS account secured with keys and two-factor authentication. That’s a completely different league of difficulty than finding a site with an out-of-date gallery plugin.

The side effect a business owner will appreciate most: a static website doesn’t need weekly care. There are no updates to install, because there’s no software ageing on the server. Built once, it works the same a year and five years from now.

What a static site generator is (and why Astro is here)

Someone might ask: if a site is just ready-made HTML files, do you have to write them by hand like in the ’90s? No — and this is where static site generators come in.

A generator is a tool that works before publication, not on every user visit. A developer writes the site in convenient, modern components (a header once, a footer once, a page template once), keeps the content in separate files, and the generator assembles a full set of ready-made HTML files in a process called the build. That build runs once — on every content change — not a million times, on every visitor.

It’s exactly the same work WordPress does over and over, live, only done once and in advance.

Astro is currently one of the most mature generators and our choice at Sitario. Its distinguishing feature: by default it ships zero JavaScript to the browser. Most frameworks bolt their own code onto the page even when the page doesn’t need it; Astro flips the logic — JavaScript only goes where it actually does something (handling a form, say). For a business site that means lighter files and faster loading, with no extra work.

AWS architecture: S3 + CloudFront in three paragraphs

The finished files have to go somewhere. Classic shared hosting would do, but since the site is just files, you can reach for enterprise-class infrastructure at a fraction of its usual price.

Amazon S3 is a file store in the AWS cloud — the same one that runs a good chunk of the internet’s best-known services. The site’s files land in what’s called a bucket, and S3 can serve them with a reliability ordinary hosting can only dream of. The cost of storing a few-megabyte site: pennies a month, literally.

CloudFront is a CDN, a network of servers scattered around the world — including in Warsaw and several other locations in Europe. CloudFront keeps a copy of the site’s files on these edge servers and serves them to the visitor from the point closest to them. A user in Poland gets the site from Poland, not from a server across the ocean. On top of that comes an SSL certificate (the padlock in the browser) and automatic compression.

This architecture scales itself. A sudden surge of traffic — an article linked from a popular site, an ad campaign, a seasonal peak — makes no difference to how it runs. The CDN is designed for traffic orders of magnitude larger than any business site will ever see. On shared hosting the same scenario often ends with a resource-limit-exceeded message, and on precisely the day the site had the most to earn.

Speed: TTFB and Core Web Vitals

The difference between the architectures shows up most clearly in the TTFB metric (time to first byte) — the time from sending a request to receiving the first byte of the response. In that window WordPress has to run the whole PHP + MySQL chain described above; typically that takes a few hundred milliseconds, and on overloaded shared hosting it can be worse. A static site on a CDN sends a finished file from a server a few dozen kilometres away — a TTFB in the tens of milliseconds is the norm, not an achievement.

Google measures site quality with a set of Core Web Vitals metrics (including LCP — the time to display the main content) and factors them into search rankings. A WordPress site can hit green scores, but it takes work: caching plugins, database optimisation, slimming down the theme, compressing images — and staying vigilant that the next plugin doesn’t ruin it. A static site built with Astro on a CDN has green Core Web Vitals almost by definition, because there’s nothing in it that could slow it down. We break this topic down in detail in our article on how to build the fastest business website.

Speed isn’t a technical fetish. A slow site loses some of its visitors before they read anything — and on mobile devices, over a cellular network, every needless second hurts twice as much.

Upkeep costs: an annual bill, not a project price

When comparing costs, most breakdowns stop at the price of building the site. Yet the difference builds up over years of upkeep.

WordPress per year:

• hosting with PHP and a database — a sensible (not the cheapest) option is typically PLN 200–600/year,
• renewals of paid plugin and theme licences — often PLN 100–500/year,
• technical maintenance (updates, backups, monitoring) — either an agency subscription, usually from PLN 100–300 a month, or your own time, or the risk described in the security section,
• the cost of an incident, if there was no maintenance — hard to predict, but real.

Static website per year:

• S3 + CloudFront for a typical business site — a cost of single-digit PLN a month, often less,
• domain — the same as with WordPress,
• technical maintenance — none; there’s nothing to update.

You’ll find the full breakdown with concrete figures in our guide on how much a business website costs. The short version: over a three-year horizon a static site can cost less than WordPress hosting alone over that period — without counting a single złoty for anyone’s time.

The comparison in a table

Criterion	WordPress	Static website (Astro + AWS)
Security	Needs constant care; plugins are the main way in, login panel publicly accessible	No database, PHP or panel — practically no attack surface
Speed	TTFB typically hundreds of milliseconds; green Core Web Vitals require optimisation and vigilance	TTFB in the tens of milliseconds with a CDN; green Core Web Vitals by definition
Upkeep	Core, theme and plugin updates every week or two; backups; monitoring	Zero — there’s no server software that ages
Annual costs	Hosting PLN 200–600 + licences + maintenance (often PLN 1,200–3,600/year with an agency)	Infrastructure for a few dozen złoty a year, no maintenance
Who it’s for	A large blog with a team of editors, a WooCommerce shop, a portal with integrations	A business site, brochure site, landing page, service offering — content changed occasionally

Honestly: when WordPress wins

We’re not writing this article to prove WordPress is bad. It’s excellent — for the jobs it was built for. Specifically:

A large blog or portal with many editors. If several people publish content daily, each with their own login, permissions and a queue of drafts awaiting approval — WordPress’s editorial dashboard is mature, battle-tested and hard to replace. A static site can have a blog too (you’re reading this article on one), but with a big editorial team WordPress’s workflow simply wins.

An online shop on WooCommerce. Cart, inventory, payments, invoices, product stock changing by the minute — that’s dynamic data by nature. You can build it on a static architecture with external services, but WooCommerce with its huge ecosystem of integrations (couriers, payments, ERP) is the pragmatic choice here.

Lots of integrations and off-the-shelf features. A login area for customers, calendar bookings, a forum, a catalogue with search and database-backed filtering — if the site is meant to be an application, WordPress’s plugin ecosystem lets you assemble it quickly. You pay for it with the attack surface described above, but sometimes that trade-off is justified.

Daily self-service content editing by a non-technical person. With a static site, changing content requires a fresh build — in a well-configured process that’s automatic, but it’s still a process. If you want to personally tweak your copy three times a day in a visual editor, WordPress gives you that on the spot.

If you recognise your business in any of these points — choose WordPress and budget for proper technical maintenance, because without it all the problems from the first half of this text come back.

If, on the other hand, you need a site that presents your company, your offering and how to get in touch — and the content changes a few times a year, not a few times a day — then every element of WordPress’s architecture is needless risk and needless cost for you.

How we do it at Sitario

Sitario builds exactly the architecture you’ve just read about: a site built in Astro, served from Amazon S3 via CloudFront, with an SSL certificate and green Core Web Vitals. No database, no plugins, no panel to keep an eye on — which means no monthly chores on your end.

The whole thing is maintenance-free in both directions: you don’t configure AWS or learn generators, and we don’t send you invoices for “technical maintenance”, because this architecture doesn’t need it. A site with a year of hosting costs PLN 249. You’ll find the details and examples on the Sitario homepage.

And if after all this you’re still torn between the two options — write to us and describe what the site is supposed to do. If your case is WordPress, we’ll tell you so straight out. We’d rather send you to the competition than build something that doesn’t fit the job.