TL;DR:
- Optimizing website speed requires fixing server response times first, as slow TTFB delays all subsequent resources.
- Improving image formats and lazy loading offers high returns, significantly reducing page weight and enhancing LCP.
- Defer non-critical JavaScript and optimize CSS and fonts to prevent render-blocking and reduce layout shifts effectively.
Website speed optimisation is the practice of reducing page load times and improving server response to deliver faster, more stable experiences for users and search engines. For website owners and digital marketers, it directly affects Google rankings, bounce rates, and conversion outcomes. The standard industry term is web performance optimisation, and it is measured through Google’s Core Web Vitals: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Tools such as Google PageSpeed Insights, Lighthouse, and Chrome DevTools provide the diagnostic data needed to act on these metrics with precision.
1. Fix server response time before anything else
Time To First Byte (TTFB) is the interval between a browser request and the first byte of data received from the server. It is the single most consequential metric in web performance because a slow TTFB delays every resource that follows, including images, scripts, and stylesheets. No amount of frontend optimisation compensates for a slow backend.
A TTFB above 800ms is a threshold worth treating seriously. Fixing TTFB first enables meaningful improvements to LCP, INP, and CLS. Skipping this step and going straight to image compression or JavaScript deferral produces limited results.
The most effective ways to reduce TTFB include:
- Upgrading to managed hosting with server-side caching (such as Kinsta or WP Engine for WordPress sites)
- Implementing a Content Delivery Network (CDN) such as Cloudflare or Fastly to serve assets from edge locations closer to users
- Setting correct cache-control headers to reduce repeat server processing
- Enabling HTTP/2 or HTTP/3 to allow parallel resource loading
Pro Tip: Run a TTFB test using WebPageTest before making any frontend changes. If your TTFB exceeds 600ms, address hosting and caching first. Frontend fixes applied to a slow server will not move your Core Web Vitals scores meaningfully.
2. Optimise images for the highest performance return
Images are the single largest contributor to page weight on most websites. Images account for 40 to 60% of total page size on the majority of sites, and reducing that weight produces faster load times with relatively low development effort. This makes image optimisation one of the most cost-effective ways to improve website performance.
Modern image formats deliver significant file size reductions. Converting images from JPEG or PNG to WebP or AVIF reduces file sizes by 25 to 50% without visible quality loss. That reduction translates directly into faster LCP scores, particularly on mobile connections.
The following practices form a complete image optimisation approach:
| Technique | Purpose |
|---|---|
| Use WebP or AVIF formats | Reduce file size by up to 50% versus JPEG or PNG |
Implement "srcsetandsizes` attributes |
Serve appropriately sized images to each device |
Set explicit width and height on all images |
Prevent layout shifts that increase CLS |
| Apply lazy loading to below-the-fold images | Defer non-critical image loading until needed |
Preload the LCP hero image with fetchpriority="high" |
Reduce LCP by 500 to 1500ms |
Tools such as Squoosh, Cloudinary, and the ShortPixel plugin for WordPress automate much of this process. For organisations managing large media libraries, a CDN with on-the-fly image transformation removes the need for manual conversion.
Pro Tip: Always set explicit width and height attributes on every image element. Without them, the browser cannot reserve space during load, which causes content to shift and raises your CLS score.
3. Manage JavaScript to reduce main thread blocking
JavaScript is the most common cause of poor interactivity scores. Every script that runs on the main thread competes with user interactions, and long tasks above 50ms directly increase INP latency. The goal is to reduce the volume of JavaScript executed at page load and to defer anything that is not immediately required.
Deferring or async-loading non-critical scripts reduces main thread blocking and improves INP. This applies particularly to third-party scripts such as analytics, chat widgets, and advertising tags, which are frequent offenders. Loading these scripts after the initial page render, or only on user interaction, removes a significant source of delay.
Additional JavaScript optimisation techniques include:
- Running a coverage audit in Chrome DevTools to identify and remove unused JavaScript
- Using code splitting and dynamic imports so that only the code required for the current page loads initially
- Breaking up long tasks using
scheduler.yield()orsetTimeoutshims to allow the browser to respond to user input between chunks - Applying tree shaking in build tools such as Webpack or Rollup to eliminate dead code
- Minifying and compressing all scripts using tools such as Terser or esbuild
Pro Tip: Use the Chrome DevTools Performance panel to identify long tasks on your page. Any task exceeding 50ms is a candidate for breaking up or deferring. Addressing the top three longest tasks typically produces a measurable INP improvement.
4. Optimise CSS and fonts to prevent render-blocking
CSS and web fonts affect how quickly a browser can paint the first visible content on screen. Render-blocking stylesheets delay First Contentful Paint, and font loading without proper configuration causes layout shifts as text reflows when fonts arrive.
Inlining critical above-the-fold CSS and using font-display: swap are two of the most direct interventions for improving LCP and CLS. Critical CSS refers to the styles needed to render the visible portion of the page without waiting for the full stylesheet to load. Inlining this CSS in the <head> removes a render-blocking request.
Effective CSS and font practices include:
- Removing unused CSS using tools such as PurgeCSS or UnCSS
- Avoiding CSS
@importstatements, which create sequential request chains - Using
font-display: swapto show fallback text while custom fonts load - Preloading primary fonts with a
<link rel="preload">tag - Self-hosting fonts to eliminate cross-origin connection delays and reduce CLS from font swapping
- Applying font metric overrides (
ascent-override,descent-override) to match fallback font dimensions to the custom font
Pro Tip: Limit font weights and styles to only those used on the site. Loading a full font family with six weights when only two are used adds unnecessary request overhead and slows rendering.
5. Use resource hints strategically
Resource hints tell the browser which assets to prioritise before it discovers them through normal parsing. Used correctly, they reduce the time spent waiting for critical resources. Used carelessly, they create bandwidth contention that slows the page.
Preloading only one or two critical resources, such as the hero image and the primary font, produces the best results. Preloading too many assets forces the browser to compete for bandwidth across multiple high-priority downloads simultaneously. The preconnect hint is better suited for establishing early connections to third-party origins such as Google Fonts or an analytics server.
The three main resource hints serve distinct purposes. preload fetches a specific asset immediately. preconnect establishes a connection to an origin without fetching a file. prefetch loads resources likely needed for the next navigation. Applying each to the right situation, rather than using preload for everything, keeps the critical path clear.
6. Keep DOM complexity low and optimise for mobile
A large Document Object Model (DOM) slows rendering, increases memory usage, and makes JavaScript operations more expensive. Google recommends keeping the DOM below 1,500 nodes. Sites built on page builders or legacy CMS templates frequently exceed this threshold due to unnecessary wrapper elements and deeply nested structures.
Reviewing the DOM with Chrome DevTools reveals which elements can be removed or consolidated. Replacing generic <div> wrappers with semantic HTML elements such as <article>, <section>, and <nav> reduces nesting and improves accessibility without changing visual output. This is particularly relevant for organisations following sustainable web design principles, where leaner code serves both performance and environmental goals.
Mobile optimisation requires testing on real devices and slow connections, not just desktop simulations. Reserving explicit space for ads and dynamically loaded content prevents layout shifts on slower connections. Delaying third-party scripts until after a user interaction, such as a scroll or click, is one of the most effective ways to improve mobile INP without removing functionality.
Pro Tip: Use real user monitoring data from the Chrome User Experience Report (CrUX) alongside Lighthouse scores. Synthetic tools measure ideal conditions. Field data reveals how your site performs for actual users on real devices and networks.
7. Measure continuously, not just once
Testing with both real user monitoring and synthetic tools gives the most accurate picture of site performance. A single Lighthouse audit after a deployment is not sufficient. Performance degrades over time as new plugins, scripts, and content are added, and only regular measurement catches regressions before they affect rankings.
Google Search Console provides field data from real users through the Core Web Vitals report. PageSpeed Insights combines this CrUX data with a Lighthouse audit in one view. WebPageTest offers waterfall charts that show exactly which resources are delaying load. Running audits after each significant site change, and scheduling monthly checks as a baseline, keeps performance from drifting.
The most effective optimisation process follows a fixed order: address TTFB first, then LCP through image and server improvements, then INP through JavaScript management, and finally CLS through layout and font fixes. This sequence, grounded in Core Web Vitals prioritisation, avoids the common mistake of spending effort on visible frontend changes while the underlying infrastructure remains slow. For a structured approach to auditing, the SEO audit guide for Australian nonprofits covers Core Web Vitals interpretation in practical terms.
Key takeaways
Effective website speed improvement requires fixing server response time first, then addressing images, JavaScript, and CSS in order of impact.
| Point | Details |
|---|---|
| Fix TTFB before frontend work | A slow server response delays every resource; address hosting and caching first. |
| Images deliver the highest return | Converting to WebP or AVIF and lazy loading below-the-fold images reduces page weight by up to 50%. |
| Defer non-critical JavaScript | Async or deferred loading of third-party scripts reduces main thread blocking and improves INP. |
| Self-host fonts and limit weights | Removing cross-origin font requests reduces CLS and speeds up first paint. |
| Measure with field data | CrUX and real user monitoring reveal actual performance; synthetic tools alone are insufficient. |
Speed without shortcuts
From working with purpose-driven organisations on their digital presence, one pattern stands out consistently. Teams spend considerable effort compressing images and minifying CSS, then wonder why their Core Web Vitals scores remain poor. The answer is almost always the same: the server response time has not been addressed.
There is a tendency to reach for visible, tangible fixes first. Image compression is satisfying because you can see the file size drop. Minifying a stylesheet feels productive. But if the TTFB is sitting at 1.2 seconds, those gains are absorbed before the user sees anything. The dependency chain runs from infrastructure outward, and working against that order wastes effort.
The other observation worth sharing is that speed and sustainability are not in tension. Leaner pages load faster and consume less energy. Removing unused JavaScript, self-hosting fonts, and reducing DOM complexity all serve both goals simultaneously. Organisations that approach performance as a stewardship question, rather than a technical checklist, tend to make better decisions about what to add to their sites in the first place.
The most durable approach is iterative. Run a Core Web Vitals audit, fix the highest-impact issue, measure again, and repeat. That cycle, applied consistently over months, produces more reliable results than a single large optimisation sprint. A useful starting point is reviewing how to make an SEO-friendly website as a framework for integrating performance into broader site decisions.
— Ben
How Marzipan approaches site performance
Marzipan works with mission-led organisations across Australia to build and maintain websites that perform well without unnecessary complexity. The approach combines sustainable web design with performance-driven development, addressing server configuration, image pipelines, and Core Web Vitals from the ground up. For organisations that need ongoing support rather than a one-off audit, Marzipan’s digital marketing services include regular performance monitoring and technical SEO. If your site is carrying technical debt that is holding back both speed and search visibility, it may be worth a conversation about what a considered rebuild could achieve.
FAQ
What is the most important factor in website speed?
Server response time, measured as Time To First Byte (TTFB), is the most important factor. A TTFB above 800ms delays every subsequent resource and limits the effectiveness of all other optimisations.
How do images affect website loading speed?
Images typically account for 40 to 60% of total page weight. Converting to WebP or AVIF format and applying lazy loading to below-the-fold images reduces this weight by up to 50%, directly improving LCP scores.
What tools should I use to test website speed?
Google PageSpeed Insights, Lighthouse, and Chrome DevTools provide synthetic performance data. For field data reflecting real user conditions, the Chrome User Experience Report (CrUX) and Google Search Console’s Core Web Vitals report are the most reliable sources.
How often should I audit my website’s performance?
Run a performance audit after every significant site change and schedule a routine check at least once per month. Performance degrades gradually as new content, plugins, and scripts are added, and regular audits catch regressions early.
Does JavaScript affect Core Web Vitals scores?
Yes. Render-blocking and long-running JavaScript tasks directly increase INP latency and can delay LCP. Deferring non-critical scripts and breaking up long tasks above 50ms are the primary interventions for improving interactivity scores.
