Core Web Vitals Challenge: WordPress vs Other CMS

Google started a new project called Core Web Vitals, which has the objective to measure and improve the user experience on the internet. After this initiative took off, HTTP Archive, published real-world statistics of which CMS (Content Management System), scored the best in Core Web Vitals rankings. While there was one clear victor, the performance was mixed between five of the contenders. HTTP Archive challenge matched WordPress versus Drupal, Joomla, Squarespace and Wix and so began the Core Web Vitals Challenge: WordPress vs Other CMS.

That comparison was published in the run-up to Google’s page experience update, and it is worth revisiting for two reasons. First, the pattern it exposed is still true: the platform you publish on sets a baseline, but it never decides your score on its own. Second, the metrics themselves have moved on. First Input Delay, one of the three vitals used in the original ranking, was retired in March 2024 and replaced by Interaction to Next Paint. Below you will find the original CMS comparison kept intact as a historical snapshot, followed by what the metrics look like now and what you can actually do about them.

Core Web Vitals

What are Core Web Vitals? As I stated in the first paragraph, Core Web Vitals is a project initiated by Google that focuses on measuring and ultimately improving the user experience on the internet. Google deliberately keeps the set small, and it does change over time. The three specific metrics that make the Core Web Vitals today are: 

1. Largest Contentful Paint (LCP) measures loading performance: how long it takes for the largest piece of content in the viewport, usually a hero image, a banner or a big block of text, to finish rendering. A good LCP is 2.5 seconds or less.
2. Interaction to Next Paint (INP) measures responsiveness: how long the page takes to paint a visible response after someone clicks, taps or presses a key. It looks at the worst interactions across the whole visit, not only the first one. A good INP is 200 milliseconds or less.
3. Cumulative Layout Shift (CLS) measures visual stability: how much the content jumps around while the page loads, for example when an image without declared dimensions pushes a paragraph down, or a late-loading banner shoves a button under the reader’s thumb. A good CLS is 0.1 or less.

First Input Delay (FID) used to hold the responsiveness slot. It only measured the delay before the browser began processing the very first interaction, which meant almost every site passed it while still feeling sluggish to use. INP is the stricter successor: it covers the full path from input to the next painted frame, and it considers every interaction on the page rather than one. The CMS rankings further down still use FID, because that is what was being measured at the time. Read them as a snapshot of a moment, not as today’s league table.

The thresholds you are measured against

Core Web Vitals are not scored on an average. Google takes the 75th percentile of real visits collected in the Chrome User Experience Report over a rolling 28-day window, which means roughly three out of four page views have to be good before a URL is considered to pass. Field data is grouped per URL where there is enough traffic and falls back to the whole origin where there is not. That is why a page can look immaculate in a single lab test and still be flagged in Search Console: the lab test is your laptop on your connection, and the assessment is thousands of real phones on real networks.

Metric	What it measures	Good	Needs improvement	Poor
LCP	Loading	2.5 s or less	2.5 s to 4.0 s	Over 4.0 s
INP	Responsiveness	200 ms or less	200 ms to 500 ms	Over 500 ms
CLS	Visual stability	0.1 or less	0.1 to 0.25	Over 0.25
FID (retired)	First input delay only	100 ms or less	100 ms to 300 ms	Over 300 ms

Desktop and Mobile performance

Desktop performance was superior over the mobile performance in the majority of the cases, and that is just a reflection of the device’s render capabilities and the internet network differences between devices. These said, mobile CWV (Core Web Vitals) scores are more important than the desktop CWV scores, and that’s because most website visitors access sites using mobile devices. Google confirmed this in practice: the page experience signals began rolling out for mobile search in June 2021 and were extended to desktop in February 2022. Mobile is still where the gap lives, so if you have time to fix one profile, fix that one first.

Explaining the scores

The scores are extracted from the number of visits of Google Chrome users, these scores are divided between desktop and mobile, and while the desktop scores are higher, the mobile ones are more important. The scores are expressing how many sites have achieved the “good” ranking in percentages. The LCP for example, 40% of websites achieved the “good” ranking.

• Largest Contentful Paint (LCP)

The top ranked CMS contender for Largest Contentful Paint, is Drupal and the lowest ranked is Wix. Drupal was the winner with 47% mobile score and that means that only 47% of the Drupal mobile websites had a good user experience. 

Here are the “Largest Contentful Paint” scores:

1.  Drupal : 47%
2. Joomla : 38%
3. WordPress : 25%
4. Squarespace : 12%
5. Wix : 9%

• First Input Delay (FID)

The scores for First Input Delay were very high, having as champion Squarespace with 91% of sites scoring “good”, followed by WordPress with 88% while Wix was still last. This is exactly the weakness that led Google to drop the metric: when almost everybody passes, the metric stops telling you anything. Under INP the same sites are separated far more clearly, because heavy JavaScript, bloated page builders and third-party tags all show up in it.

Here are the “ First Input Delay” scores:

