What “hand-coded” actually means
When we say a site is hand-coded, we mean every line of HTML, CSS, and JavaScript on it was written specifically for your business — not pulled from a theme and then bent into shape with plugins. There’s no WordPress core, no page builder, no third-party plugin marketplace involved at all.
That sounds like a small technical distinction, but it changes almost everything about how the site performs once it’s live.
The real cost of a plugin ecosystem
A typical small-business WordPress site isn’t just WordPress. It’s WordPress, plus a page builder, plus a contact form plugin, plus an SEO plugin, plus a caching plugin, plus a security plugin, plus whatever the theme itself bundles in to make its demo look good. Each one ships its own CSS and JavaScript — and a lot of that code loads on every page, whether that page needs it or not.
It adds up fast. A simple five-page brochure site can end up shipping a couple of megabytes of code before a single photo has loaded, just from plugin overhead the visitor never sees and didn’t ask for.
Why speed is a ranking factor, not just a nice-to-have
Google has used page experience signals, collectively known as Core Web Vitals, as an official ranking factor since 2021. But even setting the literal ranking algorithm aside, speed shapes behaviour: slower pages have higher bounce rates, and Google’s systems pick up on that pattern too.
A hand-coded site starts from zero instead of starting from a stack of dependencies you then have to optimise away. There’s nothing to strip out, because nothing unnecessary was added in the first place.
The security risk that comes with the same plugin stack
The plugin ecosystem that slows a site down is also the thing that gets it hacked — that’s not a guess, it’s measured. Patchstack’s State of WordPress Security in 2026 report found 11,334 new vulnerabilities disclosed across the WordPress ecosystem in 2025 — 91% of them in plugins, not WordPress core, and nearly half with no patch available at the moment they were publicly disclosed. Security firm Sucuri’s own hacked website threat report found a vulnerable plugin or theme present in over a third of the compromised sites it remediated.
WordPress core itself isn’t the problem — the same Patchstack report counted only a handful of low-risk issues in core for the whole year. It’s the plugin stack bolted on top of it, the same one responsible for the speed problem above, doing the damage.
A hand-coded site has nothing equivalent to inherit. There’s no ratings-widget plugin quietly sitting on the server two years after whoever built it stopped maintaining it, waiting to be the way in.
How to check if this actually matters for your site
You don’t need to take any of this on faith. Run your own URL through Google’s PageSpeed Insights and look at the total page weight and request count alongside the LCP score — then run a competitor’s WordPress site through the same tool. The gap in transferred kilobytes is usually the clearest evidence of where a plugin stack is costing you.
Chrome DevTools’ Network tab (open it, reload the page, sort by size) will show you exactly which files are loading and how big they are. On a typical small-business WordPress site, it’s common to see ten or more separate CSS and JS files firing before the visible content even renders — most of them from plugins doing work that page doesn’t need.
What “fast enough” actually means in practice
Core Web Vitals aren’t a vague “make it feel snappy” target, they’re three specific, measurable thresholds Google publishes and scores against directly: Largest Contentful Paint (LCP) under 2.5 seconds, Interaction to Next Paint (INP) under 200 milliseconds, and Cumulative Layout Shift (CLS) under 0.1. A site that clears all three sits in Google’s “good” band; a site that misses even one gets marked as needing improvement, regardless of how fast the rest of it feels.
Plugin-heavy WordPress sites tend to miss on LCP and INP specifically, and for the same underlying reason: a page builder’s CSS often blocks the browser from painting the main content until it’s fully parsed, and a stack of plugin JavaScript competing for the main thread is exactly what makes a page feel sluggish to tap or scroll on a phone, even after it’s visually loaded. A hand-coded page has far less script fighting for that same thread, which is most of why the INP gap is usually the starkest difference in a side-by-side comparison.
The maintenance cost most WordPress budgets don’t include
The ongoing cost of a plugin-based site isn’t just the risk covered above, it’s the recurring work of keeping ten-plus plugins, a theme, and WordPress core all compatible with each other, indefinitely. Every plugin update is a small chance that it conflicts with another plugin or the active theme, and every WordPress core update carries the same risk in the other direction. Skip updates to avoid that risk and you’re back to the security exposure from unpatched software; apply them and you’re signing up for periodic breakage that needs someone to diagnose and fix.
A hand-coded site sidesteps this category of cost entirely, not by managing it better, but because there’s no dependency web to keep synchronised in the first place. The code that shipped at launch is still the code running today unless someone deliberately changes it — nothing updates itself out from under you, and nothing needs a compatibility check before it’s safe to leave alone.
What migrating away from WordPress actually involves
The two things people worry about most are losing their content and losing their rankings, and both are manageable with the right process. Existing pages, blog posts, and images get migrated across as part of the rebuild — nothing needs to be retyped from scratch. The bigger job is making sure every old URL 301-redirects to its new equivalent, so any backlinks or bookmarks pointing at the old site still land somewhere valid instead of a 404.
Rankings typically dip slightly for one to two weeks while Google re-crawls and re-indexes the new site, then recover and usually improve past the old baseline once the speed gains kick in — assuming the content itself didn’t change and the redirects are done properly. It’s not something to do carelessly, but it’s a well-understood process, not a leap of faith.
Common WordPress speed myths
| Myth | Reality |
|---|---|
| “A caching plugin fixes it” | Caching speeds up the server response, but doesn’t remove the CSS/JS your visitor’s browser still has to download and run |
| “A premium theme is faster than a free one” | Price has nothing to do with code discipline — many premium themes ship with a page builder baked in |
| “Fixing this needs a full rebuild” | Often it’s the plugin stack, not the content, that needs replacing |
Caching plugins help. They save a pre-built version of the page instead of assembling it fresh on every request, but they don’t remove the underlying CSS and JavaScript your visitor’s browser still has to download and run. Caching speeds up the server response; it doesn’t touch the plugin bloat that’s shipped to the browser afterward.
A premium theme being faster than a free one isn’t reliably true either. Price has nothing to do with code discipline. Plenty of premium themes ship with a page builder baked in and every demo feature toggled on by default, which is the opposite of lean. The only way to know is to check the actual page weight, not the price tag or the marketing copy.
The honest trade-off
It’s not all upside. A hand-coded site can’t have a brand-new feature bolted on with a $40 plugin the way a WordPress site can — adding something genuinely new means writing it. For a lot of small businesses that’s a fair trade: you give up some last-minute flexibility in exchange for a site that’s faster, simpler to maintain, and has nothing running in the background you didn’t explicitly choose to put there.
The businesses for whom that trade doesn’t make sense are usually the ones that genuinely need a large content team publishing daily, or a plugin ecosystem specific to a use case, like membership sites or complex e-commerce, that would otherwise mean building the same functionality from scratch. Outside those specific cases, most small-business sites are using a fraction of what WordPress’s plugin ecosystem exists to support, while paying its full speed and security cost regardless.
See our custom web design page for how we build hand-coded sites for Sydney businesses. Speed is only half of local visibility — see our local SEO checklist for Sydney businesses for the rest.
Weighing this against a template builder instead of WordPress specifically? See Wix vs. Squarespace vs. hand-coded for that version of the same trade-off.