Get proposal

Measure your website’s real-world performance before you touch a single line of code, then fix whichever bottleneck is doing the most damage, usually oversized images or a slow server response. That is the entire discipline behind how to optimise website speed. Everything else is sequencing and verification.

The order matters more than the individual fix. Guess your way through it, and you’ll spend a week trimming JavaScript on a site whose real problem is a sluggish origin server three time zones away. Measure first, and you know exactly where to spend your time.

Here is the priority sequence that works for almost every site:

Pro Tip: Google’s Core Web Vitals thresholds give you the finish line: Largest Contentful Paint (LCP) under 2.5 seconds, Interaction to Next Paint (INP) under 200 milliseconds, and Cumulative Layout Shift (CLS) under 0.1. Pair those with a Time to First Byte under 800 milliseconds, and you have a genuinely responsive site, not just a passing grade.

Key Takeaways

The fastest, most reliable route to a faster website is measuring lab and field data first, fixing images and caching before anything else, then validating every change against Core Web Vitals thresholds.

Point Details
Measure before fixing Use PageSpeed Insights for combined field and lab data before changing any code.
Fix images first Convert to WebP or AVIF and add responsive srcset for the fastest, lowest-effort win.
Enable text compression Turn on Brotli at the server or CDN level to cut text asset size by up to 80%.
Protect the LCP element Preload it and never apply lazy loading to anything above the fold.
Validate at the 75th percentile Compare before and after data by device segment, not by average.
Build speed in from the start Milda integrates performance and caching strategy into every website build for fashion and beauty brands, rather than treating it as a post-launch fix.

Table of Contents

How do you measure website speed correctly?

Lab data and field data answer different questions, and confusing them is the most common mistake we see on client sites before a rebuild. Lab data comes from a controlled test, run once, on a fixed connection and device profile. It’s reproducible, which makes it brilliant for debugging. Field data comes from actual visitors, on their actual phones, over their actual patchy 4G connection, and it’s the only data that reflects what your customers experience.

PageSpeed Insights blends both. It reports Chrome UX Report field data (when your traffic volume is high enough to qualify) alongside a fresh Lighthouse lab run, which is precisely why it’s the recommended starting point for diagnosis rather than an afterthought tool. If your site has enough traffic, always check the field data tab first. That’s what Google actually uses to judge your Core Web Vitals for search purposes, and it’s frequently worse than your lab score because real users have real network conditions and mid-range phones.

Once you know field performance is poor, dig into why using lab tools:

Metrics matter differently depending on what you’re diagnosing. LCP tells you when the largest visible element finished rendering. INP (which replaced First Input Delay in Google’s ranking signals) tells you how responsive the page feels once someone actually clicks or taps something. CLS tells you whether content jumps around as it loads. TTFB and FCP tell you how much of the delay sits on the server side versus the browser side. Always check these at the 75th percentile, segmented by device, because averages hide the mobile users having the worst experience.

Reading a waterfall chart is simpler than it looks once you know what to check in order: DNS lookup time, connection and TLS handshake, then TTFB, then the actual transfer, then main-thread processing. A long gap between “request sent” and “first byte received” is a server problem. A long gap between “download finished” and “page interactive” is a JavaScript problem. Different diagnoses, different fixes.

What are the quickest wins for improving page load speed?

Images are almost always the fastest, highest-impact fix available, and it’s rarely close — learn more about how to streamline visual asset creation for ecommerce. Switching from JPEG or PNG to WebP typically cuts file weight significantly, and AVIF can shave off more still.

Hands sorting digital images at workstation

A responsive image implementation looks like this in practice:

<img src="dress-800.webp"
     srcset="dress-400.webp 400w, dress-800.webp 800w, dress-1600.webp 1600w"
     sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1600px"
     alt="Silk midi dress in emerald green"
     width="800" height="1067">

The browser picks the right file for the visitor’s screen, so nobody downloads a 1600 pixel-wide image to display it at 400 pixels.

Text compression is the second-biggest quick win, and it’s almost embarrassingly cheap to enable. Brotli compression outperforms GZIP by roughly 15 to 25%, and turning on server-level compression at all can reduce your HTML, CSS, and JavaScript payload by 70 to 80%. Most modern CDNs and hosting platforms support Brotli natively; it’s usually a single configuration flag rather than a code change.

Caching closes out the trio. A basic Cache-Control header for static assets looks like this:

Cache-Control: public, max-age=31536000, immutable

That tells the browser (and any CDN edge node sitting between you and the visitor) to hold onto that file for a year, because you’ll change the filename when the asset actually changes. Combine that with edge caching through a CDN, and repeat visitors, and often first-time visitors on a popular page, get served from a server geographically close to them rather than your origin.

If you had to rank these by impact versus effort: image optimisation delivers the biggest visible improvement for the least engineering time, text compression is close behind and often a single settings change, and caching delivers the most durable long-term gain but needs a bit more thought around invalidation. The recommended order for most sites is images first, then JavaScript, then server-side caching, and that sequence holds whether you’re running a five-page brochure site or a full product catalogue.