1. Squarespace : 91%
2. WordPress : 88%
3. Drupal : 76%
4. Joomla: 71%
5. Wix : 46%

• Cumulative Layout Shift (CLS)

Cumulative Layout Shift, measure how much the elements of the page shift around when you load the page, elements like buttons, forms and links. Shifting elements are not good for the user experience, it’s hard to read text while it’s shifting around the page, and it’s even harder to click on links. The 1st place was taken again by Drupal with a 70% score and Wix managed to secure 3rd place beating WordPress by 2%.

Here you have the “Cumulative Layout Shift” scores:

1. Drupal : 70%
2. Joomla : 63%
3. Wix : 59%
4. WordPress : 57%
5. Squarespace : 44%

Even though Drupal and Wix might have reasons to celebrate, HTTP Archive does not approve, they do not consider that 59% score is a reason to celebrate and think that these 5 contenders need to improve. 

This is what HTTP Archive stated: “The top 5 CMSs could improve here. Only 50% of web pages loaded by a top 5 CMS have a “good” CLS experience, with this figure rising to 59% on mobile.

Across all CMSs the average desktop score is 59% and average mobile score is 67%. This shows us all CMSs have work to do here, but the top 5 CMSs in particular need improvement.”

The winners and the “not so winners”

Drupal took the 1st place twice while Wix took the 5th place twice. WordPress and Joomla fought ferociously in the middle, neither good nor bad. 

Our top 5 contenders scored decently for First Input Delay , but they disappointed when it came to  Largest Contentful Paint scores and Cumulative Layout Shift scores.

Why the CMS is rarely the real bottleneck

A ranking like the one above is easy to misread as “Drupal is fast and WordPress is slow”. It is more accurate to say that each platform attracts a different kind of build. Drupal sites tend to be commissioned projects with a developer attached; WordPress covers everything from a hand-tuned custom theme to a template bought in a marketplace and loaded with twenty plugins. The distribution of skill, not the software, produces most of the spread. WordPress also powers a very large share of the web, so its numbers include an enormous tail of neglected sites that nobody has looked at in years.

In practice, the things that decide a WordPress site’s Core Web Vitals are almost always these:

• Hosting and server response time. Time to first byte is the floor under your LCP. If the server needs a second before it sends anything, no front-end trick will rescue the score.
• The theme and any page builder. Visual builders that render layouts client-side ship far more CSS and JavaScript than a block theme doing the same job.
• Unoptimised hero images. A 3 MB PNG in the header is still one of the most common causes of a failing LCP.
• Plugin sprawl. Every plugin that enqueues a script or a stylesheet on every page adds main-thread work, which is precisely what INP punishes.
• Third-party tags. Analytics, chat widgets, heatmaps, ad tags and consent banners execute on the main thread and are typically outside your build pipeline entirely.
• Web fonts. Late-swapping fonts cause both layout shift and delayed text rendering.

Modern WordPress helps more than it used to. Core has shipped lazy loading for below-the-fold images since 5.5, skips lazy loading on the likely LCP image, adds a high fetch priority hint to it, supports WebP and AVIF output, and introduced speculative loading for near-instant navigations in 6.8. A current, well-built WordPress site can pass all three vitals comfortably. A neglected one on shared hosting will not, and moving it to another CMS would not fix that either.

How to audit your own Core Web Vitals

You do not need a paid tool to do this properly. Work in this order, because each step narrows the problem before you spend effort on it.

1. Start in Search Console. Open the Core Web Vitals report and look at the mobile tab. It groups URLs into buckets of similar pages, so you learn whether the problem is site-wide, template-specific or limited to a handful of pages.
2. Pick one representative URL per failing template. Fixing a template fixes every page built on it. Fixing one page fixes one page.
3. Run PageSpeed Insights on that URL. Read the field data section at the top first, since that is what Google actually assesses. The lab audit underneath is only a set of hypotheses about why the field data looks the way it does.
4. Reproduce it locally. In Chrome DevTools, open the Performance panel, enable mobile emulation with 4x CPU throttling and a slow network profile, and record a page load. Real causes become visible here: long tasks, render-blocking requests, a late-arriving hero image.
5. Measure INP by hand. Lab tools cannot invent interactions. Load the page, then click the menu, open an accordion, type in the search box and submit a form while the Performance panel records. Look for interactions that block the main thread longer than 200 ms.
6. Collect your own field data. Google’s open-source web-vitals JavaScript library reports LCP, INP and CLS from real visits and can send them into GA4 as events. This is the only way to see vitals for pages with too little traffic to appear in public field data, and it attributes the specific element responsible.
7. Re-check after 28 days. The assessment uses a rolling 28-day window, so a fix deployed today will not fully appear in Search Console until roughly a month later.

Fixing each metric on a WordPress site

Largest Contentful Paint

LCP breaks down into four parts: time to first byte, resource load delay, resource load duration and element render delay. Find out which part dominates before you act.

