Fifteen Platforms, One Standard: Every Rebuild Verified at 100/100/100/100
Over the past ten days, ZenMasterWorks took the default output of fifteen different website platforms — the big names in website builders, e-commerce, and content management — and rebuilt each one to a verified 100/100/100/100 mobile PageSpeed score: Performance, Accessibility, Best Practices, and SEO, all perfect, all on the throttled mobile test that most real sites fail.
None of these numbers are screenshots. Every platform below links to a live before/after benchmark you can re-run yourself in Google PageSpeed Insights right now. The "before" page reproduces the platform's documented default behavior; the "after" page delivers the same content and functionality rebuilt to our standard. Receipts, not vibes.
Here is every platform we optimized, in the order the benchmarks shipped, with the single biggest bottleneck each one's own documentation, support forums, or engineering teams acknowledge.
01WordPress Speed Optimization
The world's most-used CMS, and the most common failure pattern we see in audits: render-blocking Google Fonts with no font-display strategy, jQuery and plugin bundles loaded synchronously before first paint, uncompressed autoplaying hero video, and analytics dropped straight into the head instead of deferred. Every one of those is fixable without changing what the page says or does. See the WordPress before/after →
02Squarespace Performance Audit
Squarespace isn't inherently slow — but its default templates load commerce, forms, and page-transition JS bundles on every page whether that page uses them or not, plus a render-blocking Typekit font file before any content appears. The defaults, not the platform, drag the scores down. See the Squarespace before/after →
03Shopify Page Speed Optimization
Credit where due: Dawn is one of the stronger default themes in the industry. What drags real Shopify stores down is bolted-on apps — reviews widgets, upsell popups, live chat, loyalty badges — each shipping its own JavaScript and each degrading interaction responsiveness a little more. See the Shopify before/after →
04GoDaddy Website Builder Speed
GoDaddy's own engineering team has published real work raising Lighthouse scores across their platform. The pattern that still drags individual sites down is the one their own case study documents: popup modals, booking widgets, and social feed embeds, each adding weight most small business owners never asked for by name. See the GoDaddy before/after →
05Webflow Page Speed Optimization
Webflow generates clean, semantic code on a global CDN — solid infrastructure. The gap comes from how sites get built on top of it: heavy Webflow Interactions, autoplay background videos, multiple font weights loaded "just in case," and third-party scripts accumulated over time. See the Webflow before/after →
06Duda Page Speed Optimization
Duda performs better than most competing builders out of the box, by their own published numbers. Their own support documentation names what still hurts real sites: booking widgets, store elements, or map embeds placed above the fold, and custom header scripts loaded the wrong way. See the Duda before/after →
07Drupal Page Speed Optimization
Drupal's rendering pipeline and caching layer — BigPipe, dynamic page cache — can be genuinely fast. Real-world scores fall to configuration: aggregation left disabled between staging and production, and jQuery/jQuery UI loaded on pages that never touch them. See the Drupal before/after →
08WooCommerce Speed Optimization
Mostly one script: cart-fragments.js fires an AJAX request on every single page load — not just cart or checkout — just to keep the mini-cart badge in sync. Add the full Select2 library for a couple of dropdowns and WooCommerce core CSS shipped everywhere, and the waterfall tells the story. See the WooCommerce before/after →
09Wix Speed Optimization
Wix ships roughly 200–400KB of mandatory platform JavaScript on every site — flagged as "unused JavaScript" in PageSpeed audits, but required by the editor itself, so it can't be removed from inside Wix. Each App Market install adds its own scripts on top. See the Wix before/after →
10BigCommerce Speed Optimization
Almost never the hosting — it's stacked apps and theme configuration. Each installed app injects its script on every page regardless of need, and stores running eight or more apps are common. Stencil's Handlebars rendering adds overhead on top. See the BigCommerce before/after →
11Magento Speed Optimization
The default Luma frontend's JavaScript stack — RequireJS, KnockoutJS, jQuery — loads a long chain of small, unbundled modules before the page becomes interactive. Stores still running in developer mode instead of production mode, with Varnish Full Page Cache disabled, compound it. See the Magento before/after →
12PrestaShop Speed Optimization
Two things, mostly. CCC — Combine, Compress, and Cache — is disabled on a fresh install, so every module ships its own separate CSS and JS files. And most stores still run the Classic theme: Bootstrap 3 and jQuery-heavy, the default since PrestaShop 1.7. See the PrestaShop before/after →
13OpenCart Speed Optimization
The default theme's script chain — jQuery, Bootstrap, Owl Carousel, common.js — loads render-blocking in the head, none of it deferred. OpenCart also ships with no cache extension enabled, so every page rebuilds its queries on every request. See the OpenCart before/after →
14Salesforce Commerce Cloud Page Speed
SFRA — the Storefront Reference Architecture — was built to speed up front-end development, not page load. That's Salesforce's own positioning. It ships pre-built widgets and LINK-program third-party integrations that each add their own script, commonly loaded synchronously. See the Salesforce Commerce Cloud before/after →
15Square Online Speed Optimization
The newest benchmark, and a structural one: Square Online runs on the Weebly platform Square acquired in 2018, where the JavaScript that renders the page is the same JavaScript that powers the drag-and-drop editor. Square's own support team has confirmed merchants cannot remove that runtime JS — a performance floor no image compression can fix. There's a bonus structural SEO gap too: templates render page titles as an H2 instead of an H1, with no setting to change it. See the Square Online before/after →
What fifteen platforms taught us
Three lessons repeated across every single benchmark. First, platform defaults are built for the platform's convenience, not your visitor's connection — editor runtimes, app injections, and "just in case" bundles are the tax. Second, the fix is almost always subtraction, not addition: no plugin makes a page faster than not needing the plugin. Third, a perfect score is not a stunt — it's what's left when every default that doesn't serve the visitor is removed.
All fifteen live benchmarks, with both the before and after pages linked for each platform, are collected on The 100/100/100/100 Standard. Run any of them through PageSpeed Insights yourself — that's the whole point.