Impress Solutions
A twenty-nine-year-old Sage and IT consultancy running a WordPress site that took fifteen seconds to show its main image on a phone. Rebuilt in Astro with a proper editing workflow, at a seventh of the page weight.
Visit the siteThe same page, before and after
Measured before and after
- Mobile performance
- 5595
- Largest Contentful Paint
- 15.1s2.9s
- Page weight
- 2,930 KB424 KB
- Network requests
- 11820
- JavaScript shipped
- 819 KB1 KB
- Accessibility
- 7698
How this was measured. Google Lighthouse 12, mobile preset with default throttling, three runs per site, taken on 20 August 2026. Figures are from the home page of each. The old site's scores varied run to run; the kindest numbers it produced are the ones shown.
What they had
Impress Solutions have been doing Sage, fintech and IT work for nearly three decades. They are a certified Sage Business Partner selling Sage X3 and Sage 200 into mid-market manufacturers and financial firms. Serious business, serious clients.
The website was a WordPress build on the Flatsome theme, running on PHP behind Microsoft IIS, with a child theme layered on top. It looked reasonable. It measured badly.
The home page pulled 118 requests and just under 3 MB on a phone. Of that, 819 KB was JavaScript across 27 separate scripts — the Flatsome theme bundle, a megamenu plugin dragging in the whole Font Awesome 4.7 icon font, jQuery, a cookie consent platform, and Google reCAPTCHA. reCAPTCHA loaded twice, 313 KB each time, on a page with no visible form on it.
The images were worse than the code. A single decorative PNG in the hero came in at 619 KB, another at 436 KB, neither resized for the slot it sat in. Images alone accounted for 1.7 MB.
The consequence was a Largest Contentful Paint of fifteen seconds on a mid-range phone, and nothing usable on screen until seventeen. That is not a slow website. That is a visitor who has already left.
What we did
A Publish-tier rebuild: a static Astro site, with the content in a separate repository and an admin area the team edits directly.
The split matters more than it sounds. The site code is private and the editors never touch it — they work in a browser-based editor that commits to a content repository, and the site rebuilds from that. Forty-one pages of products, case studies, blog posts and legal copy came across, organised so the folder structure generates the navigation rather than someone maintaining a menu by hand. Every incoming change runs through a validation step before it can reach a build.
There is no database, no plugin stack, no login on the public site and nothing to patch. The site is a folder of files.
Roughly two kilobytes of JavaScript are inlined into each page for the menu and a handful of interactions. That is the whole client-side budget, and it is what replaced 819 KB.
The cookie banner went too. Nothing on the new site sets a tracking cookie, so there is nothing to ask permission for — a banner is a symptom of what a site loads, not a legal inevitability.
What changed
The home page went from 2,930 KB to 424 KB and from 118 requests to 20. Largest Contentful Paint fell from 15.1 seconds to 2.9. Total blocking time went to zero, and layout shift to zero — the page no longer jumps around while it loads.
Accessibility went from 76 to 98 in the same test, which was not the point of the project but is what tends to happen when you build the markup yourself instead of inheriting it from a commercial theme.
The numbers above are the honest ones. The old site scored between 55 and 57 across repeated runs, with LCP ranging from 15 to 19 seconds; we have quoted its best result rather than its worst. The new site scored 95 to 97.