Core Web Vitals for Joomla: a pre-launch checklist

Core Web Vitals are three numbers that describe how a page feels to a real visitor: how quickly the main content appears, how fast it responds to a tap, and how much the layout jumps while loading. They are part of Google’s page-experience guidance, and poor scores tend to show up alongside higher bounce rates and more support tickets.

Joomla sites tend to fail them for predictable reasons: a template demo loaded with sliders, icon fonts and unused modules; images uploaded at camera resolution; third-party scripts that arrive before the content. The good news is that most fixes are template-level and do not require rewriting the site.

This checklist is the pass to run before launch, and again after a major template or Joomla update.

1. Measure with field data, not one Lighthouse run

A single Lighthouse score is a lab result: one simulated visit, one device, one network. Core Web Vitals are defined on field data, measured from real visitors at the 75th percentile:

• Largest contentful paint (LCP): 2.5 seconds or less.
• Interaction to next paint (INP): 200 milliseconds or less.
• Cumulative layout shift (CLS): 0.1 or less.

Start with PageSpeed Insights, which shows both field data (from the Chrome UX Report, when available) and a lab run. Then cross-check the Core Web Vitals report in Google Search Console. If field data is missing, the site may not have enough traffic yet — use lab data as a proxy and re-check after launch.

2. Fix LCP before anything else

LCP is usually the hero image, a large heading, or a video poster. On Joomla sites the culprit is often a template slider that loads a huge image after JavaScript has run.

Work through the element itself:

• Serve the image at the size it is displayed, not the original upload.
• Use modern formats and srcset/sizes where the template supports them.
• Do not lazy-load the LCP image; set fetchpriority="high" on it.
• Remove render-blocking CSS and JavaScript that must finish before the image appears.
• Check server response time and caching; a slow origin delays everything.

If the LCP element is inside a slider or module, consider replacing it with a static image block. A rotating banner is rarely worth a one-second delay on mobile.

3. Reduce INP by finding the JavaScript you did not choose

INP measures the delay between a user interaction and the next visual update. It replaced First Input Delay as a Core Web Vital in 2024. The usual cause is main-thread work from scripts: sliders, page builders, chat widgets, analytics, social embeds and modules with their own libraries.

Audit what loads on the page:

• Disable modules and extensions on pages where they are not used.
• Defer or load third-party scripts after the interface is usable.
• Remove sliders, carousels and animation libraries that add no value.
• Check that event handlers are not recalculating layout on every scroll or resize.

The template demo is a good starting point for what to remove: it was built to show every feature, not to be fast.

4. Reserve space for everything that arrives late

CLS is caused by content that loads after the first paint and pushes everything else around: images without dimensions, web fonts that swap, cookie banners injected at the top, embeds, ads and late modules.

• Set width and height — or an aspect ratio — on every image and iframe.
• Reserve space for the cookie notice and any sticky header.
• Use font-display: swap and match fallback font metrics where possible.
• Avoid inserting banners or notices above existing content after load.

5. Treat images as the biggest template lever

Many Joomla templates ship with demo images that are far larger than they need to be. Replace them before launch.

• Resize and compress every image; serve WebP or AVIF where supported.
• Provide responsive variants for cards, galleries and hero images.
• Lazy-load images below the fold, but never the LCP image.
• Remove unused demo galleries and duplicate thumbnails from the media manager.
• Check that the template outputs srcset when the image field supports it.

6. Load fewer fonts, and load them properly

Fonts are a common hidden cost, especially when the template imports several weights and icon fonts.

• Keep two font families and the weights you actually use.
• Self-host fonts where possible; avoid a third-party request on the critical path.
• Preload the font used above the fold.
• Use font-display: swap so text is readable immediately.
• Remove icon fonts in favour of inline SVG where the template allows it.

7. Stop shipping the demo CSS and JavaScript

Templates often load assets for features that are not on the page: lightbox libraries, icon sets, animation frameworks, page-builder bundles. Each file adds bytes; JavaScript adds main-thread work.

• Check which CSS and JavaScript files load on a simple article page.
• Disable template features you do not use in the template settings.
• Avoid combining everything into one huge bundle; load what the page needs.
• Update the template to its latest version, which may already remove unused assets.

If you shortlist two or three templates, run this check on their demos — for example the Creative portfolio template and the Nexbrief news template — before committing to a design.

8. Use caching and hosting as cheap wins

Template fixes only go so far if every request hits PHP.

• Enable Joomla’s cache settings; conservative caching is a safe default for most sites.
• Use the System - Page Cache plugin where full-page caching is appropriate, and test logged-in and cart flows.
• Enable OPcache and a current PHP version; Joomla 6 requires PHP 8.3 or later.
• Turn on compression (Brotli or gzip) and HTTP/2 or HTTP/3 at the server or CDN.
• Serve static assets through a CDN if your audience is spread out.

9. Re-measure and keep watching field data

Performance work is a loop, not a one-off audit:

1. Fix the biggest metric first — usually LCP on mobile.
2. Re-run lab tests on the same page and device profile.
3. Check field data again after a few weeks of traffic.
4. Repeat after template updates, new extensions or a Joomla upgrade.

Automatic Joomla core updates are convenient, but they can change markup that template overrides depend on. Re-run the checks after any major update, as covered in the Joomla 6 upgrade guide.

A pre-launch Core Web Vitals checklist

Before launch, confirm:

1. Field data or a lab baseline exists for the main page types (home, article, category, contact).
2. The LCP image is correctly sized, in a modern format and not lazy-loaded.
3. No slider or module delays the main content on mobile.
4. Third-party scripts load after the interface is usable.
5. Images and iframes have explicit dimensions or aspect ratios.
6. The cookie notice and sticky header reserve space.
7. Fonts are limited, self-hosted where possible and use font-display: swap.
8. The template does not load demo assets for unused features.
9. Joomla caching and the page cache plugin are configured and tested.
10. Compression, HTTP/2/3 and OPcache are enabled.
11. PHP is 8.3 or later (Joomla 6 minimum).
12. The Core Web Vitals report in Search Console shows no regressions.

Core Web Vitals are not a score to chase for its own sake. They are a compact way to answer a simple question: does the site feel fast when someone actually uses it? Fix the template layer once, and every page you build afterwards starts from a better baseline.

If you are still choosing a design, run these checks on the demos first — the template previews include screenshots and links to the live demos, and our SEO checklist covers the metadata side of the same launch.