Is WordPress slow? What the 2025 data shows
WordPress sites pass the Core Web Vitals less often than sites on managed builders, but the spread is wide. What the 2025 Web Almanac found and what to do.
In this guide
What the numbers say
The 2025 Web Almanac measures real visitors. A site passes only when all three Core Web Vitals are good. The table shows mobile results for the platforms where the CMS chapter gives both figures.
| Platform | Sites passing all three | Sites with a good LCP |
|---|---|---|
| Duda | 85% | 94% |
| TYPO3 | 79% | 89% |
| Wix | 74% | 81% |
| Weebly | 47% | 52% |
| WordPress | 45% | 53% |
Loading is the weak point. For layout stability, the chapter puts WordPress at around 84% of sites with a good result, which is close to Joomla and well short of Wix at 95%. In the lab, the median mobile Lighthouse performance score for WordPress sites was 41. Wix reached 64, Webflow 58, Duda 57 and Shopify 52. On desktop, WordPress sites had a median of 63 against 87 for Wix and 81 for Duda. The Almanac says these lab scores are best read as context, not as a proxy for real-user experience.
WordPress improved between 2024 and 2025, by about 4% in the share of sites passing. The chapter notes that platforms with more tightly managed environments gained the most.
What the numbers do not say
Be careful with a table like this. It describes a whole platform, not your site. The Almanac itself says its aim is not to crown a single fastest platform, but to understand how the level of control affects results at scale.
Three points matter.
- The platforms are different kinds of product. Wix, Duda and similar builders run the servers, the delivery and most of the code. A WordPress site is usually run by its owner, an agency or a host. Its result reflects those choices as much as WordPress.
- The spread is wide. The Almanac says WordPress sites show a wide range of performance, driven more by configuration and tooling than by core. A WordPress site can be among the fastest or the slowest on the web.
- Weight does not explain it. In the Almanac's page weight chart, the median WordPress page on mobile weighed 2,894 KB, among the lightest of the five platforms shown and well below Squarespace at 3,974 KB. Its median JavaScript was 638 KB on mobile, against 1,634 KB for Wix and 1,615 KB for Shopify. So WordPress pages are not slow because they are heavy. The chapter does not say where the delay comes from. In our own guides, the usual causes of a slow Largest Contentful Paint are the server, a missing cache and a main image that is found late. See how to fix a slow LCP.
Why managed builders score higher
A managed builder makes many speed decisions for every site on it. The same servers, the same caching, the same image handling, the same limits on what can be added. That raises the floor. It also lowers the ceiling for anyone who wants control, as Wix, Squarespace and Webflow explains.
WordPress works the other way. It lets the owner choose the host, the theme, the plugins and the tools, and each choice can help or hurt. The Almanac describes this as more responsibility moving onto site owners and implementers.
What WordPress has done about it
The Almanac says recent core work has focused on cutting unnecessary payloads and narrowing the gap between well-tuned and poorly tuned sites. Core now loads block styles and scripts more selectively and skips assets for hidden blocks. It generates AVIF images faster, sizes images better and lazy-loads more reliably. It can prefetch or prerender likely navigations.
The WordPress source shows the same direction, as described in our WordPress guides: srcset and sizes are added to editor images, below-the-fold images are lazy-loaded, the first large image gets fetchpriority="high", and speculative loading was added in version 6.8. Those help only when nothing overrides them, and a theme, a builder or a plugin can.
WordPress core does not add a page cache. Most slow sites miss exactly that. See caching explained.
Page builders: the big variable
About 60% of WordPress sites use a page builder, according to the Almanac. Its chart of the leading builders shows Elementor at 43% on mobile, the Block Editor at 18%, WPBakery at 13% and Divi at 10%. The Almanac says builders often produce more complex markup and larger style and script files, and that they are a major reason performance varies between WordPress sites. Newer builders try to load assets only when needed, but the gap with simpler builds has not closed. See Elementor and page builders.
What decides your result
| Lever | Why it matters | Start with |
|---|---|---|
| Hosting and PHP | Sets the speed of the first byte | WordPress hosting for speed |
| A page cache | Serves finished pages without running PHP | WordPress caching |
| Theme and builder | Decide the markup, CSS and JavaScript on every page | Themes and plugins |
| Plugins | Each one can add files and database work | Themes and plugins |
| The main image | Usually the Largest Contentful Paint element | WordPress image optimization |
| Third-party scripts | Analytics, chat and ads load code from other companies | Third-party scripts |
The full order of work is in how to speed up a WordPress website, and the short form is the WordPress speed checklist.
Should you move to another platform?
Not because of a table. A move is a project with risks: addresses change, search visibility can drop, and the same heavy images and tags travel with you. See the website migration checklist.
| If this is true | Then |
|---|---|
| The site is slow, and nobody has checked the host, the cache or the main image | Fix those first. They are cheap, and they are where WordPress sites usually lose time |
| You have tuned the site and it still fails on mobile | Look at the theme, the builder and the third-party tags before you change platform |
| The site is simple, nobody maintains it, and you do not need plugins | A managed builder may be easier to keep fast. Check what it cannot do |
| The site is large, custom or a store | The platform matters less than the engineering. See optimize or redesign |
Mistakes to avoid
- Reading the 45% as your score. Your site is one point in a wide spread.
- Blaming WordPress for a plugin stack. Remove the heavy plugin first and test again.
- Switching platform to fix a problem that lives in images or tags. It will move with you.
- Assuming a managed builder never needs work. The Almanac's figures for loading are good, not perfect.
Check your own page
Run the free audit on your home page. If the server response is the biggest part of the load, start with hosting and the page cache. If it is small, look at the main image and the scripts.
Sources
- CMS chapter, Web Almanac 2025: the Core Web Vitals pass rates by platform, the Lighthouse medians, page weight by platform, the remarks on variation, core performance work and page builders.
- WordPress core: media.php and speculative-loading.php: the image and loading behavior described in our WordPress guides.
- The WordPress guides on this site, which carry the sources for each step.
Start here
Free website audit
Live Google data for any public page: mobile and desktop.
Mobile + desktop · Lighthouse lab test · Real-user Chrome data when Google has it
Rather have this done for you? WordPress speed · Book a call