Back in 2021, a jewellery brand based in Mayfair came to us with a site that was genuinely gorgeous — deep blacks, full-bleed editorial photography, a bespoke serif typeface that cost more than my first freelance project. It also loaded in 9.4 seconds on a 4G connection. Their bounce rate was sitting at 74%. They were spending £4,000 a month on paid search and most of those clicks were evaporating before a single product had finished rendering.
That project became one of the most instructive things I've done in 9 years of building sites. Because the challenge isn't just "make it fast." It's "make it fastandstill feel like it belongs next to a Cartier boutique on Bond Street." Those two things feel like they're pulling in opposite directions. They're not. But you have to be deliberate about almost every decision.
Why Luxury Jewellery Sites Are a Special Kind of Performance Problem
Most ecommerce performance advice is written for mid-market brands. Compress your images, use a CDN, lazy-load below the fold — done. Jewellery at the luxury end doesn't play by those rules, and if you try to apply them naively, you'll end up with a site that loads quickly but looks like a Shopify dropshipping store.
The specific problems are:
- Hero images shot on medium-format cameras— we're talking source files north of 80MB sometimes
- Custom typefaces loaded from private foundries, not Google Fonts, which means no caching shortcuts
- Parallax scroll effectsthat developers add "for atmosphere" and then never audit
- Product photography with multiple angles— 8, 10, sometimes 14 images per SKU
- Video backgroundsthat someone signed off on in a brand deck without considering the web
And underneath all of that, there's often a WordPress + WooCommerce stack, because that's what 60–70% of independent jewellers are running when they come to us.
Start With a Real Baseline, Not a Gut Feel
Before you touch a single file, measure. I'm obsessive about this. RunGoogle PageSpeed InsightsandWebPageTeston the same page simultaneously. PageSpeed gives you the lab score and the Core Web Vitals breakdown. WebPageTest gives you the waterfall — which is where you actually diagnose what's killing you.
Look at three numbers specifically:LCP(Largest Contentful Paint),TBT(Total Blocking Time), andTTFB(Time to First Byte). For a luxury jewellery site, your enemy is almost always LCP. That hero image — the one with the emerald ring on a marble surface — is probably your LCP element, and it's probably massive and not preloaded.
At Seahawk, we document the baseline in a shared Notion table before any optimisation work starts. Every change gets tracked against it. Sounds obvious. You'd be surprised how many agencies skip this step and then can't demonstrate what they actually improved.
The Image Pipeline Is Everything
This is where 80% of your gains are. No other section of this post matters as much as this one.
Use AVIF First, WebP as Fallback
AVIF is not new anymore but a lot of luxury sites are still serving JPEGs because "the photographer delivers JPEGs." That's not an excuse. AVIF gives you roughly 50% smaller files than JPEG at equivalent visual quality. For a product image that's sitting at 1.2MB as a JPEG, AVIF gets you to 400–600KB without a perceptible quality difference on-screen.
I useSquooshfor manual one-off conversions when I want to check quality visually before committing to a batch process. For production pipelines on WordPress, ShortPixel handles AVIF conversion automatically and the quality-to-size ratio is the best I've tested across about 40 plugins.
Serve the Right Size, Not Just the Right Format
A 4K product image served to a 375px wide iPhone screen is negligent. WordPress'ssrcsethandles this in theory, but you need to make sure your theme is actually generating — and serving — the right intermediate sizes. Check yourwp_get_attachment_imagecalls. Check your theme'sadd_image_sizeregistrations. If your theme was built by someone who just registeredthumbnail,medium, andlarge, go and add aproduct-mobilesize at 480px width and make sure WooCommerce's gallery is using it.
The Hero Image Is a Special Case
Don't lazy-load it. I know that sounds backwards, but lazy-loading your LCP element pushes it further out in the load sequence. Preload it instead. In your<head>:
<link rel="preload" as="image" href="/hero-ring.avif" fetchpriority="high">
That single line dropped LCP by 0.8 seconds on the Mayfair project. Not an exaggeration. One line.
Fonts: The Silent Performance Killer on High-End Sites
Luxury brands rarely use Google Fonts. They're licensing typefaces from foundries like Klim or Optimo, self-hosting them, and loading 4–6 weights because "the brand guidelines say so." I've had brand managers hand me a spec sheet with eight font variants for a site that uses three of them.
Here's what I do:
- Audit which weights actually appear on the site. Use the browser's computed styles panel on every page template.
- Subset the fonts.Font Squirrel's Webfont Generatorlets you strip out glyphs you don't need. A full Latin typeface with all diacritics might be 280KB. A subset covering English-only characters drops that to 40KB.
- Use
font-display: swapso text is visible immediately, then switches to the custom font when it loads. Yes, there's a brief flash. Yes, some brand managers will complain. Show them the conversion data and they stop complaining. - Preload your primary body font the same way you preload the hero image.
The combination of subsetting and preloading typically saves 300–600ms on luxury sites. That's not nothing.
JavaScript: Audit What You're Actually Loading
This one requires honesty. Open your browser's Network tab, filter by JS, and look at what's loading. On a WooCommerce site that's had a few years of plugin accumulation, I routinely see 2–4MB of JavaScript on a product page. That's insane.
The usual suspects on jewellery sites specifically:
- Live chat widgetsthat load 200KB of JS on every page, including ones where no one ever opens the chat
- Review platforms(Yotpo, Trustpilot) loading their full SDK when you only need a star rating widget
- Klaviyo or Omnisendemail pop-up scripts firing on page load instead of being deferred
- Instagram feed pluginsthat pull in a second round of API calls and render-blocking scripts
For WordPress, I useAsset CleanUp Proto disable scripts and stylesheets per page template. It's genuinely granular in a way that WP Rocket's asset optimisation isn't. Load the live chat only on the contact page. Load the Klaviyo pop-up script only after a 3-second user interaction delay. These aren't tricks — they're just responsible loading.
Hosting and Infrastructure: Don't Cheap Out at the Top of the Stack
Here's the thing — you can do everything right with images and fonts and JavaScript, and still have a 600ms TTFB because the server is underpowered or misconfigured. For luxury clients, I've standardised onKinstafor managed WordPress hosting. Their infrastructure runs on Google Cloud's C2 machines, full-page caching happens at the Nginx level before PHP ever runs, and their CDN (powered by Cloudflare's network) handles the asset delivery.
I've also used WP Engine and Flywheel on luxury projects. Both are fine. But Kinsta's TTFB is consistently 80–140ms from UK locations in my testing, which is the best I've measured across managed hosts.
One thing people miss:database optimisation matters more on WooCommerce sites than almost any other platform.WooCommerce writes to thewp_optionstable aggressively, and after a year of operation, that table can have tens of thousands of rows, many of them transients that never got cleaned. WP-Optimize Pro handles this. Run it. Set it on a weekly schedule.
The Checkout and Product Page Are Not the Same as the Homepage
I see agencies optimise the homepage to a 95 PageSpeed score and then ignore the product listing page, the single product page, and checkout. Those are the pages that drive revenue. On a jewellery site, the single product page has the heaviest image load. That's where your 14-angle product gallery lives.
For WooCommerce product galleries, I replace the default gallery with a lightweight custom implementation usingSplide.js— it's about 28KB minified and gzipped, handles lazy loading properly, and doesn't pull in jQuery UI the way the default WooCommerce Flexslider does. The difference in JavaScript payload on a product page goes from ~380KB to ~90KB. That's a meaningful LCP improvement on mobile.
Lazy-load every product imageexcept the first one. The first image should be preloaded. The rest? Let them load as the user scrolls or taps through the gallery.
Test on Real Devices, Not Just DevTools Throttling
Chrome DevTools' throttling is a simulation. It's useful for relative comparisons but it's not ground truth. I keep a Moto G Power (2021) — a sub-£150 Android phone — on my desk specifically for testing. It has a mid-range processor and represents something close to median global mobile hardware. The gap between what DevTools shows and what this phone actually renders has caught me out more than once.
For the Mayfair project, DevTools showed a 1.3 second LCP under "Fast 3G" throttling. The Moto G Power showed 1.9 seconds on an actual 4G connection in central London. Those aren't the same problem. Real device testing showed us that the main thread was getting blocked by a font animation we'd added — a subtle fade-in on the heading typeface. Looked beautiful. Cost 400ms on real hardware. We killed it.
---
FAQ
What's a realistic load time target for a luxury jewellery website?
Under 1.5 seconds for LCP on a mid-range mobile device is what I aim for. Some agencies will tell you 2 seconds is fine for luxury — and they're not entirely wrong for desktop, where your typical jewellery buyer might actually be browsing. ButGoogle's researchshows that the 2.5 second LCP threshold is already where conversion rates start declining significantly. I'd rather have margin. Under 1.5s gives you headroom even as third-party scripts accumulate over time.
Can I keep full-bleed video backgrounds and still hit 1.5 seconds?
Rarely on mobile. What I do instead: serve a poster image (optimised AVIF) on mobile, load the video only on desktop above a CSS breakpoint. You can use a small bit of JavaScript to detect the connection speed via the Network Information API and skip video loading on slow connections entirely. It's not as elegant as a single solution, but it's honest about what the constraints are.
Should I use a page builder like Elementor or Divi on a luxury jewellery site?
I'd steer away from both for a client spending serious money on a bespoke build. They inject significant CSS and JavaScript overhead that's difficult to surgically remove. For luxury projects at Seahawk, we build on either a lightweight custom theme or a block-based theme (Kadence with only the required blocks registered) and keep the page builder out of the picture. If the client needs marketing team editability, we use the native WordPress block editor with a constrained set of custom blocks.
How often should site speed be re-tested after launch?
Monthly, at minimum. WooCommerce plugin updates, new marketing scripts the client installs without telling you, seasonal campaign landing pages with embedded Instagram feeds — these all erode performance over time. I schedule a quarterly performance audit for ongoing retainer clients. Not a full rebuild, just a 2-hour audit with a written report and a priority fix list. Most retainer clients find it incredibly valuable because they've usually installed three new things since the last check.
---
Speed and luxury aren't opposites. They're both about respect — respect for the product and respect for the person looking at it. A site that makes someone wait is a site that's already told them something about how much you value their time. Get the fundamentals right, stay honest about what's actually causing the slowness, and test on real hardware. The 1.5-second target is achievable. I've hit it on sites with 40-image product galleries and custom serif typefaces from Swiss foundries. It just takes more intention than most builds get.