Case Study: ATKDA Website Performance Report - WordPress vs primeCRM

Date: May 2026
Prepared by: Libertas Software
Scope: 15 matched pages, 3 runs per page, curl-based HTML document timing

---

Executive Summary

We benchmarked the existing ATKDA WordPress site against the new primeCRM-powered site running on a pre-production test domain. Both sites were measured over the network under identical conditions — the same machine, same connection, three timed runs per page with averages taken.

The results are unambiguous. The new site is 9.3× faster on average across all 15 matched pages. Server processing time (TTFB) — the single biggest contributor to page slowness on WordPress — is 10.6× faster on primeCRM.

---

Methodology

What was measured

Each page was fetched using curl with the following timing variables captured:

• DNS — time to resolve the hostname
• Connect — time to establish the TCP/TLS connection
• TTFB — Time to First Byte; the time from connection established until the first byte of the response is received. This reflects pure server-side processing time.
• Total — full time until the response body is downloaded

Each page was fetched three times with a one-second pause between runs. The three totals were averaged for the final score.

Note: This test measures only the HTML document response — not the full page load including fonts, JavaScript, CSS, and images.

What was not measured

• Full browser page load (JS execution, font loading, image loading)
• Core Web Vitals (LCP, FCP, CLS)
• Mobile performance
• Performance under load / concurrent users

---

URL Mapping

The new site restructures several URLs. The table below documents the full mapping used in this comparison.

New pages with no WordPress equivalent

The new site adds the following pages that did not exist on WordPress:

• /en/schools — Schools hub / index
• /en/events — Events hub / index
• /en/privacy-policy
• /en/cookie-policy
• /en/gender-equality-plan

---

Results

Page-by-page comparison

Connect time comparison

Network overhead (DNS + TCP/TLS handshake) was comparable on both sites, confirming the difference in total response time is application-level, not infrastructure or network:

---

Analysis

The TTFB story

TTFB is the most important metric in this test. It represents the time the server spends processing the request before sending a single byte back to the browser — PHP execution, database queries, plugin resolution, template rendering. It has nothing to do with network speed or browser capability.

On WordPress, TTFB accounts for 87–95% of every page's total response time. The server is spending between 1.15 and 1.60 seconds just thinking per request. This is consistent with a heavily-plugged WordPress installation where every page load triggers a full PHP bootstrap, multiple database queries, and plugin execution chains.

On primeCRM, TTFB ranges from 0.10 to 0.16 seconds — a 10.6× improvement. This reflects a fundamentally different server-side architecture: pre-compiled templates, minimal runtime overhead, and no plugin chain to resolve.

What this means for users

Research consistently shows that page load time directly affects user behaviour. At the 1.5s range WordPress averages, a meaningful proportion of visitors — particularly on mobile — will experience the page as slow. At 160ms, the HTML document is delivered before users consciously register any delay.

The full picture will improve further. This test captures only the HTML document. The new site's reduction in overall page complexity — fewer plugins, cleaner asset loading — will produce additional gains in the full browser load time that will be captured in the follow-up Playwright test.

Conclusion

The numbers in this report cover only the retrieval of the HTML document — the server's response before a browser has loaded a single asset. Even at that level alone, the new site is 9.3× faster than WordPress, with server processing time reduced by more than 90% across every page tested.

The full user experience improvement is larger still. Two additional changes compound the HTML performance gains significantly.

Image format conversion. Every image on the new site has been converted from JPEG and PNG to WebP. WebP consistently delivers substantially smaller file sizes at equivalent or better visual quality, meaning the same images reach the user's browser in a fraction of the bandwidth. For a site serving school and event photography, this reduction in image payload has a direct and meaningful impact on load time — particularly on mobile connections.

Font loading. The previous WordPress site was loading in excess of 40 font files per page, a side effect of the theme and plugin ecosystem each bundling their own typefaces. The new site loads a single additional font beyond the system stack. Fonts are render-blocking resources — the browser cannot display text until they arrive — so reducing from 40+ requests to one is a substantial improvement to perceived load speed and Core Web Vitals scores, particularly First Contentful Paint.

Together, these three changes — faster server response, smaller images, and dramatically reduced font loading — represent a comprehensive improvement to site performance at every layer of the stack. The follow-up Playwright test, to be run against the live production domain after launch, will capture the combined effect of all three in full browser load time and Core Web Vitals metrics.

It is worth noting that WordPress does offer caching and performance optimisation features that can close some of this gap — but like many such capabilities on the platform, they require deliberate configuration and are off by default. In practice, many WordPress sites never have them enabled. On primeCRM, caching and performance optimisations are on by default. The results in this report reflect that difference: the WordPress figures are representative of how the site has been running for its users, not a worst-case scenario.

If you are evaluating whether your current site is creating drag instead of supporting growth, get in touch. We build platforms designed to improve performance, visibility, and operational control together.

---

Appendix: Raw Run Data