How do you reduce render-blocking CSS and JavaScript?

Every script tag and stylesheet the browser encounters before it can paint the page is a render-blocking resource, and cutting them down is where developers usually see the biggest interactivity gains. Add defer to scripts that don’t need to run immediately, and async to scripts that don’t depend on DOM order. Code-split large JavaScript bundles so the browser only downloads what a given page actually needs, rather than your entire application in one file.

Critical CSS inlining is the technique most teams skip because it feels fiddly, but it’s worth the effort on template-heavy sites. Extract the CSS needed to render above-the-fold content, inline it directly in the <head>, and load the rest asynchronously. The browser paints immediately with what it has, rather than waiting for a full stylesheet to download. Pair this with an audit for unused CSS. Design systems accumulate dead styles fast, and a bloated stylesheet slows down every single page load.

Web fonts deserve their own checklist:

Pro Tip: Never lazy-load your LCP element. It’s tempting to add loading="lazy" to every image on the page for consistency, but if you apply it to your hero image or above-the-fold content, you actively delay the metric Google weighs most heavily in Core Web Vitals. Eager-load anything visible on first paint; reserve loading="lazy" strictly for images and iframes below the fold.

Resource hints round out the frontend toolkit. <link rel="preconnect"> tells the browser to open a connection to a third-party domain before it’s actually needed, useful for CDNs or font hosts. <link rel="preload"> tells the browser to fetch a specific critical asset, such as your LCP image, at the highest priority. Used sparingly on genuinely critical resources, both cut meaningful time off the render path. Overused on everything, they crowd each other out and stop helping.

Why does server response time undermine every other fix?

A slow Time to First Byte poisons every metric downstream of it, because nothing else on the page can start until the server hands over that first byte of HTML. You can have flawlessly compressed images, perfectly deferred JavaScript, and pristine caching headers, and still fail Core Web Vitals if your origin server takes 1.8 seconds to respond to the initial request.

Diagnosing whether the bottleneck sits at the origin, the DNS layer, or the network is a short checklist: check DNS resolution time in your waterfall (should be under 100 milliseconds on a warm connection), check the TLS handshake time, then isolate TTFB itself. If TTFB is consistently high across regions, the problem is your server or application logic, not your network. If it’s high from one region only, you likely need a CDN presence closer to that audience.

A content delivery network solves a meaningful chunk of this by caching static and, increasingly, dynamic content at edge nodes close to visitors. Configure cache keys carefully (query parameters and cookies can accidentally fragment your cache into thousands of near-duplicate entries) and set immutable policies on versioned assets so the CDN never needs to revalidate them.

Protocol choice matters more than most site owners realise. HTTP/2 allows multiplexing, meaning a browser can request dozens of assets over a single connection instead of queuing them. HTTP/3, built on QUIC, goes further by cutting connection setup time and handling packet loss more gracefully, which matters enormously on mobile networks. Most CDNs, including Cloudflare, support both, and enabling them is typically a dashboard toggle rather than a code change.

Common causes of poor performance cluster around a predictable set of culprits: unoptimised images, too many HTTP requests, missing browser caching, render-blocking resources, and slow origin responses. Test from a region representative of your actual traffic, not just your office connection, and you’ll usually find one of these five sitting at the root of the problem.

How do you validate that your fixes actually worked?

A single before-and-after Lighthouse run tells you almost nothing on its own, because lab scores vary run to run depending on machine load and network jitter. The workflow that actually holds up looks like this:

  1. Establish a baseline using both lab and field data, recorded and saved, not just eyeballed.
  2. Implement one change at a time. Bundling five fixes into one deployment makes it impossible to know which one moved the needle, or which one broke something.
  3. Re-test using both lab and field methods, giving field data enough time to accumulate a meaningful sample, typically a week or more depending on traffic volume.
  4. Compare at the 75th percentile, segmented by device, rather than trusting an average that hides your worst-performing segment.
  5. Roll the change forward only once you’ve confirmed the improvement holds, then repeat for the next item on your priority list.

For ongoing monitoring, a practical stack combines Lighthouse CI (automated lab testing on every deployment), scripted WebPageTest runs for scenario testing, RUM for continuous field visibility, and Search Console’s Core Web Vitals report for tracking by URL group over time.

A sample performance budget worth enforcing in CI: total JavaScript under 300KB compressed, LCP image under 200KB, and total page weight under 1.5MB for a typical content page. Enforce it as a build-time check that fails the deployment if a change pushes past the threshold, rather than as a suggestion someone remembers to check manually.

Track cache hit and miss rates at the CDN level, TTFB trends by template (your homepage and your checkout page will behave very differently), and LCP, INP, and CLS trends segmented by template rather than site-wide, since a single slow product template can drag down an otherwise healthy average.

What should you budget in time and cost for common site fixes?

