Faster pages mean better conversion and fewer support complaints. Each guide targets a specific bottleneck you can measure and fix.
Google recommends a minimum cache lifetime of 30 days for all cacheable subresources, with one week as the absolute minimum and one year recommended for static assets (Chrome DevTools Lighthouse). Without caching headers, every return visit downloads your CSS, JavaScript, images, and fonts from scratch — wasting bandwidth and making your site feel slow for your most engaged users.
Open guideMinification strips whitespace, comments, and unnecessary characters from code without changing functionality — typically saving 20-30% on file size. Every visitor downloads your development comments and formatting. Build tools like Terser (JS) and cssnano (CSS) handle this automatically, and most CDNs offer it as a toggle.
Open guideGoogle officially confirmed on March 12, 2024 that Core Web Vitals are used as a ranking factor (Google Search Central). After the March 2024 core update, sites with poor CWV experienced 20-40% traffic drops while those that improved saw 15-30% gains (BrightVessel). Pages at position 1 are 10% more likely to pass CWV than pages at position 9 (BKND).
Open guideBounce probability increases 32% when page load time goes from 1 to 3 seconds, and 123% at 10 seconds (Google/Huckabuy). Conversion rates drop by 4.42% for each additional second of load time (WP Rocket). The average page loads in 2.5s on desktop but 8.6s on mobile (ToolTester, 2026) — meaning mobile users are already at the edge of abandonment before your page finishes.
Open guideBrotli compression reduces file sizes by up to 70% (vs Gzip's 65%), with Akamai reporting median savings of 82% for Brotli (DebugBear). Switching from Gzip to Brotli alone improves First Contentful Paint by approximately 3.5% (WP Rocket). Enabling compression is typically a single server configuration change that instantly benefits every visitor.
Open guideThis check measures how long the initial HTML document request takes. It is your baseline "first response" signal before all scripts, images, and secondary resources finish load...
Open guideImages comprise 21% of total webpage weight on average, with pages loading 4.4MB of image data (HTTP Archive, 2024). Only 30% of images are served in WebP format despite 97% browser support (W3Techs, 2026) — meaning most sites are still serving larger JPEG/PNG files when a smaller, identical-quality alternative exists. Switching to WebP typically cuts image bytes by 30-50%.
Open guideImages account for the largest portion of page weight on most sites — averaging 4.4MB per page (HTTP Archive, 2024). When total image bytes blow past your budget, mobile users on metered connections pay real money for your bloat, and everyone gets a slower experience. Performance budgets exist to catch this drift before it compounds.
Open guideRender-blocking resources are the most common cause of poor First Contentful Paint — only 68% of desktop pages and 51% of mobile pages achieve good FCP scores (Shopify Performance, 2024). Each render-blocking resource forces the browser to download and process it before painting any content. Inlining critical CSS and deferring non-critical scripts can make content appear seconds faster.
Open guideGoogle recommends a TTFB of 0.8 seconds or less, with 200ms as the ideal target (Seobility/Google). An analysis of 143,827 URLs found that TTFB was the strongest speed-related correlation with rankings (Neil Patel). TTFB is the foundation — no amount of frontend optimisation can overcome a slow server. Common causes: unoptimised database queries, no page caching, or inadequate hosting.
Open guidePerformance is not one number. It is the combined result of server speed, page weight, render path decisions, and field conditions.
Performance work goes wrong when teams chase a single metric and miss the system behind it. A page can have decent lab scores while still feeling slow on mobile networks because its HTML is late, its images are heavy, or its long-tail JavaScript keeps the main thread busy after first paint.
This category is designed to help you separate the big levers from the cosmetic ones. The guides here focus on the checks that repeatedly move real outcomes: transfer size, cache behavior, compression, image delivery, render-blocking assets, and field-measured experience such as Core Web Vitals.
Slow pages cost attention early. If the first useful content is delayed, users bounce before they ever see the quality of what you built.
Speed debt tends to compound. One extra app script, one large hero image, and one weak cache rule rarely look dramatic alone, but together they can reshape the whole session.
Uploading large desktop-oriented hero images and relying on the browser to scale them down later.
Shipping good cache headers for CSS and JS but leaving HTML, images, or fonts on weak defaults.
Initial HTML and server response timing so you can tell whether the bottleneck starts at the edge, the origin, or the application.
Compression, caching, and redirect hygiene so repeat visits and crawl fetches are not paying avoidable transfer costs.
Start with the biggest cost center you can confirm quickly: slow HTML, no compression, weak cache policy, or oversized images.
Fix issues in the order users feel them: first response, critical render path, then media and background payload.
