We’re serious about this. Site speed isn’t something we bolt on at the end of a build. It shapes every decision we make, from which hosting platform we use to which image format we save files in.

This post walks through exactly how we approach it and why every choice we make has a reason behind it.

Most caching plugins are written to work across every hosting environment, which means they’re not perfectly suited to any of them. SG Optimizer is different. It’s built by SiteGround, for SiteGround, and it integrates directly with their server-level infrastructure in a way that third-party plugins simply can’t.

Here’s what we actually configure with it on every build.

Caching
Server-level dynamic caching means repeat visitors get a pre-built version of your pages served to them almost instantly, rather than WordPress spinning up a fresh version each time. For content-heavy sites, this alone makes a noticeable difference.

We layer browser caching on top of that. Once someone has visited your site, their browser holds onto certain assets locally. When they come back, those files load from their own device rather than your server.

Minification and File Combination
CSS, JavaScript and HTML files are full of whitespace, comments and formatting that browsers don’t need. SG Optimizer strips all of that out automatically. We also combine files where it makes sense, reducing the number of separate requests a browser has to make before the page can finish loading.

Database Optimisation
WordPress databases collect a lot of junk over time. Old post revisions, spam comments sitting in a queue, expired transient data. SG Optimizer keeps that cleaned up, which keeps database queries fast.

Lazy Loading
Images below the visible area of the screen don’t need to load before someone scrolls to them. With lazy loading enabled, they don’t. The browser prioritises what’s actually in front of the visitor and loads the rest as they scroll. Less initial weight, faster first impression.

You can do everything else right and still have a slow website if your hosting is poor. The server response time is the starting gun. If it’s slow, everything downstream is slower.

We build on SiteGround. We’ve tried others and we keep coming back. SiteGround runs on Google Cloud infrastructure, which means genuinely fast server response times and a solid global network of data centres. Your visitors in Manchester and your visitors in Melbourne both get a fast experience, not just the ones sitting near the server.

A few things that make SiteGround a strong foundation:

• Ultrafast PHP that processes requests significantly faster than standard PHP setups
• A built-in CDN that serves your assets from a location closer to whoever’s browsing
• HTTP/2 support, which lets multiple files load at the same time rather than queuing up like a very dull queue
• Staging environments so we can test changes without touching your live site

The hosting decision is one of the most important ones in a web build. It just doesn’t look very exciting in a proposal, so a lot of agencies skip past it. We don’t.

Avada is one of the most widely used WordPress themes in the world. That’s partly because it can do a lot. The risk with that kind of flexibility is that people use all of it, and end up with sites that load like a PowerPoint presentation from 2009.

We build on Avada because we know it well and we know how to keep it fast.

We configure performance settings before the first page is designed

Avada’s Fusion Builder comes with a proper set of performance controls. We get into those at the start of every project, not as a final tidy-up job. That means:

• Disabling scripts and styles on pages that don’t use the features they belong to
• Turning off Avada elements that aren’t part of the design (unnecessary icon font libraries, unused slider scripts, layout features that aren’t in play)
• Enabling built-in lazy loading for images and iframes
• Configuring critical CSS so above-the-fold content renders as fast as possible

Every component in Fusion Builder has a purpose. We don’t stack wrappers unnecessarily. We use Global Elements to reuse what can be reused rather than duplicating code across every page. We don’t add animation libraries or third-party scripts unless there’s a genuine reason for them to be there.

Sites built this way don’t just perform well when they launch. They keep performing well as the site grows.

Images are usually the biggest contributor to page weight, and a lot of websites are still serving JPEGs that are three times larger than they need to be.

We deliver all photographic images in WebP as standard. It’s a format developed by Google that produces files roughly 25% to 35% smaller than JPEG at comparable quality. For images with transparency, the saving over PNG can be even greater.

Every major browser supports WebP now, including Safari from version 14 onwards. There’s no longer a good reason not to use it.

Our image process on every project:

1. Start with the highest quality source file available
2. Resize to the actual display dimensions before upload (uploading a 4,000px image for a 1,200px container is a very common and very avoidable mistake)
   Compress and convert to WebP
