Most agencies will happily quote you for a website redesign and never mention the speed of the site they currently run. That’s a tell. If a web design agency hasn’t bothered making their own site fast, the optimisation services they sell are theoretical at best.
The previous version of keentodesign.com.au was respectable but not exceptional. It looked good, converted reasonably well, and lived in the same uncomfortable middle ground we kept finding on client audits: technically functional, visually decent, and quietly bleeding performance. The Core Web Vitals report was failing. PageSpeed scores hovered in the mid-60s on mobile. Load times were the kind of numbers you don’t actively notice but that compound into worse engagement metrics over months.
So we redesigned the site, and made WordPress speed optimisation the actual brief rather than an afterthought. The result was a 90+ PageSpeed score on every inner page, Core Web Vitals moving from FAIL to PASS, and load times cut in half. This is what we did, what worked, what didn’t, and what we’d tell anyone running a Sydney business currently sitting on a slow WordPress site.
What we started with
Before getting into the work, the honest baseline matters. The old site wasn’t a disaster. It was a typical mid-2010s WordPress build that had accumulated the usual sediment: a custom theme built on a Bootstrap CSS foundation, with features we never used, a stack of plugins that had felt necessary at install but were doing more work than the site needed, image sizes inherited from a content workflow that uploaded straight from Lightroom exports, and a hosting plan we’d outgrown but never reviewed.
The numbers told the story. Mobile PageSpeed scores sat between 58 and 71 depending on the page. Largest Contentful Paint averaged 4.2 seconds on the homepage. The site cleared a respectable Time to First Byte but bled the gains on render-blocking JavaScript. Cumulative Layout Shift was the worst metric of all because we had a hero slider that loaded its dimensions late, causing a noticeable jump as content settled.
This wasn’t a unique situation. We see almost identical patterns when auditing client sites across Surry Hills, Parramatta, and the inner west. The diagnosis is rarely a single catastrophic problem. It’s the cumulative weight of decisions made years ago by people who weren’t measuring performance.
Why we rebuilt rather than optimised
When a slow site comes across our desk, the first call is always the same: optimise or rebuild? The answer depends on whether the foundation is salvageable.
For our own site, we ran the calculation honestly. Optimisation work could probably have lifted the existing build from 65 to maybe 82 on PageSpeed. That would’ve taken roughly 30 hours of careful work, half of which would’ve gone into untangling plugin dependencies and theme overrides we hadn’t written. A rebuild on a leaner foundation, by contrast, would land us in the 90s with cleaner code we could maintain, and would take about 50 hours.
The 20-hour gap was worth it. Optimisation work on a poorly architected site has a ceiling. You can’t get to 95+ on PageSpeed when your theme ships 800KB of CSS for a feature set you only use 10% of. With proper planning and experienced developers working from the ground up, hitting 99+ is genuinely achievable. The catch is that “from the ground up” is doing a lot of work in that sentence. Optimising an existing poorly-built site to 99+ rarely happens. Building a new site to that standard, with the right decisions made early, is a different proposition entirely.
This is the test we now apply to client projects. If hitting the performance target requires removing a feature the business actually uses, the foundation is wrong and optimisation alone won’t get there. If the only blockers are caching, image weight, and a few render-blocking scripts, optimisation is the right call.
How we approached the rebuild
The principle that drove every decision was only ship what the page actually needs. This sounds obvious. In practice, modern WordPress development violates it constantly. Page builders ship their full library on every page. Themes load CSS for components a particular page doesn’t use. Plugins enqueue scripts globally when they’re only needed in one place.
The rebuild followed a few non-negotiable rules:
- No multipurpose themes. The new site uses a custom-coded theme built specifically for this content, using plain CSS only, with no framework underneath, not a Swiss Army knife rented from ThemeForest.
- No page builders. The visual editing convenience wasn’t worth the performance cost. The team writes templates in PHP and works in the block editor where appropriate.
- One job per script. Every JavaScript file on the site has a defined purpose and is loaded only where that purpose applies.
- Privacy-respecting analytics. We replaced the standard Google Analytics + Tag Manager combination with Plausible Analytics, which loads a single 1KB script versus the 45KB+ of GA4 plus GTM.
- jQuery only where it earns its place. Loaded on the contact page where the form needs it, and on the small handful of pages where a slider component depends on it. Everywhere else, vanilla JavaScript.
These rules had real costs. We gave up some development convenience. We gave up some plugin compatibility. We had to write more code ourselves rather than installing it. The trade was simple though: every gram of weight we accepted had to justify itself in terms a visitor would actually feel.
The technical decisions that mattered most
Custom theme over commercial themes
Most performance wins live in the theme layer. A typical commercial WordPress theme like Divi or Avada ships somewhere between 400KB and 1.2MB of compiled CSS, plus several hundred KB of JavaScript, before a single piece of your content loads. The theme assumes you might use any of its hundreds of features, so it ships them all.
A purpose-built theme ships only what the site uses. Our final CSS bundle came in under 40KB minified and gzipped. The JavaScript bundle, excluding the conditionally-loaded jQuery for forms and sliders, is around 8KB. By the time a browser is parsing markup, it’s working with a small fraction of the asset weight a typical commercial theme would have already cost.
For agencies and developers, this is an obvious win. For business owners running their own WordPress site, the practical translation is: choose lightweight, performance-focused themes over feature-heavy multipurpose options. They won’t be quite as light as a custom build, but they’re an order of magnitude better than what most sites ship with.
Plausible Analytics instead of Google Analytics
The default analytics stack on WordPress sites is Google Analytics, usually loaded via Google Tag Manager. The combined script weight runs to 45KB+ on the wire, plus the third-party network calls each script makes once it executes. On a slow connection, this stack alone can add 600-900ms to page load.
Plausible runs at around 1KB. That’s not a typo. The script is small enough that its network weight is essentially noise. We accepted some functionality trade-offs (no goal funnels as sophisticated as GA4, fewer custom event types) in exchange for a measurable speed gain on every single page load. For a Sydney business focused on conversion and basic traffic patterns, the trade is worth it. For an enterprise SaaS with multi-touch attribution requirements, it probably isn’t.
For businesses that genuinely need Google Analytics and can’t justify the switch, there’s a middle option worth knowing about: hosting the GA script locally instead of pulling it from Google’s servers on every page load. Plugins like CAOS (Complete Analytics Optimization Suite) and Perfmatters can fetch the analytics script, store it on your own server, and keep it updated automatically. This eliminates the third-party DNS lookup and TLS negotiation that adds latency to every visit, and it allows the script to be cached by your CDN alongside the rest of your static assets. The performance gain isn’t as dramatic as switching to Plausible outright, but it’s a meaningful improvement for sites that need GA4 specifically.
Conditional jQuery loading
WordPress ships with jQuery enabled by default because thousands of themes and plugins still depend on it. The library itself is around 30KB minified and gzipped, and many sites load it on every page even though only one or two scripts actually use it.
Our approach was to disable jQuery globally and only load it on pages that genuinely need it. The contact page loads it because the form depends on it. A handful of pages with slider components load it for the same reason. The rest of the site, which is most of it, runs on vanilla JavaScript and never pays the jQuery weight at all.
WordPress makes this surprisingly easy with the wp_enqueue_script function and conditional tags like is_page() and is_singular(). The work is in being disciplined about it. Every script registered globally is a script that runs everywhere, and the cumulative cost of “this is small enough not to worry about” decisions is what kills most sites.
The risk worth flagging: many WordPress plugins assume jQuery is available globally and will break if it isn’t. The reason this works for us is that we control every plugin choice and theme decision. For a typical business site running 20+ plugins, dropping jQuery globally is likely to break something. Test thoroughly on staging.
Here is the exact function we added to our custom theme’s functions.php file to handle this. It safely strips jQuery across the site while whitelisting the homepage and contact page:
<?php
/**
* Conditionally dequeue jQuery to improve site speed.
*/
function ktd_optimise_jquery() {
if ( ! is_admin() ) {
// Only load jQuery on the contact page and homepage
if ( is_page( 'contact-us' ) || is_front_page() ) {
return;
}
// Remove jQuery everywhere else
wp_deregister_script( 'jquery' );
wp_dequeue_script( 'jquery' );
}
}
add_action( 'wp_enqueue_scripts', 'ktd_optimise_jquery', 100 );Image strategy with Cloudflare Images
Images are usually the biggest single payload on a WordPress page, and the rebuild treated them accordingly. The headline change was moving image delivery to Cloudflare Images, which handles four jobs that would otherwise require separate solutions:
- Automatic format conversion. Cloudflare serves WebP or AVIF based on what the requesting browser supports, with no manual conversion step at upload time.
- On-the-fly resizing. Different viewport sizes get appropriately sized image variants without WordPress generating and storing dozens of file copies in the media library.
- Edge delivery. Images are served from Cloudflare’s network, which means a Sydney visitor gets the file from a Sydney edge node rather than fetching it from origin.
- Storage offload. The original images live on Cloudflare rather than ballooning the WordPress uploads directory and the database that indexes it.
For sites that don’t want to commit to a paid image service, the alternatives are local WebP conversion via plugins like ShortPixel or Imagify, combined with WordPress’s native lazy loading and responsive srcset attributes. The result is similar; the workflow is more manual and the storage stays on the origin server.
The lazy loading discipline matters either way. Every image below the fold uses native loading=”lazy”, which is now broadly supported across browsers. On long pages with many images, this is the difference between a 4MB initial page weight and an 800KB initial page weight.
As an extension of this setup, Cloudflare R2 storage can also be utilised to offload your entire media library. Instead of letting gigabytes of legacy image files sit on your web host, which bloats your server, slows down site backups, and drags down response times, R2 acts as a zero-egress fee object storage bucket. By streaming your uploads directory straight to R2, your core WordPress installation stays incredibly lean, and files load instantly from Cloudflare’s global network without ever touching or taxing your origin server.
The 3.4KB slider
We wanted a hero slider on the homepage. The standard options are Slick (about 30KB plus jQuery), Swiper (about 130KB), and various WordPress slider plugins ranging from 80KB to 400KB once their dependencies load.
We built a custom slider in vanilla JavaScript that came in at 3.4KB. It does fewer things than Swiper (no advanced effects, no complex transitions) but it does the things our site actually needs, and at a fraction of the weight. This pattern, building the minimal version of what you need rather than installing the kitchen-sink version someone else built, recurred throughout the rebuild. It takes more developer time. It’s the difference between a 90+ PageSpeed score and a 70.
Caching: Cloudflare APO instead of WP Rocket
This was probably the single most pragmatic decision in the rebuild, and it goes against the grain of most WordPress speed advice you’ll read.
The standard recommendation is to install a caching plugin like WP Rocket and configure it carefully. We’ve used WP Rocket extensively on client sites and it’s a strong product. The honest problem with it is configuration time. Getting WP Rocket dialled in for a specific site involves testing each setting, identifying which optimisations break which features, building exclusion lists for problem scripts, and coming back periodically to fix things when plugin updates change the JavaScript landscape. On a complex site, this can run to 8-15 hours of setup and ongoing maintenance.
Cloudflare APO (Automatic Platform Optimisation) takes a different approach. It caches the full HTML response at Cloudflare’s edge, which means visitors get the cached page from the nearest Cloudflare datacenter without ever hitting the origin server for cache hits. Combined with server-level caching at the host, this delivers most of the wins WP Rocket targets without the per-site configuration burden.
The trade-off is real. WP Rocket gives you fine-grained control over CSS minification, JavaScript deferral, critical CSS generation, and database optimisation. APO is more opinionated and less configurable. For our own site, where we control the codebase and could make speed-conscious decisions at the source rather than papering over problems with caching configuration, APO was the better fit. The page is already lean, so we don’t need a plugin to fix it after the fact.
For most agency clients, the calculation goes the other way. WP Rocket is usually the right answer because the underlying site has too many things that need fixing at the caching layer. APO becomes attractive when the site is built well from the start and you want infrastructure caching that “just works.”
Server-level caching does most of the heavy lifting either way. Page caching at the server, object caching with Redis, and edge caching via Cloudflare collectively mean that most page views never run PHP or query the database at all. The visitor gets a static HTML response from cache, generated once and served thousands of times. This is where the bulk of the time savings come from, and it’s available on most decent managed hosts without additional configuration work.
What the numbers actually look like now
The bullet points are concrete: 90+ PageSpeed on every inner page, Core Web Vitals moved from FAIL to PASS, load times cut by approximately 50%.
A few details behind those numbers worth flagging:
The 90+ figure is the mobile score, which is the harder of the two and the one Google uses for ranking. Desktop scores sit higher across the board, generally between 96 and 100. The variation page-to-page on mobile depends on the specific image weight and content; the homepage with its hero imagery scores slightly lower than a standard service page.
The Core Web Vitals pass is based on field data from real Chrome users over a 28-day window, not lab data from a single test. This distinction matters because lab scores can be gamed and field scores can’t. A site that scores 95 in lab tests but has a 4-second median LCP from real users is failing where it counts.
The 50% load time reduction is measured against the previous site at equivalent network conditions. On a Sydney 4G connection, the homepage went from roughly 4.2 seconds to fully interactive down to about 2.0 seconds. On desktop fibre, it’s gone from around 1.8 seconds to under 0.9 seconds. The relative improvement is consistent across connection types.
What we’d do differently
A case study without honest reflection on what didn’t work is marketing copy, not journalism. A few things we’d revisit:
We probably over-engineered the custom slider. The 3.4KB result is satisfying, but the 12-15 hours of development time it cost would’ve been hard to justify on a client project. For a paying client, we’d likely use Swiper’s slim build (around 30KB) and accept the trade. The internal value of the custom solution is that it taught us things we now apply to client work, but a 30KB difference on one page is not normally worth a fortnight of development time.
We were too aggressive with jQuery removal in the first build. The initial version stripped jQuery globally before we’d properly mapped which components actually needed it, which created a few days of debugging when sliders and the contact form didn’t behave as expected. The current setup, with jQuery loaded only on the specific pages where forms or jQuery-dependent sliders live, is more sustainable than the all-or-nothing approach.
The Plausible Analytics decision was right but we underestimated the reporting workflow change. Team members used to GA4’s interface needed onboarding to a different tool with different conventions. Worth doing, but worth budgeting for the transition cost.
Speed optimisation is ongoing, not a one-time project
The framing that gets most businesses in trouble is treating speed optimisation as a checklist they’ll complete once and never revisit. It isn’t. A site that hits 95 on PageSpeed today can drop to 78 within six months without anyone making a single deliberate change.
The reasons are unglamorous. A new plugin gets installed for a marketing campaign and never removed. The content team starts uploading larger images because the photographer’s outputs got bigger. WordPress updates a few times and the JavaScript landscape shifts under your caching configuration. A developer adds a new tracking pixel for a vendor without considering that it loads its own SDK on every page. Six months of these small accretions compound into a site that’s measurably slower than the one you launched.
The maintenance discipline that actually works looks something like this: monthly PageSpeed checks on the homepage and your top three commercial pages, quarterly plugin audits to remove anything that’s stopped earning its weight, six-monthly reviews of the caching and CDN configuration, and an annual review of the underlying tech stack. None of this is glamorous and none of it shows up as a campaign deliverable, but it’s what separates sites that stay fast from sites that quietly degrade.
For most Sydney businesses, the honest answer is that speed optimisation needs a budget line, not a one-off project quote. The work involves real time and real attention, and the investment compounds in the same direction as the entropy: a site that gets monthly attention stays fast and the attention required gets smaller over time. A site that gets ignored gets slower and the eventual fix gets more expensive.
What this means for a Sydney business with a slow site
The honest answer is that most of what we did is achievable on client projects, with caveats. The rebuild approach makes sense when the existing site has architectural problems that optimisation can’t fix. The optimisation approach makes sense when the foundation is solid.
The decisions that translate most directly to client work:
- Move to a lightweight theme. This single change typically lifts mobile PageSpeed by 15-25 points on a typical small business site.
- Audit the plugin list ruthlessly. Every plugin should be earning its weight. The Query Monitor plugin is the right tool to identify which ones are actually expensive.
- Replace heavyweight analytics with Plausible or a similar lightweight option. If GA4 is non-negotiable, host the script locally with a plugin like CAOS rather than pulling it from Google’s servers on every visit.
- Use Cloudflare Images or a comparable service for image delivery, with lazy loading on every image below the fold.
- Get the hosting and edge caching right. Server-level page caching combined with Cloudflare APO covers the majority of caching wins with very little configuration time, especially on well-built sites.
The decisions that require more thought:
- Custom theme development is expensive but yields the biggest gains. Whether it’s worth the spend depends on the site’s commercial value. For an eCommerce store doing six figures a month, absolutely. For a four-page brochure site, probably not.
- Conditional jQuery loading is a power-user move. It works on tightly controlled sites and breaks on plugin-heavy ones. Test extensively before committing.
- APO versus WP Rocket isn’t a universal answer. APO suits well-built sites that don’t need extensive caching-layer fixes. WP Rocket suits sites that need fine-grained caching control to compensate for underlying issues.
The point of all this
A fast site isn’t a vanity metric. It’s the foundation underneath every other digital marketing investment. SEO efforts perform better when Core Web Vitals pass. Google Ads campaigns convert at higher rates when landing pages load quickly. Email marketing pulls higher click-through-to-conversion rates when the destination doesn’t make subscribers wait. Every dollar spent driving traffic to a slow site is partially wasted on visitors who leave before the page settles.
We rebuilt our own site partly because we’d been recommending these changes to clients for years and had a credibility problem until our own site reflected the advice. The rebuild took about three months of part-time work and the results have been measurable in lead quality, time-on-site, and the kinds of conversations we now have with prospects who arrived via Google rather than referral.
If your WordPress site is currently sitting on mid-60s PageSpeed scores and failing Core Web Vitals, the work to fix it isn’t mysterious. It’s a series of small, disciplined decisions about what your site actually needs to do, and what it can stop carrying. With proper planning and developers who know what they’re doing, hitting 99+ on a new build is achievable. Hitting 90+ on a redesigned existing site is well within reach for most. The agencies worth hiring are the ones who’ve done this work on their own sites first, and the ones who’ll keep doing the maintenance work after launch rather than treating speed as a problem they solved once.
