# Is Ghost faster than WordPress?

Out of the box, Ghost usually serves a lighter page through a shorter request path than a typical plugin-heavy WordPress install, so on a default setup Ghost tends to feel faster. But "faster" isn't one number, and a well-cached WordPress site on good hosting can match or beat an untuned Ghost one. The CMS sets your starting point. Caching, hosting, your theme and how much third-party script you load decide where you finish.

I can't hand you a universal benchmark, and I'd be suspicious of anyone who does. What I can do is show why the two start from different places, which metrics matter, how to test fairly on your own content, and what to tune. Then comes where neither is fastest, and when speed shouldn't decide at all.

Disclosure: I work on VeloCMS, a hosted publishing platform. It appears as one of six options in the comparison section, weaknesses included. The rest of this article is about Ghost and WordPress.

**Last verified: November 9, 2026.**

I read the vendor and standards pages linked at the end on that date. I didn't run a head-to-head benchmark for this piece, so there are no invented numbers, and every figure sits on the page linked beside it. Pricing pages change, so I point at them instead of quoting amounts.

## Why does architecture matter for the answer?

Both systems are dynamic: an application, a database, and a template layer that turns rows into HTML. The differences are in what's installed by default and how much work happens before the first byte leaves the server.

Ghost's architecture page describes a Handlebars theme layer served by an Express.js web server, plus a Content API the docs call "designed to be fully cacheable." Its themes page says Ghost themes use the Handlebars templating language and that server-side publication content is sent to the browser as static HTML. For production the docs recommend MySQL, and the Ubuntu install guide lists MySQL 8.0 or 8.4. One product, one runtime, one recommended production database, one template language.

WordPress is PHP plus MySQL or MariaDB. The requirements page recommends PHP 8.3 or greater and MySQL 8.0+ or MariaDB 10.11+, with Apache or Nginx. The template hierarchy page notes that its examples use PHP files and that block themes use HTML files instead. The core is lean enough. The weight arrives with what you add: a page builder, forms, SEO and security plugins, a slider, three analytics snippets. Each can add database queries on the server and JavaScript or CSS in the browser.

That's the honest core of the "Ghost is faster" folklore. Ghost's defaults are narrow, so a fresh install has less that can go wrong, while WordPress's culture is to extend, so real installs drift heavy. A bare WordPress install with a lean block theme is a very different animal from the plugin-stuffed agency site behind most speed complaints. Compare a tuned Ghost to a neglected WordPress and you're measuring neglect.

One more fact before you test: Ghost's docs say it also works as a headless system "completely agnostic of any particular front end or static site framework." Put a static front end in front of it and Ghost is no longer what your visitors hit.

## What does "faster" actually mean?

Time to First Byte (TTFB) is the gap between starting navigation and the first byte of the response. web.dev calls 0.8 seconds or less good and anything over 1.8 seconds poor. It isn't a Core Web Vital but a diagnostic: a slow TTFB drags everything after it down, a fast one guarantees nothing. Server differences show up here most, through cache hits and misses, database round trips and PHP or Node work.

Largest Contentful Paint (LCP) is the loading metric Google scores, with a target of 2.5 seconds or less. It's mostly your hero image, fonts, render-blocking CSS and theme. It can be great on a slowish server and poor on a fast one.

Interaction to Next Paint (INP, target 200 milliseconds or less) and Cumulative Layout Shift (CLS, target 0.1 or less) are mostly front-end JavaScript and layout choices. A server can't fix them, which is why the CMS name on the box tells you less than you'd expect. Per web.dev, a page passes when it meets the targets at the 75th percentile of page loads, segmented across mobile and desktop.

Add page weight (how many requests and kilobytes of script does a post pull in?) and editor speed, the metric nobody charts. How quickly does the editor open, and how does the media library behave with five thousand images? Visitors never feel it, you will every day. I haven't measured the two on identical hardware, so treat it as a test to run.

## How do you compare them fairly?

Most Ghost-versus-WordPress screenshots are unfair in at least one way: different hosts, regions or content, or a warm cache on one side and a cold one on the other. Here's a plan that removes the usual cheats.

Use the same content. Import the same 20 posts and images, and match the homepage layout as far as each theme allows.

Use the same host class and region, or say so when you don't. Ghost on a small VPS against WordPress on a managed host with a global CDN compares hosts, not engines. Run both on identical VPS specs first, then each platform's best realistic setup.

Test cold and warm separately. web.dev's lab-versus-field guide notes that lab tests typically load a page with a cold cache, while returning users often have resources cached. A cache-miss TTFB shows how your origin copes after a purge or for old posts; a cache-hit TTFB shows what most visitors get. Report both.

