⚡ Summary
Our site took 9.3 seconds to load on mobile — Google PageSpeed showed just 50 out of 100. We assumed it was our own code. The real cause turned out to be something else entirely — here's what we found and what we did.
Website speed is the kind of thing people notice too late: a visitor opens the page, waits a few seconds, and closes the tab. If you've ever typed "what is slowing down my website" into Google at 2am, this post is for you — that's roughly how we felt about our own site.
What the first website speed test showed
A website speed test through Google PageSpeed Insights came back with a mobile score of 50 out of 100. The main problem was LCP (Largest Contentful Paint) — the moment when the largest visible element on the screen finally shows up for a real visitor. It's one of three Core Web Vitals Google uses to measure how fast a page actually feels. Ours was 9.3 seconds; Google considers anything under 2.5 seconds good.
How to read a PageSpeed report
A PageSpeed Insights report has two parts, and they're easy to mix up. At the top you'll see data from real visitors over the last 28 days, if the site gets enough traffic. Below that is a lab test: Google loads the page once on a simulated slow phone and gives it a score from 0 to 100.
The score is handy for comparing before and after, but the metrics underneath matter more. Core Web Vitals are currently three measurements:
- LCP. When the largest element on the first screen appears. A good result is under 2.5 seconds.
- INP. How quickly the page responds to taps and clicks. A good result is under 200 milliseconds. It replaced the older FID metric in 2024.
- CLS. How much the page jumps around while it loads. A good result is under 0.1.
Mobile and desktop are tested separately. Start with mobile: it almost always comes out worse.
We were looking in the wrong place
For two days we optimized our own code — compressed images, cleaned up CSS, moved scripts to the bottom of the page. Locally, LCP dropped under a second. On production, it stayed at 9.3.
The answer was buried in the detailed report: 1,253 of 2,880 kilobytes on the page, and over 5 seconds of processing time, came from a script called recaptcha__en.js — a reCAPTCHA widget inserted by Netlify itself (the hosting platform our site runs on), without async or defer, with zero lines of it in our own repository.
Why everything looked fast locally
Netlify adds that script on its own when it sees a special attribute, data-netlify-recaptcha, on a form. So the script only shows up on the live site. On the developer's computer the page opened without it, local measurements came in under a second, and we honestly believed the problem was solved.
The diagnostics at the bottom of the report helped. They list each script with its size and processing time. If the heaviest one isn't in your own files, something else is adding it to the page: the hosting, a plugin, a tag manager or someone else's widget.
Not sure why your own site is slow?
We'll run a technical audit and give you the honest picture — no guessing.
LCP optimization, the parts that actually mattered
The fix was our own reCAPTCHA widget with our own keys instead of the hosting's built-in one — server-side verification stays exactly the same. In parallel we moved fonts to self-hosting (they used to load from Google Fonts, which cost almost 3 more seconds on a cold cache) and removed a font that was linked in the code but never once used in the CSS.
How the captcha loads now
Our own keys were half the fix. The other half was timing: reCAPTCHA no longer loads together with the page. It's fetched when a visitor scrolls close to the form, or right away if they touch a field. If the form is already visible on the first screen, the script waits until the browser has finished drawing the page.
Two small things went wrong along the way. Reserving only the widget's height wasn't enough: it has a fixed width of 304 pixels, so the page still jumped by 25 pixels until we reserved the full box. And while the widget loaded only after a tap, people saw an empty rectangle and decided the captcha was broken. Now it appears a little before the visitor reaches the form.
The result
Mobile PageSpeed went from 50 to 74, LCP dropped from 9.3 seconds to roughly one. Total Blocking Time fell from 630 to 70 milliseconds, and page weight from 2,880 to 1,307 kilobytes. Running a website speed test now takes a few seconds, and we check it regularly so the number doesn't quietly creep back up. It's not just a report number: speed is one of the factors in SEO promotion, and Google ranks a slow site lower.
Why 74 and not 100
One more number moved noticeably. Speed Index, which shows how fast the page fills with content, went from 9.0 to 3.1 seconds. Still, the score didn't reach the green zone, and this time the cause is ours. The main thing holding it back is our own intro screen on the homepage.
The intro shows once per session, so returning visitors see a fast site. Google's test arrives as a new guest every time and always sees it. We decided to keep the intro for now and revisit it when traffic grows. Later we found one more cause: the heading and image on the first screen fade in, and until the animation ends, Google treats them as not shown. We know the fix and have planned it for later. So for now we accept 74 knowingly.
How to check your site's speed yourself
A basic check takes a few minutes, and you don't need a developer for it:
- Open PageSpeed Insights (pagespeed.web.dev), paste your homepage address and switch to the Mobile tab.
- If there's real-visitor data at the top, start there. The lab test helps you find the cause, while real data shows what people actually experience.
- Run the test two or three times. The first run is often worse because the server or network hasn't warmed up yet. For us, the first server response measurement came in at over 1.5 seconds, while a series of five gave about 0.1.
- Test the live site, not a copy on a developer's computer. Our case shows how different the two can be.
What to check in third-party scripts
A third-party script is code the page loads from someone else's server. You won't see it in your files, but your visitor waits for it all the same. Ask a few questions about each one:
- Is it needed on every page? A captcha only makes sense where there's a form. A chat only makes sense where a customer might really have a question.
- Does it load with
asyncordefer? Without them, the browser stops processing the page until the script has downloaded and run. - Who added it? The hosting, a plugin, a tag manager, or a contractor you stopped working with long ago. That tells you where to switch it off.
- What does it cost the page? The PageSpeed diagnostics show each script's size and processing time.
If you'd rather not dig into this yourself, a team that handles website support can keep an eye on it for you regularly.
What we took away from this
The real takeaway here: before diving into website performance optimization on your own code, check what's actually loading on the live site first — sometimes the most expensive script isn't even yours. We later ran the same kind of teardown on our own keyboard accessibility, and that one also turned up something the automated checks had missed. If your own site feels slow and you can't tell why, tell us — we'll run a technical audit and give you the honest picture.
The simplest way: message us on Telegram or get in touch.