Free Site-Performance Wins: Speed Up Without Spending

A slow site gets closed by users and demoted by search engines. The good news: most performance optimizations are free — no services to buy. This post's order is: measure the bottleneck first, then act. Don't optimize by feel; feel lies, data doesn't. Walk through this once and a jump of tens of points is normal, without spending a cent.

Measure first: run PageSpeed Insights once

Open PageSpeed Insights, enter the URL, run it once. It gives you mobile and desktop scores plus exactly what's slow: images too big, too many scripts, or slow server response. Write down the score, run it again after optimizing, and compare. No measurement, no optimization — adding caches and switching servers by feel will most likely optimize nothing. Remember: the mobile score matters more than desktop; most of your users are on phones.

Images: the biggest slowness, cured free

Nine times out of ten, a slow personal site is slow because of images. Four free moves: compress (Squoosh online — invisible to the eye, half the size); right-size (if it displays at 800px wide, don't upload a 4000px original — shrink it first); lazy-load (images below the fold load when scrolled to — add loading="lazy" to the img tag); use WebP or AVIF formats — much smaller than JPEG, supported by all modern browsers. Those four cut image weight by 70%+

Hero background images are the worst offenders. That pretty above-the-fold background often eats half the load time. Replace it with text on a solid color if you can; if you must use it, compress under 200K. Remember: users come for the content, not your photography. Making users wait 3 extra seconds for looks is a bad trade.

Above the fold: make the biggest content text

PageSpeed has a metric called LCP (Largest Contentful Paint) that basically decides whether users feel “fast or slow.” Make the biggest above-the-fold content text instead of an image or video and LCP takes off. Write headlines and subheadlines as text, not images — search engines can't read text in images either; two wins. Above the fold holds only “things that help users decide”: a headline, a one-sentence intro, a button; the rest goes below.

Third-party scripts: one fewer is one fewer

Analytics, support, chat, share buttons… every third-party script is an extra network request and often blocks rendering. Count how many you load; cut half and the site gets noticeably faster. Use light analytics (Cloudflare's built-in is fine), delete unused social share buttons, add the chat widget only when users truly need it. Before adding each script ask: is the value it brings worth the speed it costs? If not, delete.

Don't embed videos directly either. YouTube or Bilibili embed players load a pile of scripts the moment they load. The approach: show a video cover image first, load the real player only when the user clicks. This small trick doubles the speed of video pages and improves UX — the cover loads fast, so users don't stare at a blank spinner.

Static assets: cache them on Cloudflare's free CDN

Images, CSS, JS — files that never change — let Cloudflare's free plan cache them. On repeat visits, files come from the node nearest the user instead of your server. With proxying on, caching is on by default; static assets get near-zero-cost acceleration. It's the best value of all free tricks: ten minutes to set up, benefits forever. Don't cache dynamic content — logged-in pages and API endpoints must be excluded; slower beats leaking data by a mile.

Compression and cache headers: turn them on at the server

Turn on gzip or brotli compression for text resources (HTML, CSS, JS) — 70% smaller; it's one line of config in Caddy or Nginx. Then add cache headers to static assets telling browsers “don't re-download this file for a week.” Both are configure-once-at-the-server, effective forever, done in ten minutes. Many people spend big on CDNs without even enabling compression on their own server — backwards.

Slow server response: check the database

If PageSpeed says server response time (TTFB) is too long, the problem is usually the database: a page scanning whole tables, missing indexes, or firing dozens of queries per page. Small personal sites have huge optimization headroom: paginate list pages, don't select fields you don't use, index slow queries. Dropping TTFB from 2 seconds to 200ms is the most noticeable win for users, because it's the “first byte” — everything else waits on it.

Fonts: use the system font stack, don't load whole Chinese font packs

Chinese font files run several megabytes — loading a whole pack is handing every user a big gift box. Use the system font stack (Apple's PingFang, Microsoft's YaHei, etc.) — they're on users' phones and computers already, zero load time. Don't be greedy with English fonts either — one weight is enough, don't load five. Fonts are the most hidden culprit of “slow,” because designers think they look good while users feel the lag. When pretty conflicts with fast, choose fast.

One last reminder: performance optimization is ongoing, not one-and-done. Every new feature, run PageSpeed once — if the score drops, you know this addition slowed it. Make “score doesn't drop” one of your launch gates and the site stays fast. Slowness accumulates; so does speed.

Above the fold: only three things

A headline, a one-sentence intro, a button — that's all above the fold; everything else scrolls down. Every extra element above the fold slows LCP a bit more. When users open a site, the first three seconds decide stay-or-go; in those three seconds they only need to know: what is this, what's in it for me, where to click. Everything else can wait until they scroll.

Lazy-load non-critical content

Comments, maps, video players — none of these are above-the-fold necessities; load them when scrolled to. Images get loading="lazy"; videos get a cover image with the real player loading on click. The principle: above the fold loads only “things that help users decide”; everything else waits its turn. Lazy-loading isn't cutting corners — it's putting the good steel on the blade.

Fewer requests: merge

Every network request has overhead; fewer requests are naturally faster. Inline small icons as SVG instead of one file per icon; merge CSS where you can. Don't split into dozens of tiny files “for modularity” — the browser fetching them one by one hurts. Build tools do this automatically; check your build config isn't slacking.

Preload critical resources

For above-the-fold images and critical fonts, use preload to tell the browser “this one first.” Don't overuse it — too many preloads equal no priority. Use it only for the one or two truly critical resources; everything else loads in normal order. Preloading is queue-jumping — when too many jump the queue, the queue breaks.

Animation: less is more

Too many animations stutter on low-end phones. Animate with transform and opacity — they don't trigger reflow and cost the least; animations changing width, height, or top can stutter into slideshows. Test on a three-year-old budget phone; smooth there is the real bar. Silky on your computer doesn't mean silky on users' phones.

Analytics scripts: pick light ones

Heavy analytics scripts are invisible killers: one GA plus a pile of plugins slowing things half a second is common. Personal sites do fine with Cloudflare's built-in analytics — light, cookie-free, fast. Move to the heavy stuff only when you truly need fine data; don't sacrifice today's speed for data you “might need someday.” Analytics serves people, not data.

Caching strategy: make the browser remember

Add Cache-Control to static assets telling browsers “don't re-download this file for a week.” Hash filenames on release (like app.a1b2c3.js) — when a file changes its name changes, and the browser naturally fetches the new one instead of using the stale cache. Build tools usually do this automatically; just check. With caching set, returning users open the site as fast as a local app.

Regular checkups: run the score monthly

Add a PageSpeed run to the monthly routine: run once at the start of the month and write down the score; run once when a new feature launches and investigate drops. New third-party scripts and new big images quietly slow sites down. The checkup's point is “catch it early”: fixing a 5-point slowdown is a wave of the hand; fixing a 30-point one is a big project.