We ran an internal exercise this winter. The brief was simple: rebuild a small marketing site on WordPress with a hard 200 kilobyte initial transfer budget, gzip included, before any third-party scripts.
The exercise was not academic. A client in Southeast Asia had asked us to pitch on a country-wide rollout where the median connection speed was under one megabit per second on a good day. Their existing WordPress site loaded in fourteen seconds on a real device. Two-thirds of the visitors bounced before the hero image appeared.
Budgeting forced a conversation we should be having on every project.
What 200KB actually covers
The budget had to cover everything the browser parsed before the page was usable. HTML, CSS, the WordPress emoji script, jQuery, theme JavaScript, fonts, and the inline scripts that themes love to print into the head. Images counted toward LCP but not toward the initial budget — we capped the hero separately at 90 kilobytes.
For comparison, a freshly installed WordPress site running the Twenty Seventeen theme with no plugins loaded ships roughly 400 kilobytes before any content. The default emoji script, jQuery and jQuery Migrate, the wp-embed shim, and the comment-reply script account for about a third of that on a page that does not use any of them.
What we cut
The first audit dropped the page weight by forty percent without touching the design.
- Emoji script — dequeued via remove_action on wp_print_styles and wp_head. The site does not need automatic emoji substitution on a marketing page about logistics.
- jQuery Migrate — dropped from the front end. The theme JavaScript was already using modern jQuery 3 syntax.
- wp-embed — removed. The site has no embedded oEmbed content.
- Comment-reply — dequeued on every template except the blog. The home page does not need a threaded-comments fallback script.
- Block library CSS — wp-block-library is enqueued by default on every page since 5.0. Sites that do not use blocks ship that stylesheet anyway. We removed it conditionally.
None of these are sophisticated optimizations. They are all one-line dequeues in functions.php. They are still on by default on every fresh WordPress install in 2018, and they still account for the first hundred kilobytes of wasted weight on the majority of sites we audit.
Where the real work was
The next sixty percent of budget came from the theme itself.
The starting CSS was a single monolithic stylesheet of eighty kilobytes. We split it into critical CSS — the rules that paint the above-the-fold content — and a deferred load for everything below the fold. Critical CSS came down to seven kilobytes inlined into the head. Everything else loaded asynchronously via a small loadCSS polyfill.
JavaScript got the same treatment. The original theme bundle was thirty-six kilobytes of mixed concerns — slideshow, mobile nav, form validation, smooth scroll. We split it into a four-kilobyte critical bundle that handled the mobile nav and dropped a script tag for the slideshow only on pages that had one. The smooth scroll fell out entirely. CSS scroll-behaviour does the same thing in two lines.
Fonts cost us the most negotiation. The brand spec called for two custom Google fonts, four weights each. The naive load was 240 kilobytes of font payload. We dropped to one font, two weights, subset to Latin, served as woff2 with a preconnect to the Google Fonts CDN. The result was twenty-eight kilobytes.
What we did not cut
We did not gut the design. The hero image still loaded, the navigation still animated, the contact form still validated client-side. The site looked like the comp. It just loaded eight times faster.
We also did not remove the analytics or the Facebook Pixel. Those are third-party scripts and they sat outside the 200 kilobyte budget by design. They went into a deferred load after onload so they did not block the initial paint, but they were still part of the production site.
The final number
The home page shipped at 184 kilobytes gzipped before third-party scripts. The largest contentful paint on the test device — a Moto G4 on a throttled 3G connection — landed at 2.1 seconds. The bounce rate on the rebuilt site dropped from sixty-three percent to twenty-eight percent in the first three months.
The budgets we use now
The Southeast Asia project changed how we quote performance on every WordPress build. Every project now ships with a budget line in the spec.
- Marketing page initial transfer: 200KB gzipped
- Hero image: 90KB
- LCP target on 3G: under 2.5 seconds
- Total JavaScript on initial load: under 50KB minified and gzipped
Hitting those numbers is not free. It adds roughly fifteen percent to the front-end build time, in our experience. But every project that has shipped against them in the last twelve months has cleared a Lighthouse performance score of 90 on mobile at launch.
The harder part is keeping the budget alive after launch. A new plugin, a marketing pixel, an A/B test script — each one is a few kilobytes that nobody questions because it is ‘just one thing.’ By month nine the budget is gone and the site is back to fourteen seconds. The budget has to live in the team’s process, not just the launch checklist. We bake performance audits into every retainer for exactly this reason.