On 2 October 2026, skyboosttraffic.com had a mobile Largest Contentful Paint of 11.0 seconds. By 3 October, it was 1.7 seconds. This is our own site — not a client's — built on Lovable, an AI-assisted development platform, and the mistakes we fixed are the kind of defaults that ship on almost every AI-built site we have looked at.
Before — 2 October 2026, PageSpeed Insights, mobile:
| Metric | Value |
|---|---|
| Largest Contentful Paint | 11.0 s |
| First Contentful Paint | 7.0 s |
| Speed Index | 7.0 s |
| Total Blocking Time | 400 ms |
| Cumulative Layout Shift | 0 |
| Best Practices score | 77 |
| Unused JavaScript | 651 KiB |
| Unused CSS | 110 KiB |
| Main-thread work | 3.8 s |
| Maximum critical path latency | 1,277 ms |
After — 3 October 2026, same tool, same device profile:
| Metric | Mobile | Desktop |
|---|---|---|
| Performance score | 97–99 | 100 |
| Largest Contentful Paint | 1.7 s | 0.5 s |
| First Contentful Paint | 1.5 s | 0.4 s |
| Total Blocking Time | 30 ms | 20 ms |
| Cumulative Layout Shift | 0 | 0 |
| Accessibility | 100 | 100 |
| Best Practices | 100 | 100 |
| SEO | 100 | 100 |
Five fixes. One day. No framework change, no redesign, no new hosting.
Lovable — and tools like it, Bolt, v0, Replit — solve a real problem. They let people who cannot write production code ship real, working websites quickly. We use Lovable and we will keep using it. That is not the issue.
The issue is that speed optimisation requires decisions that happen at a granular level: which resources load on page load and which load on demand, what the browser prioritises, what a CDN caches and when. An AI builder optimising for "ship a working, good-looking site" is not simultaneously optimising for "minimise critical-path latency under Lighthouse's slow-4G simulation."
Those are different goals. The defaults that serve one do not always serve the other. None of what follows is a complaint about Lovable. It is a description of the gap between "shipped and working" and "shipped and fast" — and how to close it.
The homepage carries a founder video embedded via a standard YouTube iframe with no loading attribute, no facade, no deferral. This meant the full YouTube player — roughly a megabyte of third-party JavaScript — downloaded on every single page load, whether or not the visitor ever touched the video. Along with it came 4 third-party cookies from YouTube, and a significant share of the 3.8-second main-thread work PageSpeed was reporting.
We replaced the iframe with a click-to-load facade: a static thumbnail from i.ytimg.com, an accessible play button overlaid on top, and on click only the thumbnail is replaced with a real iframe pointed at youtube-nocookie.com with autoplay=1. Built as a local component. No npm package added.
PageSpeed flagged a critical path latency of 1,277 ms coming from beacon.min.js chaining to /cdn-cgi/rum. We had not installed this. It was being injected at the edge by Cloudflare Web Analytics — enabled by default on new zones — running silently on top of the GA4 instance we were already running.
Disabled RUM at account level in Cloudflare. Kept Speed Brain — it functions without the beacon and the only loss is visibility into its effect inside Cloudflare's own dashboard.
PageSpeed identified the navigation logo as the LCP element. The logo file was 512×512 pixels and 30.4 KB, displayed at 36 CSS pixels on mobile — roughly 200 times the data needed. It also carried loading="lazy", which tells the browser to defer loading this image until the user scrolls near it. On the LCP element, lazy loading is the opposite of what you want.
A 72×72 copy of the logo at 1.3 KB with loading="eager", fetchpriority="high", decoding="async". Because the file is now 1.3 KB, it falls under Vite's 4 KB inline threshold and is embedded as a data URI directly in the HTML — zero network request. The footer copy keeps loading="lazy" and the original file, because deferring it below the fold is correct.
Once the logo was inlined as a data URI, we noticed a preload hint in the document head pointing at the same data URI. Preloading a data URI does nothing — the bytes are already embedded in the HTML. The tag duplicated roughly 1.7 KB of base64 into the document a second time with no benefit. Fix: deleted the tag. The lesson: check whether each preload, each attribute is doing what you think it is doing in the current state of the page — not the state it was in when you added it.
After the first few fixes, measurements stopped moving. We deployed changes, confirmed the build succeeded, ran PageSpeed again — and saw the same numbers. For several hours, the metrics were stuck. Cloudflare was serving a cached copy of the document at the edge. The fresh HTML existed — it just was not what PageSpeed was fetching.
Fix: Purge Everything in Cloudflare under Caching → Configuration → Purge Everything, then re-run PageSpeed.
If you are iterating on a site behind a CDN and your numbers are not moving after confirmed deploys, test this before assuming the fix did not work. This is the mistake that costs the most time. It cost us several hours.
After all five fixes, we ran three consecutive PageSpeed tests on identical code. The scores returned: 80, then 97. Nothing changed. The code was the same. The result was not.
Lighthouse mobile scores are lab data generated on a simulated throttled device. Variance of ±10 to 15 points between consecutive runs is normal. The practical rule: run PageSpeed at least three times before drawing a conclusion. Judge by the metric values — LCP, TBT, CLS — not the composite score. A site with LCP 1.7 s, TBT 30 ms and CLS 0 is fast regardless of whether the composite shows 80 or 99.
Core Web Vitals is a real Google ranking signal. It is also a weak one. Moving LCP from 11 seconds to 1.7 seconds will not, on its own, move you up the results page. Content, authority, and technical indexability matter more.
Where it does matter: mobile abandonment — a page that takes 11 seconds to render loses visitors before they see anything; professional credibility — a prospect who runs your URL through PageSpeed before hiring you and sees 11-second load times has a question about your competence; and AI-search citations — our Agentic Browsing score went from 2/3 to 3/3.
Read more for trades businesses considering SEO investment, or for CBD brands, where the priority is technical indexability.
Are they loading the full player on page load? If yes, implement a click-to-load facade.
Is RUM enabled without your knowledge? Check Cloudflare → Analytics & Logs → Web Analytics.
Run PageSpeed and read which element is the LCP. Is it served at the right file size? Does it have loading="eager" and fetchpriority="high"?
Do any preload tags point at data URIs or files that no longer exist?
Before concluding a fix did not work, purge the CDN cache and re-test.
Judge by metric values, not the composite score.
Core Web Vitals is a confirmed but weak ranking signal. Improving LCP, TBT and CLS removes a potential negative factor but does not replace content quality, backlink authority or proper indexability. Fix speed issues alongside your broader SEO work, not instead of it.
The same defaults appear across Lovable, Bolt, v0 and Replit — YouTube embeds without facades, CDN-injected analytics, oversized LCP images marked lazy. These are not platform-specific bugs; they are the natural result of prioritising build speed without a performance pass. The fixes apply regardless of which AI tool built the site.
In our case, the five fixes took one day — including several hours lost to a CDN cache problem. With that lesson in hand, a systematic performance pass on a similar AI-built site should take four to six focused hours. Purging the CDN cache after each deploy is the most valuable shortcut.
Agentic Browsing is a PageSpeed Insights metric assessing how well a page is structured for AI agents — semantic markup, accessibility, crawlability. We went from 2/3 to 3/3, driven by the accessibility and Best Practices improvements. It is a growing signal as AI tools become meaningful sources of discovery traffic.
We use Lovable and will continue to. AI builders ship good-looking, functional sites quickly at a fraction of traditional development cost. Performance defaults are not optimised out of the box. A dedicated performance pass after the build — the five checks listed above — closes most of that gap in a few focused hours.
Page speed is one technical signal among many. If your site has indexability problems, a weak backlink profile, or pages that do not match what your customers search for, fixing LCP will not change your rankings. We offer a free 15-minute review of your site's current visibility — what is blocking you from ranking, and what we would address first. No pitch, no commitment required.