Every page on this site runs on the platform we sell — published from a CMS, cached at the edge

Measured, not asserted

Every number on this page came from the live site, not from a design document. Three of them are places the platform loses, and those are on the page too.

A teardown that only wins is a brochure

Measured 10 September 2026 on demo.pelasgia.io/en. Anyone can reproduce these figures with the commands at the bottom.

Agencies publish case studies. Platforms publish measurements. The difference matters when the person reading is the engineer your client will ask before signing, because that person has seen a hundred pages of adjectives and no numbers.

So this page is the whole picture: twelve delivery metrics, the mechanisms behind them, the operational figures a team lives with after launch, and the three things a serious review would flag. The gaps are named rather than buried, with what it takes to close each one.

What the browser actually got

Live measurements over a warm connection from a European edge location. The comparison column is the range a bespoke headless build typically lands in, not a measurement of any named competitor.
MetricMeasuredTypical enterprise buildVerdict
Time to first byte, warm edge96–121 ms200–600 msAhead
DOM content loaded319 ms1.2–3 sAhead
Total page transfer392 KB2–5 MBAhead
Requests to fully load2480–200Ahead
HTML on the wire13.7 KB of 67.8 KB60–200 KBAhead
Cumulative layout shift00.05–0.25Ahead
Lighthouse, desktop10070–95Ahead
Lighthouse, mobile9240–75Ahead
Total blocking time, mobile20 ms300–1200 msAhead
JavaScript transferred272 KB across 12 files600 KB – 2 MBAhead
ProtocolHTTP/2HTTP/2 or HTTP/3Level
Field data from real usersnone yet28-day Chrome UX reportBehind

Five mechanisms, not one tuning pass

Speed here is structural. None of it decays the moment someone adds a section.

  1. Four cache layers, addressed by tag

    The browser holds hashed assets for a year. The edge holds HTML for about sixty seconds. The application's own data cache holds rendered content for five minutes, keyed by content tag, backed by a shared store that survives deploys and is visible to every running copy. Publishing purges by tag, so one edit invalidates exactly the pages that changed.

  2. Layout space reserved before the image arrives

    Every image slot declares its aspect ratio, so the page never reflows when a picture loads. Fonts are self-hosted with a size-matched fallback, so text does not jump on swap. That is why layout shift measures zero rather than merely low, and why it stays zero on pages nobody tested.

  3. Fonts pushed with the document

    The fonts are self-hosted and served from the same domain as the page. Two files, 35 KB, each with a metric-matched fallback, so the text does not move when the real face swaps in. The logotype is not among them — it ships as outlines, so the brand mark never waits on a font. No third-party font host, no render-blocking request to someone else's infrastructure.

  4. Compression that actually applies

    The document leaves the edge at 13.7 KB and arrives as 67.8 KB of markup, an eighty percent reduction. Hashed assets carry a one-year immutable lifetime, so a returning visitor re-downloads nothing but the page itself.

  5. Animation that never touches the main thread

    Scroll effects compile to compositor-driven timelines rather than JavaScript running every frame, and sections that animate release their memory once off screen. An independent audit graded every animation on the page at its top tier, which is why blocking time on a throttled phone is twenty milliseconds.

The metrics a team lives with after launch

Contracted figures come from the platform's integration documents and its post-deploy verification suite. The publish pair has not yet been timed end to end on this site, and is marked as contracted rather than measured.
MetricThis platformTypical enterprise buildVerdict
Edit to fresh at the origin~1 s, contractedRebuild, 2–20 minAhead
Edit to fresh worldwide5–30 s, contractedMinutes to a nightly rebuildAhead
Lost webhook self-heal5 min or lessManual purgeAhead
Catalogue change reaching the pageSeconds with webhooksSeconds to hoursLevel
Same, webhooks off250 s measuredLevel
Wiring a store to the platform~30 minDaysAhead
New tenant infrastructure~2 hWeeksAhead
Brief to live2–6 weeks2–10 monthsAhead
RollbackOne command, nothing to un-migrateOften a database migrationAhead
Automated tests in the deploy gate158 unit, 12 browserVariesLevel
Failure domainCluster and database sharedDedicated per clientBehind

Three things a serious review would flag

Security response headers are missing. Checked live: strict transport security, content type options, frame options, referrer policy, content security policy and permissions policy are all absent, and the response names the framework. Nothing is exploitable on a marketing site, but it reads as an unfinished hardening pass, and in procurement that costs more than the risk. It is roughly half a day to close.

No real-user performance data yet. Every speed figure here is a lab run or a synthetic request. Chrome publishes field data once a site has twenty-eight days of qualifying traffic. Until then the honest phrasing is lab, on this date, and that is how the numbers are labelled.

Tenants share a cluster and a database instance. Each client gets its own content system, database schema, media storage and credentials. The cluster, the database instance and the build pipeline underneath are shared, so an outage there reaches everyone at once. This is disclosed in the data processing agreement rather than discovered later.

What engineers ask

Is this a static site generator?
No. Pages render on demand and are cached at four levels, so content changes appear in seconds without a rebuild. A static generator has to rebuild and redeploy for every edit, which is why publishing on those stacks is measured in minutes.
What happens when the content system is down?
The edge keeps serving the last good version and the shared cache fails open, degrading to in-memory caching rather than to an error page. The site has also been verified rendering from a content export with the content system deliberately unreachable.
Can we host it ourselves?
Yes. The same container image runs on a plain container host or your own cluster. The two cloud-specific layers are switched on by environment variable and their absence degrades to portable tag-based caching. A source licence for your storefront is available.
How do you know the animation is not costing us performance?
It is audited. Scroll-linked values compile to compositor timelines, and the audit reports every animation on the page at its top tier with total blocking time of twenty milliseconds on a throttled phone.

Check the numbers yourself

Time to first byte, edge behaviour and the full caching contract are all reproducible from a terminal. Ask and we will walk your engineer through the run on a call.

Talk to us