From 358 MB to 2.3 MB: Why We Changed the Way We Build Websites

358 MB became 2.3 MB.

That is what happened when we recently rebuilt a client’s website using SERO’s headless model. The required content and functionality remained. What changed was the architecture underneath it.

The previous figure covered the complete deployed WordPress installation: core software, themes, plugins and associated website files. The replacement figure covers the complete public Astro deployment. At approximately 99.4% smaller, it is a substantial reduction in the deployed public website footprint.

This measures deployment storage, not homepage or page-transfer weight: visitors were not downloading 358 MB per page view. The separate Payload CMS still exists and uses its own storage, excluded from the new figure. The comparison shows how much application overhead was removed from this public deployment, not the total resource saving across both systems.

Using the rounded measurements, the reduction is 99.36%; the new deployment is about 0.64% of the previous footprint. The old installation was approximately 156 times the size. And size is only one reason we made the change.

The CMS and the website do not have to be the same application.

A content management system, or CMS, is the admin area where people update their website. In a conventional setup, that system also helps generate the pages visitors see. Content editing and public delivery are closely connected.

A headless setup separates them. The CMS stores and organises content; a separate frontend controls how it appears. The two communicate through an API: a defined way for one application to request information from another.

A business owner can update a service description without editing code. Their customers see that approved content inside a purpose-built website. The client retains content management, while SERO gains direct control over public delivery.

Headless does not necessarily mean static. For suitable SERO sites, we generate pages in advance, so ordinary visits can be served from ready-made files. The editing system does not have to construct each page as someone opens it.

How our new model works.

Our new website-development model pairs a custom central content platform built around Payload CMS with Astro frontends. Payload handles structured content and editing. Astro produces the website people visit. Payload’s overview explains its content and API capabilities; Astro’s CMS guide describes how a separate content source can feed a frontend.

1. Content is managed centrally. Pages, Services, Areas, Projects and Blog or Insights entries have defined fields and relationships. Client access is restricted to their own content.
2. Approved content is retrieved for a build. The website requests the information it needs through the API. A build is the process that turns content and design components into deployable website files.
3. Astro generates the public pages. Suitable pages are produced as HTML, with their styling, images and the JavaScript needed for interactions.
4. The generated website is deployed. Those files can be served on conventional hosting. Later approved content changes go through a controlled rebuild and deployment.

Visitors do not need to open the CMS to read a generated service page. The editing platform can change independently of how that page is delivered. Forms and other dynamic features still need appropriate server-side services; generating the pages in advance does not remove those responsibilities.

Why we made the change.

We wanted substantially greater control over the websites we build: their performance, generated HTML, responsive behaviour, frontend assets and ongoing standards. Separating content from presentation lets us make those decisions deliberately, around the business and its customers.

Structured content makes growth more manageable. A service can connect to relevant projects and areas through defined relationships. Adding content follows an established pattern, so a growing website is easier to keep coherent and useful.

Our central platform supports multiple clients with access limited to their own content. We can improve shared editing patterns and quality checks while giving each public website its own design. Clients get consistency where it helps them manage information and individuality where it matters to their brand.

This is a deliberate part of how we intend to build suitable websites going forward. The early results have reinforced that decision.

What happened to performance.

We have seen excellent early performance from this architecture, including A-grade results in our testing of the migrated client website. Performance was one of the reasons for making the change, and those early results support the direction we chose.

We have much tighter control over what a public page ships: which images it uses, how fonts load, which scripts are necessary and when interactions need browser-side code. That gives us better conditions for smaller page payloads, fewer unnecessary requests, faster rendering and less blocking work on mobile.

The architecture does not make performance automatic. It gives us far greater control over achieving it. Laboratory results are snapshots, not a guarantee that every visitor or future project will experience identical performance.

What does the client actually see?

The client gets a content area organised around their services, projects and articles. They can maintain appropriate information without managing code, using GitHub or running builds. Defined fields help keep updates consistent with the approved design.

Content is checked and approved, then the website is rebuilt and deployed through an agreed publishing process. Saving an edit and making it live are distinct steps; we agree the workflow around how frequently the business needs to publish.

For the business, this means a clear route from an update to a checked public page. New content can use the structure already in place, while a genuinely new layout or feature can be planned with SERO. The editing experience supports the team without handing them the technical upkeep.

Does headless automatically mean better SEO?

No. Google does not award a ranking bonus for Astro, Payload or a headless CMS. The advantage is the control that the architecture gives us over implementation.

The relationship is indirect, but real: architecture affects the generated output; that output affects performance, crawlability and page experience. Combined with consistent technical signals, those improvements create a stronger SEO foundation.

Our development and QA process makes that control systematic:

• Page structure: semantic HTML, a clear heading hierarchy and content available in the initial response.
• Search signals: title tags, meta descriptions, canonical URLs and schema built from structured content.
• Discovery and continuity: internal links, XML sitemaps, robots directives and a checked redirect plan when URLs change.
• Delivery: deliberate image handling, responsive rendering and checks on the assets each page loads.

These become repeatable standards across the website, rather than individual repairs after pages have been assembled. Structured service and area content also helps connect useful information, with editorial review ensuring each page serves a genuine purpose.

Performance matters here. A page that takes four or five seconds to become useful creates a different experience from one that responds quickly. Google confirms that Core Web Vitals are used by its ranking systems. Good scores do not guarantee rankings, and relevance remains critical; other aspects of page experience can improve usability without being direct ranking factors.

Our SEO work connects these foundations to useful content and the searches a business needs to reach. For the wider picture, see why a website may not be ranking. Better architecture gives us stronger conditions for that work.

A different maintenance model.

We have changed where maintenance happens. SERO still maintains the CMS, dependencies, deployments, forms, integrations and hosting security. Ordinary public pages can be served without running the CMS to construct them, reducing the CMS runtime exposed through that frontend while keeping editing separate.

That separation gives us clearer responsibilities for maintaining content and delivering the site. Access controls, backups and security checks remain part of the work.

We use AI-assisted tools where appropriate for implementation, structured operations and QA. Strategy, architecture, design decisions and final review remain human responsibilities.

Is headless right for every website?

This model fits many service businesses and content-led websites particularly well. Complex commerce, memberships, real-time applications, highly personalised systems or some editing workflows may justify a commerce-specific platform, server rendering, a hybrid setup or a traditional architecture. We choose around the project’s requirements.

WordPress can produce excellent websites, and we have built good ones. Depending on implementation, traditional installations can also accumulate plugins, builders, runtime complexity and technical debt. A poorly built headless site can be bad too. We moved because this model gives us greater control over the websites we want to produce.

What this changes for SERO clients.

Clients retain an appropriate content-management experience. Their customers get a purpose-built public website. SERO gets stronger control over the quality of what is deployed. That is the model.

We changed because we wanted stronger performance, better technical foundations, structured content and a cleaner way to maintain suitable websites. The early results have reinforced the decision. For clients, the practical value is a site that can be fast, clear, reliable and easier to grow without accumulating unnecessary frontend complexity.

Most businesses do not need to know which framework their website uses. They do notice how quickly it loads, how clearly it works and how confidently their team can keep it current. Those are the priorities behind our website design and development approach. The technology matters because it gives us greater control over the quality of the result.