WordPress or a Custom Website? An Honest Comparison on Speed and Security

First, let's define the terms

• WordPress site: A site built on the open-source WordPress content management system (CMS), with its look provided by a theme and extra features by plugins. Pages are usually generated on the server from a database on every visit, and the admin panel runs on the same server.
• Custom website: A site designed and coded from scratch around a business's needs. Instead of a stack of ready-made themes and plugins, only the components that are actually needed are written. For corporate sites, this usually means a lean static architecture in which pages are generated in advance and served directly; a separate, simple panel can be added for content management if needed.
• The middle path, "headless" WordPress: Content is managed in the WordPress panel, while the site visitors see is a separate, custom-coded front end. It preserves editors' habits but requires maintaining two systems.

Why is WordPress so widespread?

It would be wrong to start by dismissing WordPress. According to HTTP Archive's 2025 Web Almanac, more than 54% of the websites it observed run on a CMS, and WordPress powers roughly 64% of those CMS-driven sites. That popularity brings real benefits:

• A fast start and low upfront cost with ready-made themes and plugins,
• An easy time finding developers and agencies who know WordPress,
• A mature editing experience for blogging and news publishing,
• Ready-made infrastructure for many editors, roles and publishing workflows.

The problem lies less with WordPress itself than with what a typical WordPress installation turns into over time: a page builder, a few visual-effects plugins, then plugins for forms, SEO, caching, security, backups, translation and social media... Each one looks reasonable on its own; together they form a heavy stack that affects both speed and security.

Speed: what do visitors and Google see?

The "good" thresholds for the Core Web Vitals that Google uses to measure page experience are as follows (web.dev): LCP (loading of the largest content element) of 2.5 seconds or less, INP (responsiveness to interactions) of 200 milliseconds or less, and CLS (visual stability) of 0.1 or less. The assessment is made at the 75th percentile of page loads, which means the large majority of visitors should fall within these limits.

HTTP Archive's 2025 Web Almanac data shows that WordPress sites struggle here:

• Only 45% of WordPress sites pass Core Web Vitals on mobile; the report places WordPress among the lowest-ranked platforms on this measure.
• The median Lighthouse performance score for WordPress sites is 41 on mobile and 63 on desktop.
• The median weight of a WordPress page on mobile is about 2,894 KB.

These figures don't mean "WordPress can't be fast"; there are well-optimized WordPress sites with few plugins. What they show is that an average installation works against speed. On a lean custom-coded site, speed doesn't come from a plugin added later but from decisions made at the start: only the code that is used gets shipped, images are prepared at the right size in modern formats, and because pages are generated in advance, the server doesn't run a database query on every visit.

A real example: Luniva Plastik

For Luniva Plastik, the starting point was a Turkish-only, nearly empty WordPress page. We replaced it with a four-language B2B export site built on a lean static architecture. The values we measured:

• The home page's first load is about 57 KB across 5 requests in total,
• No third-party requests (no connections to external font, tracking or widget servers),
• CLS 0 (nothing shifts while the page loads),
• 0 errors in automated checks across all 77 pages.

This measurement isn't a like-for-like comparison using the same method as the Web Almanac's median page weight, but the difference in scale shows concretely what a lean architecture can deliver.

Does speed guarantee rankings?

No, and it's worth saying so plainly. Google states that Core Web Vitals are used by its ranking systems, but it also says clearly that it seeks to show the most relevant content even when the page experience is sub-par. Speed makes a difference between pieces of content of similar quality; it doesn't replace content. For details, see our Core Web Vitals guide. The real payoff of speed often shows up with users before it shows up in rankings: a purchasing manager opening your site on mobile data won't wait for the page to load.

Security: where does the attack surface grow?

Security company Patchstack's "State of WordPress Security in 2026" report, which covers 2025 data, paints a clear picture:

• 11,334 new vulnerabilities were reported in the WordPress ecosystem in 2025, a 42% increase over 2024.
• 91% of these vulnerabilities were found in plugins and 9% in themes. Only 6 were reported in WordPress core, and those were low priority.
• 46% of the vulnerabilities had not yet been fixed by their developer at the time of public disclosure.
• For heavily exploited vulnerabilities, the weighted median time to the first exploit is 5 hours; roughly half of high-impact vulnerabilities are exploited within 24 hours.

The lesson is this: WordPress core is fairly well protected; the risk grows with every plugin and theme added to the site. The more third-party code your site runs, the more you have to trust the developer behind each piece of it. The A03: Software Supply Chain Failures category in OWASP's 2025 Top 10 describes exactly this: components that are vulnerable, unsupported or out of date, and that aren't updated in a timely fashion.

Four things that make WordPress security harder

1. Plugin and theme vulnerabilities: As the figures above show, most vulnerabilities come from here. There may be only hours between a vulnerability's disclosure and its exploitation.
2. The update burden: WordPress's own security guide recommends always keeping core and plugins up to date and deleting plugins you don't use. But every update carries the risk of incompatibility with another plugin or a broken layout, which is why many businesses postpone updates.
3. A publicly exposed admin login: The admin panel runs at the same address and on the same server as the site. WordPress documentation describes brute-force password guessing as a common attack, notes that even unsuccessful attempts can overwhelm a site with requests, and recommends two-step authentication as an extra layer of protection.
4. Abandoned plugins: A plugin installed years ago, whose developer no longer maintains it, can remain an open door without anyone noticing.

