# AI-built sites: the Core Web Vitals regressions that show up after the padlock

The padlock in the address bar means the custom domain is live on HTTPS, but it does not mean Core Web Vitals stay healthy after the next edit. The certificate proves encryption. It says nothing about Largest Contentful Paint on the booking page next Tuesday.

AI-built sites often look fine on launch day: one homepage laboratory pass, images compressed, obvious red audits cleared. Then someone swaps the hero, pastes a booking widget, turns on a cookie banner, or asks the builder for a “fresh look.” Those are normal post-go-live moves, and they are also the usual path from a green afternoon score to an AI website that feels slow after launch.

What follows names the Core Web Vitals regressions we see after the padlock, why laboratory scores move, and how to catch the next change before a client forwards a complaint. For metric thresholds, keep [LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It](https://apogeewatcher.com/blog/lcp-inp-cls-what-each-core-web-vital-means-and-how-to-fix-it?utm_source=hashnode&utm_medium=referral&utm_campaign=ai-built-sites-cwv-regressions-after-padlock) open. For why one PageSpeed Insights run in Slack is not a portfolio schedule, see [PageSpeed Insights vs Automated Monitoring](https://apogeewatcher.com/blog/pagespeed-insights-vs-automated-monitoring-when-manual-checks-arent-enough?utm_source=hashnode&utm_medium=referral&utm_campaign=ai-built-sites-cwv-regressions-after-padlock).

## Why Core Web Vitals regress after go-live on AI-built sites

Launch checks answer a narrow question: is this build good enough to connect the domain? They rarely answer the after-launch question: will the same URLs still meet good thresholds after content and third parties change? Agencies that stop at the padlock usually learn the answer from a client screenshot, not from their own dated run.

AI builders make those changes cheap. A one-sentence prompt can replace the Largest Contentful Paint candidate, inject a chat script on every template, or regenerate layout that was stable last week. The builder did not fail, but the team stopped measuring after the padlock.

Website performance after go-live also depends on the live host, not the preview CDN. Once DNS points at production, image origins, caching headers, and third-party domains often differ from the builder preview. Public URLs after cutover are the fair baseline. The preview score is not.

## Hero and image swaps that break Largest Contentful Paint

The most common post-launch Largest Contentful Paint regression on AI-built sites is a marketing edit, not a platform outage. Someone uploads a heavier hero, removes `fetchpriority` or preload hints the builder had set, or lazy-loads the above-the-fold image because a checklist said “lazy load everything.” That edit can go live without a deploy ticket, so nobody thinks to re-run PageSpeed Insights.

When the homepage suddenly feels slower, the useful artefacts are the previous hero dimensions and file weight, then a fresh mobile laboratory Largest Contentful Paint on the same URL. If the new image is the Largest Contentful Paint element, that asset is the first place to look. Unrelated script audits rarely explain the jump.

## Booking, chat, and WhatsApp widgets that hurt Interaction to Next Paint

Conversion pages are where AI-built sites usually get slow after launch. Home stays tidy while the quote, booking, or contact URL loads calendars, maps, WhatsApp buttons, and chat bubbles. Those scripts compete for the main thread, so Interaction to Next Paint (or Total Blocking Time in older laboratory reports) is the metric that moves first.

Each new widget belongs on a laboratory pass for the conversion URL, not only for home. If the agent never saw the booking iframe when it “fixed Core Web Vitals,” it cannot be blamed for a widget added two weeks later. Non-critical scripts often work better deferred, and chat that waits for first interaction hurts Interaction to Next Paint less when the product allows it. One dated mobile run on the conversion URL in the client note is enough evidence for the next comparison.

## Cookie banners and late embeds that raise Cumulative Layout Shift

Cookie consent, newsletter bars, and embeds that inject after first paint are common Cumulative Layout Shift sources. AI builders often ship a minimal banner on day one, then the legal or marketing team enables a heavier consent manager later. Layout that looked stable in the launch laboratory run starts shifting under real Chrome visits once field samples exist.

A useful reproduction is mobile, with the banner accepted and dismissed. Templates that reserve space for the banner, or load it without pushing the Largest Contentful Paint candidate, keep Cumulative Layout Shift lower. Late YouTube or map embeds need the same treatment: sized containers before the iframe paints.

## Full redesign prompts that erase last week’s laboratory baseline

“Make it look more premium” is a legitimate client request. On an AI-built site it can rewrite templates, fonts, and image treatment in one pass, and the previous green laboratory screenshot becomes irrelevant because the DOM is no longer the same site.

Before a redesign prompt, the URL list, device strategy, and scores you will compare against are the baseline worth saving. After the redesign, that same list is the honest re-test. If nobody recorded the baseline, the account lead has no way to say whether Core Web Vitals got better or worse. That process gap looks like “the AI website got slow after launch” even when only the new design is slow.

## How to catch the next regression before the client forwards a complaint

A practical loop for AI-built properties looks like this:

1. Keep a short URL list: home plus the conversion URL (booking, shop, or quote).
2. Record laboratory tool, strategy (mobile or desktop), and date for every “we are fine” claim.
3. Re-run the list after every material edit: hero, widget, banner, redesign, or tag manager change.
4. When PageSpeed Insights shows field data, read URL-level and origin-level rows separately. Do not claim Search Console health from a laboratory screenshot alone.
5. Put the next check on a calendar. Weekly is enough for most small sites; agencies running many AI-built clients need a portfolio schedule.

That loop is monitoring, not another launch prompt. Spot checks remain useful for debugging a single change, but they do not scale when five clients each ship Christmas banners the same week. Automated coverage exists so regressions show up before the complaint email.

## FAQ

**Does the padlock mean Core Web Vitals are fine?**\
No. HTTPS proves the connection is encrypted. Core Web Vitals still need laboratory checks on the live host, and field data when Chrome samples exist.

**Why is my AI website slow after launch when the builder said it was green?**\
Usually a post-launch edit or a host difference, not a lying launch report. Public URLs after cutover are the fair comparison, then the same URL before and after the hero, widget, or redesign change.

**Which pages should I re-test after go-live?**\
At minimum home and the conversion URL. Blog templates and category pages matter when those URLs carry ads, embeds, or shared scripts.

**Can we still use AI website builders?**\
Yes. Keep them for speed of build. Keep a dated laboratory schedule (and field data when available) for the weeks after the padlock. Launch and retain are different jobs.

## Keep the padlock. Watch the next edit.

An honest launch checklist is still the right gate for connecting the domain. After that, every hero swap, widget paste, cookie banner, and redesign prompt is a new Core Web Vitals event on a short URL list. That is how you keep “green on Friday” from becoming “slow after launch” with no dated evidence in between.

If you want that schedule across many client domains without running PageSpeed Insights by hand each time, [try Apogee Watcher](https://apogeewatcher.com/sign-up) or run a [free domain check](https://apogeewatcher.com/check) for a multi-page laboratory baseline before the next edit ships.

## References

- [Lab data vs field data](https://web.dev/articles/lab-and-field-data-differences) (web.dev)
- [Optimize Largest Contentful Paint](https://web.dev/articles/optimize-lcp) (web.dev)
- [Optimize Interaction to Next Paint](https://web.dev/articles/optimize-inp) (web.dev)
- [Optimize Cumulative Layout Shift](https://web.dev/articles/optimize-cls) (web.dev)
- [LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It](https://apogeewatcher.com/blog/lcp-inp-cls-what-each-core-web-vital-means-and-how-to-fix-it) (Apogee Watcher)
- [PageSpeed Insights vs Automated Monitoring](https://apogeewatcher.com/blog/pagespeed-insights-vs-automated-monitoring-when-manual-checks-arent-enough) (Apogee Watcher)