How to Speed Up an AI-Built Website (Core Web Vitals)

AI builders can assemble a polished page with oversized images, several animation packages, and more client-side JavaScript than the interaction requires. The page may look fast in a warm desktop preview while feeling slow on a customer's phone. Performance work begins with the delivered experience, not the speed of the generation process.

Do not ask the assistant to “optimise everything”. Establish a baseline, identify the resource or task delaying the user, and change one cause at a time. That approach produces measurable improvements and avoids trading a visible problem for a less obvious loading or accessibility defect.

Measure the page users actually receive

Test the production build on representative routes, devices, and connection conditions. Builder previews may add tooling, use different caching, or serve assets differently from the live site. Include an entry page, a content-heavy page, and an important conversion journey rather than testing only the home page.

Understand the three Core Web Vitals: Largest Contentful Paint measures when the largest eligible visible content appears, Interaction to Next Paint reflects interaction responsiveness, and Cumulative Layout Shift tracks unexpected visual movement. The web.dev Web Vitals guidance explains their definitions and current assessment criteria.

Aim for good field results at the 75th percentile: LCP within 2.5 seconds, INP within 200 milliseconds, and CLS no higher than 0.1. These thresholds describe user experience distributions, not a guarantee provided by one successful lab run. A low-traffic site may not have enough public field data to support a reliable assessment.

Use lab tools to diagnose causes and real-user measurement to understand actual visitors. The PageSpeed Insights documentation explains the distinction between lab and field data. Save the tested URL, revision, device profile, and repeated results so later comparisons are meaningful rather than anecdotal.

Fix the image that delays the first view

Identify the LCP element in a trace before changing image settings. It may be the hero image, a large heading, or another content block. For an image, inspect discovery time, transfer size, dimensions, and rendering delay. A small file discovered late can be slower than a larger file requested immediately.

Deliver responsive image candidates and appropriate sizes. Give images intrinsic dimensions or a stable aspect ratio to reserve space. Compress source assets and compare visual quality at the size users actually see. Do not ship a huge desktop export to a narrow phone simply because the CSS scales it down.

Avoid lazy-loading an above-the-fold hero that is the likely LCP candidate. Reserve lazy loading for suitable off-screen content. A simplified pattern is:

<img
src="/images/workspace-960.webp"
srcset="/images/workspace-480.webp 480w, /images/workspace-960.webp 960w"
sizes="(max-width: 600px) 100vw, 960px"
width="960"
height="640"
fetchpriority="high"
alt="Shared workspace with desks beside a window"
>

Treat fetch priority as a targeted hint, not a setting for every image. Follow the web.dev LCP optimisation guide to distinguish resource discovery problems from slow servers or render-blocking work. Ask the builder to preserve meaningful alternative text while replacing or resizing assets.

Reduce JavaScript before adding clever scheduling

Inspect the generated bundle and the network requests for each route. Look for duplicate libraries, large icon imports, unused charting packages, and components loaded globally for one page. AI-generated projects can accumulate dependencies from abandoned experiments even when the final interface no longer uses them.

Prefer less shipped code to elaborate workarounds for unnecessary code. Remove a decorative effect before adding another dependency to schedule it. Replace an entire library with a small native interaction where the requirement genuinely permits it, but do not rewrite complicated behaviour without tests simply to reduce bundle size.

Use route-level splitting and defer expensive features until needed. A reporting chart does not need to block a visitor reading the public pricing page. Check the network waterfall after a change: splitting code into many dependent requests can create its own delays if the critical path remains long.

For responsiveness, inspect long tasks and event handlers, not just transfer size. A small script can block the main thread with expensive work. Ask the assistant to identify the computation triggered by a slow interaction and propose a bounded change. Browse the AI coding assistants directory for tools that fit your repository review workflow rather than expecting automatic performance claims to substitute for evidence.

Stabilise layout and loading states

Reserve space for images, embeds, promotional banners, and asynchronously loaded components. Unexpected movement often comes from content inserted above something the user is reading or trying to click. Use layout stability as an acceptance criterion, including after navigation and during interactions, not just during the first screenshot.

Review font loading. Too many families and weights increase requests and can cause text to reflow. Use a deliberate fallback stack and test realistic headings while the preferred font is unavailable. Do not hide all text for a long period merely to avoid a visible font transition.

Generated skeletons should approximate the dimensions of the final content. If a placeholder collapses when data arrives, the loading animation has not solved the layout problem. Test slow responses, missing images, and error messages. These conditions often expose shifts absent from a fast local demo.

Use the meta tag previewer to check title, description, and social preview metadata after changing the shared page template. This is a companion release check, not a Core Web Vitals measurement: metadata edits should not accidentally introduce heavy preview assets into the visible page or remove essential sharing information.

Give the builder a measurable performance task

Write a performance budget suited to the route and audience. Record the current critical resources, the target improvement, and the behaviours that must remain unchanged. Ask for evidence from a trace or bundle report, not a claim that the assistant has “made the site faster”.

A useful request names one problem: the mobile hero is discovered late because it appears only after client rendering. Ask the builder to make the image discoverable earlier, preserve the layout, and show before-and-after measurements under the same conditions. Review the diff for unrelated changes and confirm that tracking and navigation still work.

Apply the AI app debugging loop when an optimisation causes a regression. Revert speculative patches, reproduce the failure, and isolate the boundary. Performance repairs should not weaken authentication, remove essential validation, or make keyboard interaction unreliable.

Finally, verify field impact after deployment. Segment by route and device where possible, and allow for reporting windows rather than expecting historical field data to change immediately. Monitor performance alongside errors and conversion behaviour. A faster page that no longer lets customers complete the task is not an improvement.

Key takeaways

• Measure production routes using both diagnostic lab runs and field evidence.
• Find the actual LCP element before changing image loading behaviour.
• Remove unnecessary JavaScript and investigate slow interaction handlers.
• Reserve layout space and test fonts, errors, and delayed content.
• Ship bounded changes and verify performance without breaking the journey.