Performance
Website speed optimization: a practical guide
What Core Web Vitals actually measure, how to diagnose a slow website, and the fixes that produce the biggest gains in the least time.
10 min de lectura
Los artículos están escritos solo en inglés. El resto de la web sí está en tu idioma.
Speed affects rankings, bounce rate and revenue, and unlike most improvements it is unambiguous: either the page arrives quickly or it does not. This is the order we work in during a performance engagement.
What Google actually measures
- Largest Contentful Paint (LCP): how long until the main content appears. Target under 2.5 seconds; we aim under 1.5.
- Interaction to Next Paint (INP): how quickly the page responds to a tap. Target under 200 milliseconds.
- Cumulative Layout Shift (CLS): how much the layout jumps while loading. Target under 0.1.
Measure on mobile, on a throttled connection, on a mid-range device. A desktop score on office wifi tells you nothing about the experience most of your visitors have.
Step 1: diagnose before you touch anything
Run PageSpeed Insights on your five most important pages and record the mobile numbers. Then check the Core Web Vitals report in Search Console, which uses real visitor data rather than a lab test. If the two disagree, trust the field data.
Step 2: fix the images
On most business websites, images are 60 to 80 percent of page weight and the direct cause of a failing LCP. In order of impact:
- Serve modern formats. WebP or AVIF instead of JPEG and PNG typically cuts file size 30 to 60 percent at identical visual quality.
- Size them correctly. A 4000-pixel-wide photo displayed at 800 pixels wastes 90 percent of its bytes. Serve responsive sizes.
- Lazy-load anything below the fold, and explicitly do not lazy-load your hero image.
- Set width and height on every image so the browser reserves space and CLS stops.
- Compress deliberately. Quality 75 to 82 is usually indistinguishable from 100 and a fraction of the weight.
Step 3: fix the fonts
Self-host rather than calling a third-party font service, subset to the characters you actually use, preload the one or two faces used above the fold, and always set font-display: swap so text is readable while the font loads.
Step 4: reduce the JavaScript
Audit what is loading. Chat widgets, analytics stacks, heat mapping, A/B tools, tag managers, social embeds and carousel libraries commonly add one to three megabytes between them. Remove what you do not use. Defer what is not needed for first paint. Load chat and marketing scripts after interaction.
Step 5: fix delivery
- Enable Brotli or gzip compression at the server
- Set long cache lifetimes on static assets with content hashing
- Serve from a CDN so bytes travel from a data center near the visitor
- Enable HTTP/2 or HTTP/3
- Reduce redirect chains - each hop is a round trip
Step 6: fix the platform, if the platform is the problem
Sometimes the theme and plugin stack cannot get fast. Twenty-eight plugins each loading their own CSS and JavaScript on every page has a floor, and it is not a good floor. At that point rebuilding on a modern framework is cheaper than continuing to optimize.
Step 7: defend the result
Speed regresses. Someone uploads a 6MB photo, a new tracking script arrives, a plugin update ships extra CSS. Set a performance budget, check it monthly, and treat a breach as a bug rather than a preference.
Almost every slow website we audit is slow for the same three reasons: oversized images, unnecessary JavaScript, and nobody watching.