• Serve full-page cache and make sure the cache actually hits for logged-out visitors; a high TTFB is usually an uncached page or an overloaded database.
• Never lazy load the hero image, and give it a high fetch priority so the browser requests it early.
• Convert large images to WebP or AVIF and serve correctly sized versions through srcset rather than shrinking a desktop image with CSS.
• Preload the LCP image and the font used by the headline; remove render-blocking CSS and JavaScript from the head.
• Self-host fonts, subset them, and use font-display: swap so text is readable while the font arrives.

Interaction to Next Paint

INP has three parts: input delay, processing duration and presentation delay. Almost every WordPress INP problem is main-thread congestion.

• Audit which plugins enqueue assets globally and restrict them to the templates that need them.
• Defer non-critical JavaScript, and load chat, heatmap and social widgets only after the first interaction or after the page is idle.
• Break long tasks into smaller chunks and yield to the main thread so the browser can paint between them.
• Test the consent banner separately. Banners frequently run before anything else and delay the first real interaction.
• Replace heavy sliders and mega-menus that rebuild the DOM on every hover with lighter implementations.

Cumulative Layout Shift

CLS is measured in session windows of up to five seconds, so a single bad shift late in the load can define your score. It is also the cheapest metric to fix.

• Set explicit width and height attributes, or an aspect ratio, on every image, video, iframe and ad slot.
• Reserve space for anything injected after load: cookie notices, promo bars, newsletter boxes.
• Avoid inserting content above existing content unless it is a direct response to a user action.
• Match the fallback font’s size and spacing to the web font so the swap does not reflow the page.
• Check CLS on real mobile viewports; shifts that are invisible on a wide desktop screen are often severe on a phone.

A worked example

Suppose Search Console flags your blog template as poor on mobile LCP. PageSpeed Insights confirms it in field data, and the lab audit blames “properly size images”. The tempting move is to install an image optimisation plugin and call it done.

Instead, record the load in DevTools with throttling on. You see the HTML arrive slowly, a stylesheet and two plugin scripts blocking rendering, then the featured image requested only after the CSS finishes parsing. That tells a different story: the image is late because it is discovered late, not because it is large. The fix order becomes obvious. Get the page cached so the HTML arrives quickly, remove the two render-blocking scripts from the head, preload the featured image so the browser fetches it in parallel with the CSS, and only then compress it. The image plugin was step four, not step one, and on its own it would have produced a modest improvement while leaving the real cause in place.

This is the general rule with Core Web Vitals work: the tool tells you the symptom, the waterfall tells you the cause. Ordering your fixes by cause rather than by the tool’s checklist is the difference between a page that moves into the green and a page that stays amber after a lot of effort.

Frequently asked questions

Are Core Web Vitals a ranking factor?

Yes, but a modest one. Google has been consistent that page experience signals act as a tie-breaker between pages of comparable relevance rather than as a way to outrank genuinely better content. The stronger argument for fixing them is commercial: slow, jumpy pages lose visitors before they read anything, and that costs you conversions whatever your position in the results.

Should I move off WordPress to fix my scores?

Almost never. A migration carries real risk to your rankings and rarely addresses the underlying causes, which are usually hosting, images, scripts and theme choices that would follow you to the new platform. Spend a fraction of the migration budget on a performance audit of the current site first.

Why does my PageSpeed score differ from Search Console?

Because they measure different things. The PageSpeed performance score is a lab simulation run once on a synthetic device. Search Console reports field data from real Chrome users over 28 days at the 75th percentile. A perfect lab score with a failing field assessment usually means your real audience is on slower devices or connections than the simulation assumes.

My site has too little traffic to appear in field data. What now?

Add the web-vitals library and send the measurements to your own analytics, then use lab testing with heavy CPU and network throttling as a proxy. Low-traffic URLs also inherit the origin-level assessment, so improving your templates site-wide still helps them.

How long does it take to see improvement?

Lab tools react immediately. Field data moves gradually as the rolling 28-day window refreshes, so expect four to six weeks before Search Console reflects the full effect of a deployment. Do not revert a change because week one looks flat.

Do Core Web Vitals matter for AI-generated answers and assistants?

Not directly, since machines do not experience layout shift. They matter indirectly: pages that render fast and server-side are easier for every crawler to fetch and parse, and the same technical hygiene that improves vitals tends to improve crawlability and rendering reliability.

Where this leaves you

Even though Core Web Vitals is more about user experience and less about SEO and ranking in google search, they are still important. If a user has a great experience when using your website it is more likely that they will return and recommend the site to someone else, which will ultimately benefit SEO rankings as well. 

The CMS league table is a useful reminder that no platform is fast by default and none is doomed to be slow. Whichever one you use, the work is the same: measure with field data, find the cause in the waterfall, fix the biggest contributor first and re-measure a month later. If you would rather that ran alongside a wider plan for visibility, our SEO services cover technical performance work as part of the same engagement. For the current metric definitions and thresholds, Google maintains the reference on web.dev, and the annual HTTP Archive Web Almanac keeps publishing the CMS comparison this article started from.