How web development works
Static versus server-rendered sites, in plain terms
Every web page has to be put together before someone can see it. The question is when that happens.
A server-rendered site, like a typical WordPress install, builds each page when someone asks for it. The server runs code, queries a database, assembles the HTML and sends it back. Caching speeds that up, but there’s always a server doing work, and that server has to be kept updated and secure.
A static site, like one built with Astro, builds every page once, ahead of time, when the site is published. Visitors get ready-made HTML files that can be served instantly from anywhere. There’s no database for an attacker to reach and very little to keep updated.
For most marketing sites (service pages, about pages, blog posts and contact forms), the content doesn’t change between one visitor and the next, so building it in advance is the obvious choice. That’s why static sites usually load faster and pass Core Web Vitals with less effort. When you need dynamic features, like a booking widget or a live search, they can be added to just the pages that need them.
When custom code is worth it, and when it isn’t
Custom development isn’t always the right answer. It’s worth it when:
- Speed is part of the business case. Paid landing pages, competitive local markets or any site where a slow page loses money.
- You need something specific. A quote calculator, a multi-step form with logic, a filtered directory or an integration with your CRM.
- You’re paying to work around your current platform. Licences for premium plugins, a developer patching the theme, hosting upgrades to cope with bloat.
- Your designs deserve better. Page builders often lose the details a good designer worked hard on.
It isn’t worth it when:
- A well-built WordPress site would do the job. If your team publishes every day and relies on plugins, WordPress development is often the better fit.
- You need to launch something very simple, very fast, and you don’t expect it to grow.
- Nobody will maintain it. Every site needs an owner. Static sites need far less upkeep, but not zero.
I’ll tell you which side of that line you’re on before you spend anything.
How this site was built
This site is a working example of the approach, so here’s what went into it.
- Framework. It’s built with Astro and outputs plain HTML, CSS and a very small amount of JavaScript for the menu, the contact form and a light scroll effect.
- Styling. It uses Tailwind CSS with design tokens, so light and dark modes, spacing and type stay consistent across every page.
- Images. They’re processed at build time into modern formats (AVIF and WebP) at several sizes, so phones download small files and large screens get sharp ones.
- Fonts. They’re self-hosted, with the heading font preloaded so text appears quickly without layout shifts.
- SEO. Structured data, canonical URLs, a sitemap and clean trailing-slash URLs are generated automatically from the content files.
- Hosting. The finished site is a folder of static files on standard shared hosting. No Node.js server is needed in production.
In pre-launch testing, the home page scored 99 for performance and 100 for accessibility, best practices and SEO on Lighthouse’s mobile test, with a Largest Contentful Paint under two seconds and no layout shift. Those numbers aren’t the goal in themselves, but they mean visitors on a phone see the page almost immediately, and that matters for both rankings and conversions.
Speed and SEO from the first commit
On a custom build, SEO isn’t a plugin you add at the end. It’s part of the code from the start: one H1 per page, logical heading order, descriptive URLs, metadata pulled from the content, structured data that connects your business, services and FAQs, and a sitemap that updates itself when pages are added.
That’s also why custom builds pair well with ongoing SEO services. When the site is clean and fast to begin with, every hour of SEO work goes into content and authority instead of fixing the platform. And if you’re redesigning as well as rebuilding, my web design process plans the pages around keywords before any code is written.
Accessibility is part of the build
A fast site that some people can’t use isn’t finished. Accessibility is built in from the start: real headings in a logical order, enough colour contrast to read comfortably, visible focus outlines for keyboard users, form fields with proper labels and error messages, alt text on meaningful images, and menus that work without a mouse. Motion is reduced for visitors who ask their device for it.
This matters for three reasons. It’s the right thing to do, since a meaningful share of your visitors rely on it. It reduces legal risk in markets like the US and UK, where accessibility complaints against small business websites are no longer rare. And it overlaps heavily with good SEO, because clear structure and descriptive labels help search engines and AI tools understand your pages too.
If your current site is slow, limiting or expensive to keep alive, tell me about it below and I’ll send a fixed quote for a custom build.