When we recently rebuilt orionesque.com on EE7, hitting a perfect desktop PageSpeed score wasn't the goal — but it became a useful forcing function for doing things properly. This post covers the specific changes that moved the needle, roughly in the order we tackled them.
None of this is EE-specific magic. But EE sites have their own particular failure modes - add-on bloat, unoptimised template output, and a tendency to lean on third-party resources that quietly destroy your LCP. This is what we found, and how we fixed it.
Start with a baseline — and read the report properly
Before touching anything, run your page through PageSpeed Insights and spend ten minutes actually reading the diagnostics rather than just looking at the score. The opportunities and diagnostics sections are where the actionable information lives. The score itself is almost meaningless without context.
Our starting point on desktop was solid - mid-80s. Mobile was the problem: LCP was sitting above 3 seconds, dragging everything down. Two culprits were immediately obvious: a Google Fonts <link> in the <head>, and unoptimised images.
1. Eliminate the Google Fonts round-trip
This is the single biggest quick win on most EE sites. If you're loading fonts from fonts.googleapis.com, you're adding a DNS lookup, a TLS handshake, and a render-blocking request before your page can paint anything.
The fix is to self-host your woff2 files. We use IBM Plex Serif and IBM Plex Mono on orionesque.com. The process:
- Use google-webfonts-helper to download the exact weights and subsets you need as woff2 files
- Upload them to your EE theme folder (e.g.
/themes/user/yoursite/fonts/) - Replace the Google Fonts
<link>in your{layout:set name="head"}with a@font-faceblock pointing to your own files - Add
font-display: swapso text remains visible while fonts load
@font-face {
font-family: 'IBM Plex Serif';
font-style: normal;
font-weight: 300;
font-display: swap;
src: url('../fonts/ibm-plex-serif-300.woff2') format('woff2');
}On its own, this dropped our mobile LCP by around 600ms.
2. Preload your LCP resource
PageSpeed will tell you what your LCP element is. On a text-heavy site like ours it's usually the largest above-the-fold text block - which means it's your heading font. Once you've self-hosted it, tell the browser to fetch it early with a <link rel="preload"> in your <head>:
<link rel="preload" href="/themes/user/orionesque/fonts/ibm-plex-serif-300.woff2"
as="font" type="font/woff2" crossorigin>The crossorigin attribute is required even for same-origin fonts - leave it out and the browser fetches the font twice.
3. Image optimisation and lazy loading
Any images on the page should be:
- WebP format - convert JPGs and PNGs at build time or on upload. Smaller files, same visual quality.
- Explicitly sized - always set
widthandheightattributes to prevent layout shift (CLS) - Lazy loaded below the fold - add
loading="lazy"to any image that isn't in the initial viewport - Eager loaded above the fold - your hero image should have
loading="eager"and ideallyfetchpriority="high"
In EE templates this typically means adding these attributes in your channel entries loop wherever you output image fields. If you're using a file field, you can pull width and height from EE's file metadata directly.
4. Minimise render-blocking resources
Check your <head> for anything that blocks rendering:
- CSS - your main stylesheet should be in
<head>and as lean as possible. Remove unused rules. If you have page-specific styles, consider inlining critical CSS for above-the-fold content. - JavaScript - everything that isn't critical should have
deferorasync. If you're using jQuery-dependent add-ons, check whether you actually need jQuery on that page at all. On orionesque.com we ship zero JavaScript dependencies — everything is vanilla. - Third-party scripts - analytics, chat widgets, and cookie scripts all have a cost. Load them after the page has painted using
defer, or trigger them on first user interaction.
5. Server response time (TTFB)
If your TTFB is above 200ms, no amount of frontend optimisation will get you to 100. EE's template engine adds overhead — especially if you're running lots of channel entries tags or un-cached queries.
Things that help regardless of your hosting environment:
- Enable EE's template caching for pages that don't change on every request. Static pages — homepage, about, services — are ideal candidates. Configure it per-template in the EE control panel under Templates → Edit → Caching.
- Enable PHP OPcache - OPcache is bundled with PHP and should be active on any production server. Worth verifying in your
phpinfo()output if you're not sure. - Review your MySQL configuration - default MySQL settings are often tuned for servers with more RAM than shared or entry-level hosting provides.
innodb_buffer_pool_sizein particular is worth checking; too high and MySQL competes with PHP-FPM for memory. - Add a CDN - Cloudflare's free tier adds edge caching, Brotli compression, and serves static assets from a location close to your visitors. Set a long
Cache-ControlTTL for your theme assets and let the CDN hold them.
6. The things that don't matter as much as you think
A few things you'll regularly see in PageSpeed reports that are worth less than they appear:
- "Serve static assets with an efficient cache policy" - if you're on a CDN this is handled. If not, add
Cache-Controlheaders via.htaccessfor your theme folder. - "Reduce unused CSS" - useful in principle, but unless you're shipping a large framework like Bootstrap, the gains are usually marginal. Don't spend days tree-shaking hand-written CSS.
- The mobile score - it's tested on a throttled 4G connection with a mid-range device profile. A 90+ mobile score is excellent for most sites. Chasing 100 on mobile is a long tail of diminishing returns unless your audience is predominantly mobile.
Results
After working through the above on orionesque.com:
- Desktop: 100 / 100 / 100 / 100
- Mobile: 97+ across all metrics, with LCP consistently under 2.5s
- LCP resource: self-hosted woff2, preloaded, delivering in under 300ms
The advantage of EE here is that it gives you full control of template output. You're not fighting a theme framework or a page builder — you write exactly the HTML, <head> content, and asset references you want. That control is worth a great deal when optimising for performance.
Need a hand with your EE site's performance?
Performance optimisation is something we do as a matter of course on every EE project — whether that's a new build, a migration, or an existing site that's started to feel sluggish. If your PageSpeed scores are holding you back, or you're not sure where the bottlenecks are, we're happy to take a look.
Get in touch - we'll give you an honest assessment of what's fixable and what it would take.