Expectations vary enormously by site type, and setting them upfront saves a lot of frustration mid-project. A small brochure or portfolio site with a handful of templates might see meaningful Core Web Vitals improvement within a few days of focused work, mostly image and caching fixes. An e-commerce store with dozens of templates and third-party integrations (payment widgets, reviews, chat) typically needs several weeks, because every third-party script needs its own audit. A JavaScript-heavy application, particularly one built on a framework with a large client-side bundle, often needs a genuine engineering sprint, not a quick pass.

Fix Category Typical Time Relative Cost
Image conversion & responsive srcset Hours to 1–2 days Low
Caching & CDN configuration 1–3 days Low to moderate
Text compression (Brotli/GZIP) Hours Low
JavaScript audit & code-splitting 1–2 weeks Moderate to high
Third-party script rationalisation Days to 1 week Moderate
Server/infrastructure changes 1–3 weeks High

Diagram comparing time and cost for website fixes

Budget the low-cost, low-effort items first, always. Image work and caching configuration deliver disproportionate returns for the time invested, which is exactly why the recommended order for most site types puts images ahead of JavaScript refactoring, which in turn comes ahead of server-side architecture changes. Deeper engineering work, rewriting a bloated JavaScript framework or migrating hosting infrastructure, genuinely does deliver results, but it’s the expensive, slower-return end of the list, not the starting point.

The trade-off worth naming honestly: quick wins buy you time and goodwill, but they have a ceiling. If your Core Web Vitals are still failing after images, compression, and caching are all sorted, the remaining problem is almost always architectural, and no amount of further tweaking around the edges fixes that.

When should you bring in a specialist for website speed?

Persistently high TTFB that survives a caching and CDN pass, a complex JavaScript framework with a bundle size problem baked into its architecture, or Core Web Vitals that keep failing on field data despite passing lab tests, these are the three scenarios where DIY fixes have genuinely run their course.

Before hiring anyone, run them through a short interview checklist:

A vendor who can’t show you field data from a past project, and who promises a single fix will solve every performance problem on your site regardless of its architecture, is not someone who has actually done this work before. Genuine performance engineering produces a paper trail: baseline numbers, a prioritised list, and evidence the fix held up over time.

Realistic deliverables from a proper performance engagement include a baseline report covering both lab and field data, a prioritised list of fixes ranked by impact and effort, validation scripts or a monitoring setup you keep after the engagement ends, and a runbook explaining what was changed and why, so your team isn’t left guessing six months later.

Studio perspective: why speed is a brand decision, not just a technical one

Speed and visual richness get treated as opposing forces far too often, and that’s the wrong framing for fashion, beauty, and lifestyle brands specifically. A slow-loading hero image doesn’t just cost you milliseconds on a Lighthouse score; it costs you the first impression the entire brand identity was built to create. Visitors form a judgement about credibility within seconds of a page starting to load, and a stalled, half-rendered layout reads as unfinished or careless, regardless of how considered the actual design underneath it is.

The instinct to protect image quality by simply serving fewer, smaller images is understandable and, in our experience, usually the wrong trade-off for premium brands. Responsive delivery paired with CDN edge transforms preserves the visual fidelity a fashion or beauty brand needs while still hitting Core Web Vitals targets, because the browser gets a correctly-sized file rather than a heavily compressed one. Downsampling every image to hit a file-size target flattens exactly the texture and colour precision that a premium visual identity depends on to feel premium at all.

This is the tension we navigate on every website build: a brand’s visual language has to survive contact with a phone on patchy 4G, not just look flawless on a studio monitor. Getting that balance right is a design decision as much as a technical one, which is part of why we build visual identity and website execution as one continuous process rather than handing off a finished design to be “optimised” afterwards. Speed decisions made after the design is locked tend to cost quality; speed decisions made alongside the design rarely do.

How we can help with website speed and brand experience

If everything above sounds like the right approach but not something you have the time or team to execute properly, that’s precisely the gap a dedicated performance and design engagement closes. Milda builds speed into the website itself rather than bolting it on afterwards, which means the fashion, beauty, and lifestyle brands we work with don’t have to choose between a visually rich site and a fast one.

Milda

A typical engagement starts with a full baseline audit covering both lab and field data, followed by a prioritised list of fixes ranked exactly the way this article has laid them out: images and caching first, then frontend and JavaScript, then infrastructure where it’s genuinely needed. Every fix gets validated against the same Core Web Vitals targets before we call it finished, and clients leave with a monitoring setup, not just a one-off improvement that quietly regresses six months later. For brands rebuilding or launching a new site, this sits inside our website design and development process from day one, rather than as an afterthought once the visuals are locked.

If your Core Web Vitals are failing, or you’re planning a redesign and want speed built in from the first wireframe, get in touch through the luxury branding guide to see how we scope a project, or reach out directly to start a discovery conversation about your current site’s performance.

Tools and resources to keep close while you optimise

Different tools earn their place at different stages of the work, and knowing which one to reach for saves a lot of wasted testing time.

Keep PageSpeed Insights and your RUM dashboard open during diagnosis, Lighthouse and WebPageTest open during active development, and web.dev’s documentation bookmarked for whenever a metric’s exact definition matters for a decision you’re about to make.

Sources

Leave a Reply

Your email address will not be published. Required fields are marked *