3. Upload with descriptive, keyword-relevant file names and proper alt text

That last point matters for SEO too, not just performance.

Anything that isn’t a photograph should almost certainly be an SVG. Logos, icons, decorative shapes, dividers, UI graphics. All of it.

SVG files are vector-based, which means they’re mathematically drawn rather than pixel-based. They look crisp on every screen regardless of resolution, and you only need one file version rather than separate assets for different display densities.

The file size difference is real. A logo that weighs 40KB as a PNG can often sit below 5KB as an SVG. Multiply that across a full set of icons and it adds up.

We use SVGs for logos, brand marks, icons, UI elements, and any decorative graphic work across the site. Where animation is needed, SVGs can be animated with CSS or JavaScript without adding any extra file weight.

Font loading is one of the most overlooked performance costs in web design. Each font weight is its own file request. Load Regular, Medium, Bold, Italic, Bold Italic and Light across two typefaces and that’s twelve separate requests before the page can render text correctly.

Most sites don’t need that many weights. Most designs don’t either.

Our approach on every project:

• Two typefaces maximum wherever the design allows for it
• Only the weights we’re actually using, usually Regular and Bold
• font-display: swap so text stays visible while fonts load rather than disappearing while the browser waits
• Self-hosted fonts where possible to remove the external DNS lookup that comes with Google Fonts or Adobe Fonts
• Subsetting fonts where the design only uses a limited character range

Getting this right shaves real time off your load speed. It’s also one of those things that’s easy to get lazy about, which is why we keep a close eye on it.

A few more things that don’t need their own section but are worth knowing about.

Preloading critical assets. We identify the assets the browser needs to render what’s visible above the fold and tell it to fetch those early using rel=”preload”. The hero image and main font file are the usual priorities.

Keeping third-party scripts in check. Analytics tools, chat widgets, marketing pixels, social embeds. Each one adds load time, and together they can quietly wreck a PageSpeed score. We audit everything at the start of a project and only load what’s genuinely earning its place. Scripts that can be deferred or loaded asynchronously are.

Clean, semantic HTML. Good markup is faster for browsers to parse and easier for search engines to understand. We write it properly throughout, with the right heading structure, correct alt text, and clean output from Avada’s builder rather than layers of inline style overrides.

Core Web Vitals. Google uses these metrics directly in search rankings, so we track them throughout every build rather than checking them at the end. We target Largest Contentful Paint under 2.5 seconds, keep Interaction to Next Paint low by keeping JavaScript light and deferred, and set explicit image and embed dimensions to prevent layout shift as the page loads.

Site speed has been a Google ranking factor since 2010 for desktop. Since 2018 for mobile. Core Web Vitals became part of the ranking algorithm in 2021. This isn’t new information, but a lot of websites still haven’t caught up.

A fast site means better search visibility, lower bounce rates, and higher conversion rates. Research from Portent found that a site loading in one second converts three times better than one that takes five. That’s not a marginal improvement.

Performance and SEO are the same conversation. We treat them that way from day one.

This one doesn’t come up enough. Every time someone loads a web page, data is transferred across servers, networks and devices. That transfer uses energy. The heavier the page, the more energy it consumes, and the more carbon is produced as a result.

The average web page is now over 2MB. Multiply that by the billions of page loads happening every day and the environmental cost of a bloated web adds up quickly.

Building lean websites isn’t just good for your users and your search rankings. It’s genuinely better for the planet. Smaller files, fewer requests, efficient caching and optimised assets all mean less data moving around, which means less energy consumed per visit.

It’s not the reason we build the way we do, but it’s a benefit we’re glad to stand behind. A fast website and a responsible one aren’t in conflict. They’re the same thing.

Performance planning happens alongside the creative, not after it. We set a performance target before we start designing, configure the hosting and plugin environment early, and run tests throughout the build using Google PageSpeed Insights, GTmetrix and Chrome DevTools.

By the time a site goes live, speed is already built in. We’re not running around trying to fix things at the last minute because we left it too late.