Run several times on a throttled profile. WebPageTest lets you choose the test location, a device and connection combination, the number of runs, and a repeat view that loads the page twice. Take the median, not the best run, and remember a lab test represents one device, one network and one location.

Check field data if the sites are live. The Chrome UX Report (CrUX) shows how real Chrome users experience popular sites, though only origins with enough visitors are included. A small blog may return nothing, so lab data is all you have.

Finally, test the pages that matter: a post with six images and an embed, an archive, a search result, and a logged-in member view. That's where the systems diverge, not on the homepage.

## What does the public data say?

Less than you'd hope. The HTTP Archive publishes a Core Web Vitals Technology Report combining CrUX field data with technology detection, and its Web Almanac CMS chapters rank the big platforms. The 2025 chapter's mobile figures show a 45% pass rate for WordPress, among the lowest of the ranked CMSs, and the text says WordPress gained around 4% year over year (it doesn't say whether that is points or a relative change). The 2024 chapter had it at 40%, up from 28% in 2023. The 2025 chapter also says more tightly managed platforms gained the most, while more extensible ones improved less.

Two cautions. Those are WordPress-wide numbers across a huge population, including every neglected install on cheap hosting, so they describe the average site, not a tuned one. And I couldn't find Ghost anywhere in that chapter, so I can't point you to a primary-source dataset comparing the two. The Technology Report is where to look up per-technology numbers yourself; check which technologies it covers and the date range. If an article claims "Ghost sites pass at X% and WordPress at Y%," ask for the dataset and the date.

## Does hosting change the result more than the CMS?

Often, yes. Hosting is the biggest confound in any comparison.

For Ghost you have two routes. Ghost(Pro) is the official managed service. Its pricing page lists a worldwide CDN on all plans, says installs are integrated with Fastly, and includes automated backups and updates. If you self-host, the install guide describes Ubuntu, MySQL 8, Nginx and a server with at least 1 GB of memory. Performance is then whatever you build around it: proxy, TLS, CDN, backups.

For WordPress the range is wider. At one end is bargain shared hosting with a crowded server, an old PHP version and no object cache. At the other are managed hosts that bundle page caching, object caching and an edge network. WordPress.com documents one version: a global edge cache that stores copies of pages and static files on edge servers, always on for its Free, Personal and Premium plans and switched on in settings for Business and Commerce. Read each host's docs for what's actually included instead of trusting "optimized for WordPress."

That's why "Ghost on a good VPS beats WordPress on cheap shared hosting" is true and useless. Compare like with like, and accept that the best setup costs money or time.

## How do you make WordPress fast?

The WordPress developer handbook's optimization guide is a decent checklist.

Install a page cache. The guide notes that caching plugins can cache posts and pages as static files, and that a system-level cache such as Varnish can add more. For anonymous readers, a cache hit can be served without running most of PHP, which is where much of the gap closes.

Add a persistent object cache if your host supports one. The guide says it saves trips to the database and needs a cache server from your host plus a compatible plugin. It matters most for logged-in traffic, stores and the admin, where page caching can't help.

Confirm PHP's opcode cache is on. The guide names accelerators such as OPcache. Most decent hosts have one, but check.

Trim the database: InnoDB tables, a sensible cap on stored revisions, and small autoloaded options, since they load on every page view (the guide mentions staying under roughly 800 KB).

Be ruthless with plugins. The guide calls deleting unnecessary plugins a significant way to improve performance. Treat each one as a recurring cost, disable suspects one at a time, and re-run the same test.

Optimize images and use a CDN. The guide recommends the right format and compression per image, mentions WebP, and describes a CDN for offloading images, scripts and styles. A very common cause of poor LCP is an oversized hero image and a render-blocking font, not the CMS.

## How do you make self-hosted Ghost fast?

Ghost needs less tuning, but not none.

Start with the cache defaults. Ghost's configuration docs have a caching section that applies to responses carrying `public` in the Cache-Control header. The listed default `maxAge` for `frontend` (public pages such as the homepage) is 0 seconds, and so is `contentAPI`, while public assets such as `ghost.css` default to a year. In plain terms, Ghost's own headers don't ask a shared cache to keep your HTML for any length of time by default. If you want a CDN or reverse proxy to serve pages without waking Node, configure that deliberately, either in the proxy or by setting those values, and test that a purge happens when you publish.

Then think about images. Per the config docs, editor uploads are resized to a 2000px maximum width, JPEGs are compressed to 80% quality and metadata is stripped. If you move storage to an S3-compatible bucket behind a CDN, the docs warn you need a resizing layer, because responsive sizes are created on demand.

Keep the theme honest. A Handlebars theme can load hundreds of kilobytes of script as easily as a PHP one, so audit third-party embeds, chat widgets, fonts and analytics. The themes page says the approach allows themes to be "super fast", but one script tag can undo that.

## Where is neither of them the fastest?

If raw delivery speed is your top priority, both lose to a pre-built static site on a CDN.

A static site generator builds HTML once and serves files. Hugo describes itself as "a static site generator written in Go, optimized for speed," and says it renders a complete site in seconds, often less. (That's about build time, not page load. Page speed comes from the server having nothing to compute.) Astro calls itself a web framework for content-driven websites, lists "Zero JS, by default" as a highlight, and takes a server-first stance: "Websites run faster when they render HTML on the server." Both take the application and database off the reader's request path.

The trade-off is editing. You write Markdown or use a headless CMS, commit, and wait for a build. There's no built-in membership, newsletter or comments unless you add services. For a developer blog that's often a fine deal; for a team of editors it often isn't.

A common middle path is headless Ghost: keep its editor, memberships and newsletter, and render the public site with a static or hybrid front end such as Astro. You get Ghost's authoring with static delivery, at the cost of owning a front-end project.

Hosted site builders are a third category. Wix has a web.dev case study saying the share of its sites with good Core Web Vitals more than tripled year over year, which it credits to server-side rendering, HTML caching in more regions and other infrastructure changes. That's a vendor's own case study, so I treat it as a claim, not a benchmark.

## How do the six options compare?

Six realistic choices for a blog, in the same shape: stack, main speed lever, main weakness, source.

### Ghost (self-hosted, or Ghost(Pro))

A Node.js publishing platform with Handlebars themes, MySQL in production and built-in membership and newsletter features. Its narrow default surface is why it starts light. Self-hosted, you own the server, proxy, CDN and upgrades. Ghost(Pro) is the same software run by Ghost, with a CDN and backups included per its pricing page.

- Stack: Express.js serving a Handlebars theme layer; MySQL recommended for production.
- Main speed lever: a CDN or proxy configured deliberately, plus a lean theme.
- Main weakness: you run the ops on self-host, and the speed gains from the default stack depend on a CDN or proxy you set up yourself.
- Source: https://docs.ghost.org/architecture

### WordPress (self-hosted)

The flexible default: PHP, MySQL or MariaDB, a very large theme and plugin ecosystem, and a deep pool of hosts and developers. Page cache, object cache, OPcache, few plugins and a CDN get it close to anything else dynamic.

- Stack: PHP 8.3 or greater, MySQL 8.0+ or MariaDB 10.11+, Apache or Nginx recommended.
- Main speed lever: page cache, object cache and plugin discipline.
- Main weakness: default drift. Plugin sprawl and weak hosting are the usual suspects when a site is slow.
- Source: https://developer.wordpress.org/advanced-administration/performance/optimization/

### Managed WordPress (WordPress.com as one example)

A host takes the cache layer off your plate. WordPress.com documents a global edge cache plus a CDN for images and static files; other hosts differ, so read their docs. You trade some flexibility for a baseline you don't have to build.

- Stack: WordPress with host-run caching, edge network and updates.
- Main speed lever: edge caching, on by default for some plans and a toggle on others.
- Main weakness: plan-based limits, cost, and real differences between hosts.
- Source: https://developer.wordpress.com/docs/site-performance/

### Hugo or Astro (static generator)

Pre-built HTML on a CDN. Hugo is written in Go and builds quickly. Astro ships zero JavaScript by default and targets content-driven sites. Nothing dynamic runs per reader request.

- Stack: generator plus any static host or CDN; content in Markdown or a headless CMS.
- Main speed lever: no application or database on the read path.
- Main weakness: the authoring workflow, and no built-in members, newsletter or comments.
- Sources: https://gohugo.io/about/introduction/ and https://docs.astro.build/en/concepts/why-astro/

### Wix (hosted builder)

A closed hosted platform with visual editing and no servers to run. Wix publishes its own case study on improving Core Web Vitals through server-side rendering and wider HTML caching. You can't change the infrastructure, so you get what the platform delivers.

- Stack: proprietary hosted runtime.
- Main speed lever: the vendor's own infrastructure work.
- Main weakness: little room to tune, and you're tied to the vendor's platform.
- Source: https://web.dev/case-studies/wix

### VeloCMS (hosted)

A hosted blog platform made by the company I work for. Its tech-stack page lists Next.js with ISR for blog posts, PocketBase on SQLite, Railway hosting and Cloudflare. Its performance page publishes field data for the 90 days to November 9, 2026 (p75 LCP 2.33s, INP 32ms, CLS 0.002, TTFB 646ms) and a September 27, 2026 lab run with a mobile LCP of 3.90s. Those numbers are self-reported across its own live blogs, and the page admits field LCP misses its stricter internal budget.

- Stack: Next.js with ISR, PocketBase, Railway, Cloudflare.
- Main speed lever: server-rendered pages with cached data reads refreshed on publish.
- Main weakness: managed SaaS only (there is no self-hosted install), a mobile lab LCP that misses its own target, and no free plan (a 14-day trial, card normally required).
- Source: https://velocms.org/performance

## When is speed not the deciding factor?

For most blogs, once a page loads under about two and a half seconds on a mid-range phone, extra milliseconds rarely change anyone's behavior. What the system does for you matters more than a 200ms gap.

If you sell memberships or send a newsletter, ask how much of that machinery is built in and how much you'll glue together. Ghost includes both. WordPress can do both with plugins or services, with more choice and more moving parts. A static site needs outside services for each.

If you need a specific plugin or integration, such as a niche course platform, a booking tool or a directory, WordPress's ecosystem is hard to match, and that can outweigh a speed edge. If your editors aren't technical, the editing experience matters daily and a static pipeline probably isn't for them. If you'd rather not patch servers, a managed service beats a faster setup you resent maintaining.

If the real goal is search visibility, page experience is one signal among many. A fast site with thin content won't outrank a useful, slower one.

## Who is each option best for?

- Ghost (self-hosted or Ghost(Pro)): publishers who want built-in memberships and a clean writing experience, and either run a Node and MySQL stack or pay Ghost to.
- WordPress (self-hosted): anyone who needs plugin depth or an agency ecosystem, and will keep the stack cached and patched.
- Managed WordPress: people who want WordPress compatibility with a host-run performance layer.
- Hugo or Astro: developers who care most about delivery speed and don't mind Markdown and builds.
- Wix: people who want a visual builder and zero ops, and accept the lock-in.
- VeloCMS: bloggers who want a hosted blog with newsletter, membership and a store included in every plan. It isn't the pick if you need to self-host.

## FAQ

### Is Ghost faster than WordPress out of the box?

Usually, by default. Ghost ships a narrow stack, while a typical WordPress site accumulates plugins. That's about defaults, not ceilings, so test your own content.

### Can WordPress be as fast as Ghost?

Yes. With a page cache, a persistent object cache, OPcache, a lean theme, few plugins and a CDN, a WordPress blog can serve cached pages as quickly as any dynamic system. The effort is higher, and it's yours to maintain.

### Which one has better Core Web Vitals?

I don't have a primary-source dataset that compares them. The 2025 Web Almanac CMS chapter reports a 45% mobile pass rate for WordPress overall, and I couldn't find Ghost in it. Your theme, images and scripts dominate, so measure your own site with CrUX or lab tools.

### Does self-hosted Ghost cache pages by itself?

Not in a way you should rely on for CDN-style caching. Ghost's configuration docs list a default `maxAge` of 0 for public frontend pages, while public assets default to a year. If you want a proxy or CDN to serve HTML without hitting Node, set that up and verify purges on publish.

### Should I switch CMS just for speed?

Rarely. Measure first. An oversized hero image and 40 plugins are cheaper to fix than a migration, which brings its own risk to URLs and rankings. Switch for editing, features or operations reasons, with speed as a bonus.

## Sources

- Ghost architecture: https://docs.ghost.org/architecture
- Ghost themes: https://docs.ghost.org/themes
- Ghost configuration: https://docs.ghost.org/config
- Ghost Ubuntu install requirements: https://docs.ghost.org/install/ubuntu
- Ghost(Pro) pricing: https://ghost.org/pricing/
- WordPress requirements: https://wordpress.org/about/requirements/
- WordPress optimization guide: https://developer.wordpress.org/advanced-administration/performance/optimization/
- WordPress template hierarchy: https://developer.wordpress.org/themes/basics/template-hierarchy/
- WordPress.com site performance: https://developer.wordpress.com/docs/site-performance/
- Web Vitals: https://web.dev/articles/vitals
- TTFB: https://web.dev/articles/ttfb
- Lab and field data: https://web.dev/articles/lab-and-field-data-differences
- Chrome UX Report: https://developer.chrome.com/docs/crux
- Core Web Vitals Technology Report: https://httparchive.org/reports/cwv-tech
- Web Almanac 2025, CMS: https://almanac.httparchive.org/en/2025/cms
- Web Almanac 2024, CMS: https://almanac.httparchive.org/en/2024/cms
- WebPageTest instant tests: https://docs.catchpoint.com/wpt/docs/instant-tests
- Hugo: https://gohugo.io/about/introduction/
- Astro: https://docs.astro.build/en/concepts/why-astro/
- Wix case study: https://web.dev/case-studies/wix
- VeloCMS performance: https://velocms.org/performance
- VeloCMS tech stack: https://velocms.org/tech-stack