Core Web Vitals and caching after an AI website to WordPress migration

Why performance changes after a migration

AI website builders usually deliver a single-page application: a small HTML shell followed by a large JavaScript bundle that renders the content in the browser. WordPress renders HTML on the server. This changes the performance profile completely. The first byte now depends on PHP and database speed, while the time until content appears often improves because the browser no longer waits for JavaScript to build the page.

Understanding this shift lets you optimise the right layer. On a converted WordPress site the biggest gains come from server response time, caching, images and keeping unnecessary scripts away.

Time to First Byte and hosting

Choose hosting with modern PHP, sufficient memory, SSD or NVMe storage and a data centre close to your audience. Enable full-page caching at the server level, for example with Nginx FastCGI cache, LiteSpeed cache or the host's built-in cache. A cached page is served as static HTML in milliseconds, and TTFB values under 200 ms become realistic.

Add a persistent object cache such as Redis for logged-in users and dynamic pages. It reduces repeated database queries and keeps the admin dashboard responsive as content grows.

Largest Contentful Paint

The largest element on most pages is a hero image or a large heading. Serve hero images in WebP or AVIF, at the correct dimensions, and preload the main one. Never lazy-load the image above the fold. Self-host fonts and use font-display swap so text renders immediately. With server-rendered HTML and an optimised hero image, LCP under 2.5 seconds is achievable on mobile.

Cumulative Layout Shift

Layout shifts happen when images lack dimensions, fonts swap with different metrics, or banners are injected above content. WordPress adds width and height attributes to images automatically; keep them. Reserve space for embeds and cookie banners, and avoid inserting elements above existing content after load.

Interaction to Next Paint

INP measures how quickly the page responds to clicks and taps. Converted sites usually ship far less JavaScript than the original application, which helps. Keep it that way: limit sliders, avoid page builders that load heavy scripts on every page, defer analytics and load chat widgets only after interaction.

CDN, compression and HTTP

A content delivery network serves static files and cached pages from locations near your visitors. Enable HTTP/2 or HTTP/3, Brotli compression and long cache lifetimes for versioned assets. Most quality hosts and CDNs configure this with a single switch.

Plugins: fewer and better

Every plugin can add queries, scripts and styles. Audit plugins after the migration and remove what is unused. Prefer plugins that load assets only on pages where they are needed. One caching plugin, one SEO plugin, one form plugin and one security solution are a strong baseline.

Measuring correctly

Use field data from the Core Web Vitals report in Search Console and lab data from Lighthouse or PageSpeed Insights. Field data reflects real users over 28 days, so improvements appear gradually. Test the most important templates: home page, service pages, articles and contact page.

Expert conclusion

A WordPress site created with Convert2WP starts with a strong performance advantage: server-rendered HTML and compact CSS. Good hosting, page caching, optimised images and restraint with scripts turn that advantage into excellent Core Web Vitals. Small issues after conversion are normal and are typically solved with a caching or image plugin setting.