We tell clients that a slow website costs them enquiries, so in November 2026 we measured our own. The results were mixed: good on phones in places, poor on desktop in others, and in one case slowed down by a decorative effect we were proud of. This is what we found, what we changed and what still needs work. Every number here is a lab measurement, and we explain below why that matters.
How we measured
We ran Lighthouse 12.8 against a production build of the site, three runs per page and device type, and took the median. The mobile runs emulate a mid-range phone on a slow 4G connection with a slowed-down processor. We also ran Google's PageSpeed Insights against the live homepage.
Lab tests are repeatable, which makes them good for before-and-after comparisons, but they are not what real visitors experience. Real-user data comes from the Chrome UX Report, and our site did not yet have enough traffic for it to report any. So we don't claim to pass Core Web Vitals; we can only say the lab numbers moved.
A 3D background that blocked the page for over a second
PageSpeed Insights gave our live homepage a desktop score of 65, with 1,220 ms of total blocking time, 9.1 seconds of main-thread work and 20 long tasks. The cause was a decorative three.js background. On a machine without a graphics processor, as in Google's test environment, Chrome draws WebGL on the CPU, and our scene was rendering at the full refresh rate.
We changed four things:
- Decorative 3D now starts only after the page has loaded and the browser is idle
- The animation is capped at 30 frames a second and stops completely when the tab is hidden
- Software renderers without a GPU are treated as having no WebGL, so they get the static CSS background instead
- Phones, and visitors who prefer reduced motion, never load it
Images that skipped optimisation
A cache-busting query string on our project images stopped the Next.js image optimiser from processing them, so 1,024-pixel JPEGs of about 230 KB each went to every screen size. Our Work page alone moved 826 KB of images on mobile. Once the images went through the optimiser, zeevan.jpg, for example, dropped from a 223 KB JPEG to a 48 KB AVIF at 640 pixels wide. The Work page's mobile image weight fell from 826 KB to 201 KB, and its lab LCP from 5.71 s to 3.79 s.
A map that loaded before anyone saw it
The Google Maps embed on our contact page pulled in about 460 KB of third-party script as soon as the page opened, even though the map sits near the bottom. It now loads only when it scrolls within 200 pixels of view, with a styled placeholder until then. The contact page's total mobile transfer fell from 1,012 KB to 487 KB.
A validation library on every page
Our contact form used zod for validation, about 73 KB gzipped, and that code was prefetched from every page. We replaced it with a small hand-written validator with the same rules and messages; the server still validates every submission. The contact page's initial JavaScript fell from 333 KB to 270 KB gzipped, and the rest of the site stopped downloading the form code.
Headings that waited for JavaScript
Page headings were hidden until JavaScript ran, and the whole page rendered a second time after it loaded. Now headings paint with the HTML. On desktop, the moment the largest element actually appeared moved from about 1.2–2.6 s to about 0.1–0.2 s after navigation; on the contact page, from 2,582 ms to 97 ms.
What is still not good enough
- On mobile, lab LCP was still 3.4–4.1 s on most pages. Google's threshold for a good LCP is 2.5 seconds or less, so those pages sat in the "needs improvement" range.
- Every page still downloaded about 260–290 KB of shared JavaScript, including an animation library.
- A second font file of 84 KB downloaded on pages that show the rupee sign, because ₹ falls outside the basic Latin character set.
- We have no real-user data yet. Until the Chrome UX Report covers the site, we can't say how it performs for visitors.
A checklist you can use on your own site
- Measure first, over several runs, and keep the numbers
- Check the image weight of each page, and whether images are resized for phones
- List every third-party embed, and load each one only when it is needed
- Find large libraries that are sent to pages that don't use them
- Make sure the main heading and first paragraph show without JavaScript
- Give decorative effects the lowest priority: after load, and never on weak devices
What to do next
For the search side of the same work, read technical SEO that moves the needle. If your site feels slow, send us the address and we will tell you what we would check first, or see our cloud, DevOps and design services.