Skip to content

1 Answer

Accepted answer

PSPriya Singh6.2K XP1mo ago
Measure first, then fix the biggest item — almost every slow site is slow for one or two dominant reasons, and guessing usually leads to optimising something that accounts for 3% of the problem. Run PageSpeed Insights and open the Network tab in DevTools; sort by size and by time. The answer is nearly always visible within a minute. The fixes ranked by how often they're the actual problem: 1. **Images.** This is the single most common cause by a wide margin. A 4MB photo scaled down in CSS still downloads all 4MB. Fixes: resize images to the size they're actually displayed, use modern formats (WebP or AVIF — typically 30-50% smaller than JPEG), compress them, and add `loading="lazy"` to images below the fold so they don't block the initial load. 2. **Too much JavaScript.** Every kilobyte must be downloaded, parsed and executed before the page becomes interactive. Audit your dependencies — importing an entire library for one function is extremely common. Code-split so each page only loads what it needs, and defer non-critical scripts. 3. **Render-blocking resources.** CSS and synchronous scripts in the `<head>` stop the page rendering until they finish. Inline the critical CSS, defer the rest, add `defer` or `async` to scripts. 4. **No caching or compression.** Enable gzip/Brotli compression on the server (often a one-line config, typically 60-80% smaller text files) and set long cache headers on static assets. Frequently the cheapest big win available. 5. **Fonts.** Custom fonts block text rendering. Use `font-display: swap`, preload the main font file, and limit yourself to two or three weights instead of nine. 6. **Slow server or database.** If the HTML itself takes over half a second to arrive, the problem is behind the scenes — usually an unindexed database query or an N+1 query pattern, not the front end at all. 7. **Third-party scripts.** Analytics, chat widgets, ad tags and embeds are frequently the slowest things on a page and the easiest to overlook because they're 'not your code'. Audit them ruthlessly; each one is a request to a server you don't control. A CDN helps if your users are geographically distant from your server — it serves static assets from a location near them, which cuts latency substantially and is usually easy to enable. One framing that keeps priorities straight: users perceive the time until they see meaningful content and the time until they can interact. Optimising something that happens after both has almost no perceptual benefit, however good it looks in a report. Fix the images first — it's the boring answer and it's right most of the time.
86

Know the answer?

Join Nobink to answer, vote and build your reputation.