I am proud when a new build produces a strong PageSpeed result. I also treat that result carefully: a controlled lab score describes one page under a particular test condition. It is a useful build signal, but it does not stand in for everyday customer experience.
When a business is paying to rebuild a website, it should not inherit avoidable waiting, jumping layouts, giant images, or a small pile of scripts nobody can explain. A strong performance result is evidence that those decisions were considered early.
Think of the score as a build receipt. It records one important part of the work: how efficiently a page reached the browser under the test conditions.
What a PageSpeed result can tell you
PageSpeed Insights gives you two different kinds of information.
The first is a controlled Lighthouse test: one page, a simulated device and connection, and a set of diagnostics. That is excellent for spotting technical friction and comparing changes. The second, when a site has enough traffic, is field data from Chrome users over the previous 28 days. Google is clear that the two can differ: a lab test is controlled; field data reflects real devices, networks, and conditions. Google explains the distinction here.
Treat a desktop test with no field data as a snapshot of one page at one moment. Customer experience, search performance, and conversion each need their own evidence.
Google makes the ranking part equally plain: Core Web Vitals are used in its systems, but good scores do not guarantee top rankings. A relevant, helpful page can outrank a technically cleaner page. Google also advises against spending your time chasing a perfect score solely for SEO. That guidance is worth reading before anyone starts optimizing for a screenshot.
Performance still changes the conditions under which everything else has to work. A visitor cannot evaluate your offer while a huge hero image is arriving, a layout is shifting under their thumb, or a form is waiting on unnecessary code. Faster, more responsive pages can improve engagement in particular contexts, but the honest way to evaluate the business impact is to measure the actual journey on the actual site—not borrow a conversion lift from somebody else’s case study. web.dev makes the same distinction between performance work and business measurement.
I use three receipts when I look at a website
Performance is one receipt. A useful website needs two others.
| Question | The useful receipt | What it cannot prove |
|---|---|---|
| Can the site get out of the visitor’s way? | PageSpeed diagnostics, mobile testing, and—once enough traffic exists—real-user field data. | That people understand the offer or take action. |
| Can search find and understand the page? | Crawlability, clear text, internal links, page-level relevance, and Search Console evidence over time. | That the page will rank first or be cited by an AI answer. |
| Can a potential customer actually use it? | A clear service explanation, an obvious next step, accessible interaction, and an end-to-end test of the form or phone path. | That the business will respond, qualify the inquiry, or close the sale. |
All three receipts matter. Together, they provide a more useful picture than a green circle alone.
That is why I separate foundational technical work from claims of a special “AI optimization” layer. Google says its AI search features do not need special markup, AI text files, or new technical requirements. The same fundamentals apply: allow crawling, make important information available as text, use structured data that matches what people can see, and make the page useful. Google’s current AI-features guidance is refreshingly direct on this.
Modern technology supports the first receipt. Search and business evidence complete the picture.
Why I stopped starting with WordPress for many new builds
WordPress can be fast, useful, and completely appropriate for the business that owns it.
A new site can become heavy by accumulation: a page builder on top of a theme, a plugin for a small visual effect, another one for a form, several tracking tags, oversized images, a chat widget, two font families, and a marketing request that sounds harmless in isolation. Each decision may be reasonable. Together, they can make the site harder to understand, maintain, and keep quick.
For many new builds, I prefer starting with a modern custom stack because it makes those decisions explicit from day one. If a script ships, there should be a reason. If an image is large, there should be a reason. If a form relies on a third party, we should know what is being handed off and how it will be tested.
The editing model belongs in that decision. WordPress is often practical when a non-technical team needs to make regular updates themselves. A custom build should include an equally clear CMS or support plan, so ordinary page changes do not unexpectedly require a developer.
Some businesses need self-service publishing. Others benefit from a smaller, intentionally controlled custom system. Start with the ongoing operating model: who edits the site, who owns updates, what integrations are truly necessary, and how much complexity the business wants to carry.
How SvelteKit fits in
SvelteKit is one of the tools I use for custom builds. Its value lies in Svelte’s compiler-based approach: it turns component code into efficient browser work rather than asking the browser to carry a large framework runtime for every page. That is how Svelte describes its own approach.
That approach creates a simpler starting point. Image discipline, restrained third-party tools, accessible HTML, and clear content still determine how the finished page behaves.
A SvelteKit site can still be slow if it ships a giant video, loads five third-party widgets, uses the wrong image format, or hides the useful content behind unnecessary interaction. A careful WordPress site can remain quick. The framework establishes the browser work you start with; the build decisions determine what visitors ultimately experience.
The decisions that usually matter more than the framework
When I am trying to protect performance on a new website, I care less about winning a framework argument and more about a few repeatable choices:
- Treat the first screen as a budget. The headline, service explanation, visual proof, and call to action should arrive without making a phone download half the internet.
- Make images earn their weight. Serve an appropriate size and format, reserve their dimensions so the page does not jump, and do not put a large background image where a smaller useful image would do.
- Be ruthless about client-side JavaScript. A little interaction can be valuable. A pile of code to create the appearance of a modern site is rarely a business advantage.
- Treat third-party tools as tradeoffs. Analytics, chat, scheduling, maps, review widgets, and ad tags can all be useful. They should have an owner and a reason—not simply survive because nobody is sure what will break if they disappear.
- Keep the important answer visible. Search engines, AI systems, and people all benefit when the service, location, proof, and next step are stated plainly rather than hidden inside animation or an image.
- Test the path a customer actually takes. Check mobile, use the buttons, submit the form with permission, verify the saved record and notification, and revisit performance after launch instead of declaring victory on deployment day.
Visual and technical choices can pull in the same direction. They make a site feel intentional rather than stripped-down or generic.
Reading a PageSpeed screenshot well
If a developer shows you a score card, ask four follow-up questions:
- Is this mobile or desktop, and is it a controlled lab test or real-user field data?
- Which page was tested? A lightweight homepage and a long service page may behave differently.
- What changed to earn the score, and what tradeoffs were made?
- How will we verify that the page is findable and that the inquiry path works after launch?
A good builder should welcome those questions. They make the conversation less about a green circle and more about the quality of the finished system.
Build the fast version of the right website
Build the site that makes it easy for a real business to be understood before a visitor loses patience.
That is why I care about modern web technology. It gives me more control over what a new site asks from a visitor’s device, makes performance easier to protect as the site grows, and keeps the basic job in view: clear information, a credible next step, and fewer avoidable obstacles between the two.
High PageSpeed scores become a useful build receipt. Paired with search and business receipts, they show a website working across its full job.