Why Web Performance Is a Business Metric, Not Just a Technical One
The web performance research that most compellingly demonstrates its business impact: the consistent finding across studies conducted by Google, Amazon, Cloudflare, and independent researchers that page load time and user experience metrics are directly correlated with conversion rates, bounce rates, and revenue. Google’s research found that as page load time increased from one second to three seconds, the probability of a mobile user bouncing increased by 32%; from one to five seconds, the probability increased by 90%. Amazon’s research suggested that every 100ms of additional latency cost them approximately 1% of revenue. These numbers are from specific contexts but the direction of the relationship is robust: slower pages produce worse business outcomes.
The web performance business case that most resonates with stakeholders who are not technical: the page speed improvement that converts 3% of visitors instead of 2% has effectively increased marketing ROI by 50% from the same traffic. The faster website does not require more advertising spend to generate more conversions; it extracts more value from the existing traffic by reducing the exit rate that slow pages produce. For any business with meaningful web traffic and conversion-dependent revenue, web performance optimisation is among the highest-return technical investments available.
Core Web Vitals: Google’s Performance Standards
Google’s Core Web Vitals — the three performance metrics that Google uses as direct ranking signals in search results — define the specific performance standards that web developers should optimise toward. Largest Contentful Paint (LCP) measures the time from page navigation to the rendering of the largest content element visible in the viewport (the image, heading, or text block that is the dominant visual element above the fold) — with the target of under 2.5 seconds for a good score. Interaction to Next Paint (INP) measures the latency of the page’s response to user interactions (clicks, key presses, and taps) throughout the entire page visit — with a target of under 200 milliseconds. Cumulative Layout Shift (CLS) measures the visual stability of the page as it loads (how much the content unexpectedly moves as additional resources load) — with a target score below 0.1.
The Core Web Vitals measurement tools that most efficiently reveal where a website’s performance needs improvement: Google Search Console’s Core Web Vitals report (which shows field data from real Chrome users visiting the site, organised by URL group and showing the distribution of good, needs improvement, and poor scores), Google PageSpeed Insights (which combines field data with lab measurements and provides specific, prioritised improvement recommendations for the specific URL tested), and Lighthouse (the auditing tool built into Chrome DevTools that provides a comprehensive performance audit with explanations of each finding and guidance on how to address them).
Image Optimisation: The Highest-Return Performance Improvement
Images typically account for 50-70% of the total byte size of web pages, making image optimisation the single highest-return web performance improvement available to most websites. The image optimisation techniques that produce the most significant size reduction: format modernisation (replacing JPEG and PNG images with modern formats — WebP provides 25-35% smaller file sizes than JPEG at equivalent visual quality, and AVIF provides 50% or greater reductions — using the HTML picture element to serve the optimal format to each browser based on its support), compression (applying lossy or lossless compression appropriate for each image type and context, using tools like Squoosh, ImageOptim, or automated build tools), and dimensioning (serving images at the exact pixel dimensions they will be displayed rather than serving a 3000px wide image that is displayed at 800px and scaled down by the browser).
The image lazy loading technique that most reduces the initial page load time for pages with many images: the native loading=lazy attribute on img elements, which instructs the browser to defer loading images that are below the visible viewport until the user scrolls toward them. The page with twenty images where only the top five are visible on initial load benefits dramatically from lazy loading, which causes only the five visible images to load initially — reducing the initial page byte load and the time to first visible content by the weight of the fifteen deferred images.
JavaScript Performance: Loading Less and Loading Smarter
The JavaScript performance improvement that most reduces the time to interactive for JavaScript-heavy web applications: code splitting, which divides the application’s JavaScript bundle into smaller chunks that are loaded only when needed rather than loading the entire application JavaScript on the initial page load. The single-page application that delivers all of its JavaScript in a single large bundle on first load is forcing the user to download, parse, and execute JavaScript for features they may never use before the page becomes interactive. The same application with route-based code splitting delivers only the JavaScript required for the current page on initial load, deferring the JavaScript for other routes until those routes are navigated to.
The JavaScript payload measurement that most reveals optimisation opportunities: the coverage tool in Chrome DevTools, which shows for each loaded JavaScript file the percentage of code that is actually executed during a specific page interaction. The JavaScript file where 80% of the code is unused during typical page interactions is a code splitting candidate — if the unused code is related to features that are not present on the current page, splitting it into a separate chunk that loads only when needed eliminates the unnecessary load, parse, and compile cost of that code on every page visit.
Caching, CDNs, and Server Performance
The caching strategies that most effectively reduce the load time of repeat visits and reduce server load: browser caching (setting appropriate cache-control headers that instruct the browser to store static assets — images, fonts, JavaScript and CSS files — locally and serve them from the cache on subsequent visits, without making a network request), CDN caching (distributing the content delivery to edge servers geographically close to each user, reducing the latency of asset delivery regardless of where the origin server is located), and server-side caching (storing the result of expensive database queries or computation in memory and serving the cached result for subsequent identical requests, reducing the time and resource cost of generating dynamic page content).
The server performance improvement that most reduces Time to First Byte (TTFB) — the time between the browser’s initial request and the first byte of the response arriving — for dynamic web applications: the move from server-side rendering on every request to static site generation or edge rendering. The page that is generated fresh on every request (querying a database, processing templates, assembling a response) will always be slower than the page that is pre-generated and served from a CDN edge node without any server processing. The static site generator approach (building HTML files at deployment time rather than at request time) and the incremental static regeneration approach (rebuilding pages at defined intervals rather than on every request) reduce TTFB to the milliseconds required to serve a pre-built file from a nearby CDN node rather than the hundreds of milliseconds required to generate the page dynamically.