Website speed affects everything — conversion, SEO, user experience, and the bottom line. Google reports that the probability of bounce increases by 32 percent when page load time goes from 1 to 3 seconds (Google, "Find Out How You Stack Up to New Industry Benchmarks for Mobile Page Speed"). This guide gives you 20 concrete, prioritized steps you can implement immediately — from low-hanging fruit to advanced optimizations.
Why speed matters: Key statistics
Speed is directly linked to business results. Amazon estimated that 100 milliseconds of extra load time cost them 1 percent in sales (Greg Linden, Amazon). Walmart found that for every second of improvement in load time, conversion increased by 2 percent (WalmartLabs, "The Impact of Web Performance"). Vodafone improved LCP by 31 percent and saw an 8 percent increase in sales (web.dev, "Vodafone Performance Case Study").
For SEO, speed is a direct ranking factor through Core Web Vitals — LCP (Largest Contentful Paint), FID/INP (Interaction to Next Paint), and CLS (Cumulative Layout Shift). Websites that fail Core Web Vitals have a measurable disadvantage in Google search results, especially in mobile search.
For a complete review of Core Web Vitals and SEO impact, see our Core Web Vitals guide. And for the connection between performance and web design, see our performance guide.
Steps 1-2: Measure baseline with the right tools
Before you optimize, measure. You need a baseline to improve from. The three most important tools are: PageSpeed Insights (combines lab data from Lighthouse with field data from Chrome User Experience Report), GTmetrix (detailed waterfall diagram and historical tracking), and WebPageTest (advanced testing with different devices, networks, and locations).
Step 1: Run PageSpeed Insights on your five most important pages. Document LCP, FID/INP, and CLS for both mobile and desktop. Step 2: Run GTmetrix with a European server to see the waterfall diagram — this reveals exactly which resources delay page loading.
Establish a performance monitoring routine: check PageSpeed Insights weekly for key pages, and set up automated alerts in GTmetrix or SpeedCurve for performance regressions. Without measurement, you do not know if your changes actually improve anything.
Steps 3-6: Image optimization
Images typically make up 50-70 percent of a website's total weight (HTTP Archive, "State of Images"). Image optimization is almost always the easiest and most effective performance gain. Step 3: Compress all images — use Squoosh (web-based), ShortPixel (batch), or ImageOptim (Mac). Aim for visual quality of 80-85 percent for JPEG/WebP.
Step 4: Convert to modern formats. WebP provides 25-35 percent smaller files than JPEG at comparable quality. AVIF provides an additional 20 percent savings but has slower encoding. Use the picture element with fallback for avif, webp, and jpg.
Step 5: Implement responsive images with srcset and sizes. Step 6: Add loading="lazy" to all images below the fold, and fetchpriority="high" to the LCP image. These two attributes alone can improve LCP by 200-500ms on image-heavy pages.
- Step 3: Compress images to 80-85% quality (Squoosh, ShortPixel)
- Step 4: Convert to WebP/AVIF with picture element fallback
- Step 5: Responsive images with srcset and sizes
- Step 6: loading="lazy" below fold, fetchpriority="high" on LCP image
Steps 7-9: Font optimization
Web fonts can block rendering and add 100-300ms of load time. Step 7: Use font-display: swap in the @font-face declaration. This shows text immediately with a system font and swaps to the web font when loaded, instead of showing blank text (FOIT — Flash of Invisible Text).
Step 8: Preload critical fonts with link rel="preload". Only preload fonts used above the fold — typically 1-2 fonts. Too many preloads can actually delay loading of other resources.
Step 9: Subset fonts to only the characters you need. A full Google Font may contain hundreds of glyphs for languages you never use. Variable fonts can replace multiple font files (regular, bold, italic) with a single file.
Steps 10-13: JavaScript optimization
JavaScript is the most expensive resource byte-for-byte — it must be downloaded, parsed, compiled, and executed. Step 10: Add defer or async to all script tags that are not critical for initial rendering. defer loads the script in parallel but executes after HTML parsing. async loads and executes in parallel — use this only for independent scripts like analytics.
Step 11: Implement code splitting — divide the JavaScript bundle into smaller chunks loaded on demand. Next.js and other modern frameworks do this automatically per route. For single-page applications: dynamic import() for components not needed at page load.
Step 12: Remove unused JavaScript. Chrome DevTools Coverage tool shows exactly how much JavaScript is actually executed. According to HTTP Archive, the median unused JavaScript is 37 percent of total JavaScript. Step 13: Analyze bundle size with webpack-bundle-analyzer or Next.js @next/bundle-analyzer. Identify heavy dependencies and replace with lighter alternatives.
- Step 10: defer/async on non-critical scripts
- Step 11: Code splitting with dynamic import()
- Step 12: Remove unused JS — check with Coverage tool
- Step 13: Bundle analysis — replace heavy libraries
Steps 14-15: CSS optimization
CSS blocks rendering — the browser renders nothing until all CSS in head is loaded and parsed. Step 14: Extract critical CSS (CSS needed for above-the-fold content) and inline it directly in HTML. The rest of the CSS loads asynchronously. Tools like Critical (npm package) automate this.
Step 15: Remove unused CSS. PurgeCSS or Tailwind CSS built-in content configuration removes unused classes automatically in production builds. For Tailwind projects, this can reduce CSS from 3+ MB to under 10 KB.
CSS minification should happen automatically in the build process. All modern bundlers (Next.js, Vite, webpack) do this by default in production builds.
Steps 16-18: Server and infrastructure
Step 16: Enable compression. Brotli (newer, better compression) or gzip (wider support) compresses HTML, CSS, and JavaScript by 60-80 percent. Most hosting providers and CDNs support this.
Step 17: Configure cache headers correctly. Static resources (images, fonts, CSS, JS with hash in filename) should have Cache-Control: public, max-age=31536000, immutable. HTML pages should have Cache-Control: no-cache or short max-age with revalidation. Correct caching can eliminate 80-90 percent of requests for returning users.
Step 18: Use a CDN (Content Delivery Network) to serve static resources from servers near the user. Cloudflare (free plan available), Vercel Edge Network, and AWS CloudFront are popular choices. A CDN can reduce TTFB (Time to First Byte) by 50-70 percent for users far from the origin server.
Step 19: Third-party audit and facade pattern
Third-party scripts are often the hidden performance killer. Google Tag Manager, Facebook Pixel, Hotjar, Intercom, chat widgets, A/B testing tools — each script adds load time and can block the main thread. A typical marketing site can have 15-20 third-party scripts that together weigh more than the site's own code.
Step 19: Audit all third-party scripts. List each script, measure its performance impact (Chrome DevTools Performance tab), and assess whether the value justifies the cost. Tools you are not actively using should be removed immediately.
The facade pattern means showing a static preview of the widget and only loading the actual script when the user interacts with it. YouTube embeds are a classic example: show thumbnail and play button, load iframe only on click. See our technical SEO checklist for more on third-party optimization.
Step 20: WordPress/CMS-specific optimizations
For WordPress-based sites: Install a caching plugin like WP Rocket, W3 Total Cache, or LiteSpeed Cache. WP Rocket is easiest to configure and provides immediate improvement. Enable page caching, CSS/JS minification, lazy loading, and preloading of critical resources.
Image plugins: ShortPixel or Imagify for automatic compression and WebP conversion on upload. For themes: choose a lightweight theme — GeneratePress, Astra, or Kadence are faster than most "multipurpose" themes.
Remove unused plugins — each plugin adds CSS, JavaScript, and potentially database queries. For WooCommerce stores: use AJAX cart loading, optimize product image sizes, and consider moving checkout to a lighter template. For glossary definitions of Core Web Vitals, lazy loading, and CDN, see our glossary.
Performance budgeting and continuous monitoring
Performance optimization is not a one-time job — without active monitoring, performance regresses over time. Every new feature, image, plugin, and third-party script adds weight. A performance budget sets limits: total page size max 1.5 MB, JavaScript max 300 KB (compressed), LCP under 2.5 seconds, CLS under 0.1.
Integrate performance checks into the CI/CD pipeline. Lighthouse CI runs automated performance tests on every deploy and fails the build if performance drops below the threshold. SpeedCurve or Calibre provide continuous Real User Monitoring (RUM) with alerts.
At LeapJet, we run performance audits quarterly for all client sites and catch regressions with automated alerts. The performance budget is established at project start and monitored throughout the lifetime. For complete performance optimization, contact us via our web design services page.
- Set performance budget: Page size, JS weight, LCP, CLS
- Integrate Lighthouse CI in deploy pipeline
- Run PageSpeed Insights weekly on key pages
- Set up RUM with SpeedCurve, Calibre, or web-vitals library
- Audit third-party scripts quarterly
- Document baseline and improvements over time
