Website speed: why hand-coded sites load faster

Open your company website on your phone, on mobile data, standing in a parking lot. Count how long it takes before you can read the headline. If you got past three, you're in the majority, and that majority is losing inquiries it never sees.

Here's the short answer on website speed. Most slow business sites aren't slow because of the visitor's connection or a bad hosting day. They're slow because every visit downloads far more code, images and scripts than the page needs, much of it put there by a theme, a page builder or a stack of plugins. A hand-coded site ships only what that page uses, so there's simply less to download and less for the phone to work through.

What Google measures when it talks about speed

"Speed" is a vague word, so Google split it into three numbers called Core Web Vitals. According to Google's web.dev documentation, the targets are:

Largest Contentful Paint (LCP) within 2.5 seconds. Roughly: how long until the main thing on screen, usually the hero image or headline, has appeared.
Interaction to Next Paint (INP) of 200 milliseconds or less. When someone taps a button or opens the menu, how long before anything visibly happens.
Cumulative Layout Shift (CLS) of 0.1 or less. Whether the page jumps around while loading, so the visitor taps the wrong link.

Two details matter more than the numbers themselves. Google judges these at the 75th percentile of real visits, so the slower quarter of your visitors counts as much as you do on office fiber. And mobile and desktop are assessed separately. A site that flies on the CEO's laptop can fail on the phones your customers actually use.

INP replaced First Input Delay in 2024, and heavy JavaScript hurts it most: a phone busy running scripts can't respond to a tap.

Does website speed affect Google rankings?

Yes, but less than some agencies would have you believe. Google says good Core Web Vitals align with what its core ranking systems seek to reward. In the same breath, its page experience guidance is blunt that a good score doesn't guarantee a top position, and that the most relevant content can still rank with a mediocre experience.

Our honest reading: speed is a tie-breaker in search and a much bigger deal in conversion. The real money is in what happens after the click.

What slow pages cost a business

The best-known study on this is Deloitte's Milliseconds Make Millions, commissioned by Google. It tracked 37 European and American brand sites and more than 30 million sessions. A 0.1 second improvement across a set of speed metrics was linked to an 8.4% lift in retail conversions and a 21.6% lift in form submissions on lead-generation sites. The data is from late 2019, so treat the exact percentages as a snapshot. The direction hasn't changed.

For most businesses we work with, that 21.6% is the number to sit with. The quote form and the "call us" button both sit at the bottom of a page the visitor has to wait for.

There's also a cost your visitors pay directly. A large share of visits now come from phones, often on mobile data instead of Wi-Fi. A 3MB video background is spending your customer's data plan.

Why is my website slow? Where the weight comes from

The HTTP Archive's 2025 Web Almanac puts the median mobile home page at about 2.56MB, made up of 72 requests, including roughly 632KB of JavaScript and 911KB of images. The mobile home page has grown 8.4% in a year and roughly tripled since 2015.

When we audit a slow site, the causes are nearly always some mix of the same five:

Code for features the page doesn't use

A commercial theme is built to sell to thousands of buyers, so it includes sliders, galleries, shop layouts and a dozen header styles. Your contact page loads the stylesheet and scripts for all of them. Page builders add their own layer on top: the builder's front-end library, icon fonts, and widget styles, loaded on every page whether a widget appears there or not.

Too many nested boxes

Drag-and-drop builders wrap each element in several containers (section, column, inner section, widget wrapper) to make the editing interface work. The visitor doesn't see them, but the phone has to lay out every one. Google's Lighthouse tool starts warning at about 800 elements on a page and flags an error at about 1,400. We regularly see builder pages well past that for a heading, three boxes and a form.

Scripts that block the page

Every plugin that adds a chat widget, a cookie banner, a pop-up or a tracking tag tends to put a script in the page head. The browser stops and fetches each one before it draws anything. The 2025 Almanac performance chapter found only 15% of mobile pages passed Lighthouse's render-blocking resources audit.

Images uploaded straight from a camera

A 5MB photo scaled down with CSS still downloads at 5MB. So does a PNG logo that should have been an SVG. That's a process problem, fixable on any platform.

A lazy-loaded hero image

A small one with a big effect. Lazy loading tells the browser to delay images until they're needed, which is right for photos further down the page and wrong for the big banner at the top. The same Almanac chapter found around 16% of pages lazy-load the very image Google uses to measure LCP.

How a hand-coded page gets its speed

Nothing magical. When a developer writes the page by hand, the stylesheet contains the rules that page uses and nothing else. There's no builder library, because there's no builder. The page has as many elements as the design needs. Scripts are added one at a time, with a reason, and loaded after the content where possible. The hero image gets a fixed size (so nothing jumps) and is told to load first.

