There is no evidence-supported CMS that is fastest for every site. A managed platform may reduce infrastructure work, while a self-hosted or static setup may offer more control. The speed visitors experience comes from the complete delivery path: hosting, cache behavior, templates, images, scripts, device, location, and network.
If a mobile article is slow because its hero image is oversized, moving it to another CMS may not fix the problem. Measure representative pages first, identify the slow stage, and choose a platform for the way your team operates rather than relying on an unverified leaderboard.
This guide separates platform capabilities from page-level performance. It compares operating models, defines a repeatable test record, and gives a controlled process for deciding whether to optimize the current site or consider migration.
Is there one fastest CMS?
No universal winner can be established from the available evidence. Google classifies Largest Contentful Paint (LCP), the time until the largest visible content element renders, as good at 2.5 seconds or less at the 75th percentile, segmented by device. LCP includes connection setup, redirects, time to first byte (TTFB), and rendering. It is a user-experience measure, not a CMS processing benchmark. See Google’s LCP guidance.
Keep three kinds of evidence separate. A lab run tests a particular page under specified conditions and helps diagnose it. Field data reflects real visitors over an observation period. An origin-level aggregate compares eligible sites detected as using a technology; it does not isolate the CMS from hosting, design, or implementation. The HTTP Archive Core Web Vitals technology report is useful context, not a controlled head-to-head CMS test.
Choose a CMS for its fit with your operating model. Establish speed with repeatable tests of your own pages.
Start with three questions: Who owns hosting and infrastructure? How much technical control and customization does the team need? What page-level evidence would show that performance is a problem?
What to compare before choosing a CMS
Compare operating models and the work they leave to your team. The table is a shortlist, not a speed ranking. Evidence to request means current platform documentation or site-specific testing, not a promise that every configuration performs alike.
| Operating model | Good fit when | Performance work owned by the team | Evidence to request |
|---|---|---|---|
| Managed SaaS CMS | You want fewer infrastructure decisions and can accept platform constraints. | Custom templates, images, third-party scripts, integrations, and page-level testing. | Documentation for the relevant plan, followed by tests of your own pages. |
| Self-hosted WordPress | You need a broad ecosystem and control over implementation. | Hosting, theme and plugin choices, caching, CDN, updates, and database health. | WordPress performance guidance and a record of the actual stack. |
| Drupal | You need structured content, complex permissions, or developer-controlled delivery. | Cache contexts and invalidation, personalized behavior, and infrastructure configuration. | Drupal Internal Page Cache documentation and tests for relevant user states. |
| Ghost | Publishing is the core job and its scope fits your needs. | For self-hosting: hosting, backups, and CDN decisions. For Ghost(Pro): custom assets and integrations still need testing. | Ghost hosting guidance and the applicable managed or self-hosted configuration. |
| Static generation | Content changes and deployment workflows suit prebuilt delivery. | Build and deployment workflow, assets, JavaScript, and delivery infrastructure. | Tests of generated pages and the deployment process. Static delivery alone is not a speed result. |
WordPress is flexible, but performance depends on hosting, theme, plugins, software, images, and cache configuration. WordPress describes page, browser, object, and server caching as distinct layers rather than prescribing one universal setup. Drupal provides Internal Page Cache for anonymous-page behavior and Dynamic Page Cache for pages with dynamic or personalized portions. Cache contexts and invalidation still matter.
Ghost(Pro) and self-hosted Ghost are different operating choices. Ghost documents Ghost(Pro)’s supported CDN arrangement and says adding another CDN layer is unsupported and may interfere with site behavior. Do not assume self-hosted Ghost has the same infrastructure. HubSpot’s current developer guidance documents capabilities including CDN delivery, image optimization and WebP conversion, caching, minification, compression, and prerendering. Verify what applies to the plan and configuration in question, then test custom code and third-party scripts separately.
Duda reported an 80% Core Web Vitals pass rate in a December 2, 2024 announcement. That is a vendor-reported result, not an independently audited comparison or a guarantee for an individual site. The extracted November 2025 HTTP Archive percentages and site counts for several CMS platforms could not be rechecked from the accessible report. They should not be used as verified rankings.
Measure the site you have before considering migration
Choose representative page types such as a homepage, article, and conversion page. Test mobile and desktop separately. PageSpeed Insights can show available lab and field results; WebPageTest can help inspect repeatable lab runs and loading details. Save the tool output and context rather than recording only a score.
Track LCP, Interaction to Next Paint (INP), Cumulative Layout Shift (CLS), TTFB, page weight, request count, JavaScript bytes, and image bytes where available. LCP concerns when the main content appears. INP concerns interaction responsiveness. CLS describes unexpected layout movement. TTFB helps investigate the response before page content arrives. Page weight and request counts help locate potential sources of delay. None alone proves that the CMS is the cause.
Use the evidence to form a bottleneck hypothesis. Slow TTFB points toward origin, network, or cache investigation. Slow LCP may involve TTFB, the main image, fonts, or render-blocking resources. Poor INP calls for examining JavaScript and long tasks. CLS calls for checking image dimensions, late fonts, and content inserted after layout. These are investigation leads, not automatic diagnoses.
For each lab execution, store one record per test run. A run is not a URL, CMS, or monthly aggregate. The following is a hypothetical field contract. Its values are illustrative, not measured results:
{
"test_run_id": "database-generated-unique-id",
"url": "https://example.com/sample-article/",
"page_template": "article",
"cms": "declared-platform",
"environment": "production",
"device": "mobile",
"location": "test-region",
"connection_profile": "declared-profile",
"timestamp_utc": "recorded-execution-time",
"cache_state": "HIT, MISS, bypassed, or unknown",
"lcp_ms": null,
"inp_ms": null,
"cls": null,
"ttfb_ms": null,
"page_weight_bytes": null,
"request_count": null,
"javascript_bytes": null,
"image_bytes": null,
"deployment_id": "release-or-configuration-id",
"source_url": "test-tool-result-url",
"raw_result_uri": "optional-stored-artifact-location"
}Keep field-period summaries in a separate record with its date range, device, geography, and population scope. Do not write a platform-wide pass rate into an individual test-run row. Use a database-generated unique ID or a database-enforced unique key that captures the test context. If multiple workers can submit the same result, use an atomic upsert against that constraint. A read-then-insert check can race. Rules are better than AI for validating required fields, allowed device values, timestamps, and duplicate IDs. AI is not needed to run or approve the test. If used to summarize stored results, constrain it to recorded run IDs and have a person verify causal conclusions.
Fix the observed bottleneck before changing CMS
Set a success criterion before the change, such as improving LCP on named mobile article pages without worsening INP or CLS, breaking interactions, or serving stale content. Keep baseline and retest records linked to the deployment. If hosting, images, scripts, and CMS settings all change together, you cannot tell which change mattered.
- WordPress: Record the host, theme, plugins, software versions, page and object cache, CDN state, and relevant database load. If removing a plugin appears to help a lab run but breaks a form, restore the feature or replace the plugin before retaining the change.
- Drupal: Identify whether Internal Page Cache, Dynamic Page Cache, a reverse proxy, or a CDN served the response. If anonymous users see personalized content or a published page remains stale, review cache contexts and invalidation before expanding the cache.
- HubSpot CMS: Separate documented platform-managed features from custom modules, custom scripts, and external tools. If a custom tracking script increases interaction delay, test its loading behavior and confirm analytics still works before deferring or removing it.
- Ghost: Record whether the site is Ghost(Pro) or self-hosted. If a proposed extra CDN layer conflicts with Ghost(Pro)’s supported arrangement, do not deploy it. Investigate page assets and supported configuration instead.
Consider a migration when tested requirements continue to fail after reasonable fixes, or when the current model consumes unacceptable infrastructure effort. The reason should be a documented requirement or operating cost, not a platform ranking.
Cache safely and verify the page still behaves correctly
Page cache, object cache, browser cache, server or reverse-proxy cache, and CDN cache are different layers. A cache hit may reduce repeated work, but it does not make every page safe to cache. Before changing page-cache behavior, map variations caused by authorization, cookies, locale, query strings, and personalization. Confirm that cache keys distinguish variations that change output and that publishing invalidates affected pages.
- Document which cookies, query strings, locales, roles, or other conditions change the page.
- Verify the cache key represents each variation that affects output.
- Test anonymous and authenticated paths separately where both exist.
- Publish a test change and confirm relevant pages refresh instead of remaining stale.
- Check that personalized content is excluded, safely varied, or rendered separately before rollout.
For images, preserve dimensions to reduce layout shifts and avoid lazy-loading the image likely to be the LCP element. For JavaScript, verify page interactions and INP after changing loading behavior. HubSpot’s documentation recommends attention to image sizing, dimensions, selective lazy loading, and appropriate JavaScript loading. These are implementation choices to test, not guaranteed improvements.
Choose the operating model, not a leaderboard
- Choose managed SaaS when lower infrastructure ownership is valuable and the platform’s constraints fit. Still test custom templates, assets, and integrations.
- Choose self-hosted WordPress or Drupal when control and extensibility justify the technical ownership required to maintain hosting, caching, updates, and delivery.
- Consider Ghost when publishing is the main job and its narrower scope fits. Compare Ghost(Pro) with self-hosting as distinct responsibility models.
- Consider static generation when the content update cycle and build-and-deploy workflow suit prebuilt delivery. Large assets, heavy JavaScript, or poor delivery can still produce a slow experience.
- Choose headless architecture only when multiple front ends, channels, or independently optimized presentation layers justify the added development and operational complexity.
Make the decision from a written list of publishing workflows, channels, customization needs, infrastructure ownership, measured page constraints, and available technical capacity. Shortlist architectures against those requirements. A pilot should use representative pages and the same test protocol as the current site.
For teams reviewing platform responsibilities and operating requirements before making that decision, ConsultEvo services may be relevant. A migration is justified when the current model repeatedly misses tested requirements or imposes an unacceptable operational burden, not simply because another CMS appears higher in an aggregate report.
Sources and evidence limits
Platform documentation describes capabilities, not guaranteed results for every plan or implementation. Vendor announcements are vendor-reported claims. Lab tests describe the tested page and conditions; field metrics and origin-level aggregates have different populations and time scopes. No independent head-to-head benchmark of the CMS options discussed here was performed, and the extracted November 2025 HTTP Archive figures were not confirmed from an accessible historical export.