Google's PageSpeed Insights gave zinetics.com a desktop score of 100 but a mobile performance score of 93, with accessibility at 95. Mobile Largest Contentful Paint (LCP) was 2.9 seconds and Speed Index 4.2 seconds. Not bad — but not where we wanted our own site to be. Here is exactly what we found and fixed, with the real numbers.
The starting point
| Performance | Accessibility | Best Practices | SEO | |
|---|---|---|---|---|
| Desktop (before) | 100 | 98 | 100 | 100 |
| Mobile (before) | 93 | 95 | 100 | 100 |
The site is built with Next.js 14 and React, deployed on Vercel.
Finding 1: the hero was invisible until JavaScript ran
The biggest problem was one many modern sites share. Our hero headline and introduction used a fade-in animation that started at opacity 0. Browsers do not count invisible elements as the "largest contentful paint", so Lighthouse ignored the hero until the animation ran — and for most pages the animation was controlled by JavaScript, which had to download and run first.
Lighthouse's breakdown made this obvious: 74% of LCP time was "render delay" — the content had arrived but was not being painted.
Fix: above-the-fold content now renders visible on the first paint, keeping a subtle slide-up (transform only, no opacity change). Below-the-fold sections still fade in as you scroll.
Finding 2: the real page was fast — the simulation was not
This was the most interesting lesson. In the raw trace, our first paint and largest paint both happened at 0.17 seconds. The 2.9-second figure came from Lighthouse's simulation of a slow mid-range phone on a throttled 4G connection. That simulation assumes the largest paint has to wait for every file requested before it — including all of the page's JavaScript.
So even though the page itself was quick, every kilobyte of JavaScript requested early made the mobile score worse. Reducing JavaScript became the priority.
Finding 3: an animation library on every page
We were loading a popular animation library on every page purely for scroll-in effects, a mobile menu, an FAQ accordion, a scroll progress bar and a back-to-top button. We replaced all of them with:
- CSS transitions for the menu, accordion, progress bar and back-to-top button;
- a tiny IntersectionObserver hook for scroll reveals, using CSS classes we already had;
- lazy loading for the chat assistant, so its code downloads only after the page is interactive.
The home page's first-load JavaScript dropped to 106 KB.
Finding 4: font priorities
The site uses three font families. The monospace font is only used for small labels, but it was being preloaded alongside the heading and body fonts, competing for bandwidth on a slow connection. We stopped preloading it.
Finding 5: small accessibility fixes
Accessibility went from 95 to 100 with three changes:
- Colour contrast — tiny green status text in the hero illustration was too light; we darkened it.
- Heading order — footer column titles skipped a heading level; we corrected them.
- Section headings — the blog and portfolio grids jumped from the page title straight to card titles, so we added screen-reader-only section headings.
What did not help
We tried inlining critical CSS to remove the render-blocking stylesheet. Next.js's App Router does not support that option, so nothing was inlined and the score did not change. We removed it rather than keep dead configuration. Not every well-known optimisation applies to every stack — measure, do not assume.
The results
| Performance | Accessibility | Best Practices | SEO | LCP | |
|---|---|---|---|---|---|
| Desktop (after) | 100 | 100 | 100 | 100 | 0.5 s |
| Mobile (after) | 99 | 100 | 100 | 100 | 2.0 s |
Mobile Speed Index fell from 4.2 s to 1.1 s. Across repeated runs, mobile performance landed between 95 and 100 — PageSpeed's mobile score naturally varies by a few points depending on network conditions at the moment of the test.
Checklist for your own site
- Find your LCP element in Lighthouse and look at the phase breakdown — render delay is a strong hint that something is hidden or waiting on JavaScript.
- Never start above-the-fold content at opacity 0.
- Audit your JavaScript. Animation, carousel and chat libraries are frequent culprits; CSS can do most of it.
- Lazy-load anything not needed for the first view — chat widgets, embeds, maps.
- Preload only the fonts needed for the first screen.
- Fix accessibility basics — contrast and heading order are quick wins.
- Test several times and compare trends, not single runs.
Speed matters for search rankings and conversions alike. If your site needs the same treatment, our web development team can audit and fix it. Get in touch.