The bigger advantage is that it stays that way. On a hand-built site, adding a feature means a developer writing it, which forces the question "what does this cost the page?" every time.

This is why the websites in our website design packages are built with speed optimization and WebP images as standard rather than as an add-on, and why the 15–25 page package includes Core Web Vitals work specifically.

To be fair to WordPress

A well-built WordPress site can be fast. It takes a lean theme, very few plugins, careful caching, and someone who says no to the fourth slider plugin. What it doesn't do is stay fast by default.

The 2025 Almanac CMS chapter found 45% of WordPress sites passed Core Web Vitals on mobile. Tightly managed platforms did better (Wix passed at 74%), and the chapter's own observation is that the more extensible platforms improved less. That fits what we see: WordPress's flexibility is exactly what lets a site bloat.

So if you have a WordPress site that scores well, leave it alone. Rebuilding for the sake of it would be a waste of your money. If you want the full trade-off between routes, we compared them in custom website vs WordPress vs an AI builder.

Test your website speed in three minutes

Go to pagespeed.web.dev, paste in your home page address and click Analyze.
Make sure the Mobile tab is selected. That's where most sites fail and where most of your visitors are.
Look at the top section first, headed "Discover what your real users are experiencing". This is field data from real Chrome users over the past 28 days, and it's what Google uses. If it says "Passed" for Core Web Vitals, you're in decent shape.
Then look at the performance score below it (0–100). According to Google's PageSpeed documentation, 90 and above is good, 50–89 needs improvement, and below 50 is poor. This is a lab test on a simulated mid-range phone, so it moves a few points between runs. Run it twice.
Repeat for your busiest service page and your contact page.

If the field data section is missing, your site doesn't get enough Chrome traffic for Google to report on, and the lab score is all you have to go on. A mobile score in the 40s on a brochure site is a red flag, because a brochure site has no good reason to be heavy. And if the "Diagnose performance issues" list mentions reducing unused JavaScript, eliminating render-blocking resources and an excessive DOM size all at once, you're almost certainly looking at the theme-and-builder problem described above.

Don't chase 100. A solid 90-something with a clean field-data pass beats a perfect lab score won by deleting the chat widget your sales team relies on.

Hosting: the part nobody sees

Everything above is about what the page sends. Hosting is about how quickly the server starts sending it. Google's guidance is that time to first byte should be 0.8 seconds or less, which includes DNS lookup, the secure connection and the server building the page.

Distance plays a part. If your customers are in one country and your site sits on a cheap shared server on another continent, each of those connection steps is a round trip across an ocean before a single pixel appears.

This is the reason we don't outsource our servers. Our in-house server team, led by Franro (16+ years in IT, 13+ on Unix), sets up and watches the machines our clients' sites run on, and we've held over 99% uptime for the past five years. When a site is slow, there's no support ticket to a third-party hosting company. There's more on how that works on our hosting page.

What a fast site feels like to run

The goal isn't a green number in a report. It's a site where the quote form loads before the customer loses interest, where your Google Ads clicks land on a page that's already there, and where you don't get a text from your sales manager saying "the website's slow again" on a Friday afternoon.

If you've just run the test and don't like what you saw, send us the link. We'll look at the report and the site, and tell you plainly whether it needs tuning, a hosting change, or a rebuild. If a rebuild is on the table, our page-builder to custom code case study shows what that process looks like, or you can get in touch here.

Frequently asked questions

What is a good website loading speed?

By Google's Core Web Vitals, the main content should appear within 2.5 seconds, the page should react to taps within 200 milliseconds, and the layout shouldn't shift more than a score of 0.1. Those need to hold for 75% of real visits, measured separately on mobile and desktop.

Why is my website slow on mobile but fine on desktop?

Phones have slower processors and often slower connections, so heavy JavaScript and large images hurt far more. Your desktop test is also probably on office fiber. PageSpeed Insights tests mobile on a simulated mid-range phone, which is closer to what your customers use.

Is a PageSpeed score of 100 necessary?

No. Aim for passing Core Web Vitals in the field data and a lab score in the 90s on mobile. Pushing from 95 to 100 rarely changes anything a visitor notices, and it can mean removing tools your business actually uses.

Can a WordPress site be as fast as a hand-coded site?

It can, with a lean theme, few plugins, good caching and disciplined upkeep. The difference is that WordPress sites tend to slow down as plugins accumulate, while a hand-coded site only gets heavier when a developer deliberately adds something.

Does hosting location matter for website speed?

For a site whose visitors are mostly in one country, a server on another continent adds a delay before the page even starts downloading, because the connection setup takes several round trips. Server quality and how many other sites share it matter just as much as location.

Website speed: why hand-coded websites load faster