Is a custom-coded site more secure?

When built correctly, its attack surface is significantly smaller, but it isn't "unhackable." What makes the difference:

• In a lean static architecture, visitors are served pages prepared in advance; there is no publicly reachable database query, no plugin code and no admin panel running inside the site.
• Only the components actually in use are present; there is no plugin that "nobody knows what it does."
• Dynamic parts such as forms are written as small, auditable pieces and protected with validation and multi-layer spam protection.

Custom sites also use libraries, and those need updating too; the difference is that these components are few and well known, and updates can be tested before they go live. That's why, when you commission a custom site, the contract should also state in writing who is responsible for maintenance and security updates. If you'd like to look at your overall cyber security setup beyond your website, see our backup and cyber security service.

Comparison table

When is WordPress still the right choice?

To be fair, seriously consider WordPress in the following situations:

• You run a content-heavy site: Several posts go out every week, and there are multiple editors, authors and an approval workflow.
• Your budget is very limited: You need to be online right away and can't set aside a budget for custom design. In that case, starting with a good theme and few plugins makes sense.
• Your team already knows WordPress: If someone in-house regularly applies updates and keeps track of plugins, a large part of the risk can be managed.
• What you need is ready and mature in the WordPress ecosystem: For example, features such as memberships or a simple events calendar that a well-maintained plugin covers.

Even in these scenarios: keep the number of plugins to a minimum, choose only regularly updated plugins, delete the ones you don't use, turn on two-step authentication for admin accounts and don't postpone updates.

When does a custom site pull ahead?

• Your site is a sales channel, not a publishing platform: Content changes a few times a month at most; the real goal is to build trust, present the product and collect inquiries.
• Speed and first impressions are critical: Your visitors come from mobile devices, from different countries, on slow connections.
• No one is assigned to security and maintenance: A "set it and forget it" WordPress install is the most dangerous scenario.
• A multilingual structure and technical SEO matter: You want language versions, hreflang, sitemaps and structured data set up correctly from the start. For a list of these steps, see our technical SEO checklist.
• You want a design unique to your brand: An interface that reflects your corporate identity without being boxed in by a theme.
• Ownership matters: You want the code, the design and the data to belong to you and to be transferable to another team.

A custom site doesn't mean giving up content management, either. On the Royal Class Garage site, for example, the team can update content from a management panel. What matters is choosing the panel to fit the need and not leaving it publicly exposed without reason.

How should you look at total cost?

On the first invoice, WordPress almost always looks cheaper. For a fair comparison, consider at least a three-year picture:

For WordPress: setup + paid theme and plugin licenses (most renew annually) + hosting + the time spent on regular updates and compatibility testing + a security plugin or service + the cleanup and reputational cost of a possible attack.

For a custom site: design and development fee + hosting + annual maintenance (library updates, minor content and design changes).

This calculation doesn't always favor a custom site; for teams that produce content frequently, WordPress may remain the more economical option. For a general decision framework, our article on custom vs. off-the-shelf software applies the same logic to software as a whole. When comparing proposals, our checklist on how to evaluate a software proposal will also come in handy.

Decision checklist: 8 questions

Give yourself 1 point for every "yes":

• 0–2 points: A well-maintained WordPress site with few plugins is most likely enough.
• 3–5 points: Both paths are worth considering; evaluate a headless setup or a custom site with deliberately simple content management.
• 6–8 points: A lean custom-coded site is a strong candidate.

When moving from an existing WordPress site

The biggest risk in a migration is losing the search traffic built up over the years. To prevent that:

1. Take a URL inventory: List every page that receives traffic or links.
2. 301-redirect old addresses to their new counterparts: Don't let any page disappear silently.
3. Move and improve the content: Valuable articles are kept, while empty or duplicate pages are merged.
4. Monitor after launch: Keep a close eye on indexing and 404 errors in Search Console during the first weeks.

For the step-by-step process, read our guide to avoiding SEO loss during a site migration.

Common mistakes

• Choosing a platform because it's fashionable: Neither "everyone uses WordPress" nor "WordPress is outdated" is a reason to decide; your needs and maintenance capacity are what count.
• Installing a new plugin for every need: Every plugin adds both weight and a new security responsibility.
• Postponing updates: Some vulnerabilities are exploited within hours of being disclosed.
• Leaving a custom site unmaintained: Custom code also needs library updates and regular checks.
• Forgetting redirects during migration: No matter how good the new site is, traffic drops if old addresses break.

Sources

• Patchstack — State of WordPress Security in 2026 (2025 data)
• HTTP Archive — Web Almanac 2025, CMS chapter
• web.dev — Web Vitals
• Google Search Central — Understanding page experience in Google Search results
• OWASP Top 10:2025 — A03 Software Supply Chain Failures
• WordPress Developer Resources — Hardening WordPress
• WordPress Developer Resources — Brute force attacks