Skip to content 
Forget HTTP/2 Server Push. Here’s the Real Way to Make Your Site Blazing Fast.
Understanding the right tool for website speed is crucial. You know that annoying moment. You click a link, the page starts to load, but the text looks all wrong for a second. Or you’re staring at a white screen, waiting for something, anything, to appear. For years, we were told HTTP/2 Server Push would solve this. The idea was genius, the server would just shove critical files at your browser before it even asked. No more waiting.
Here’s the truth no one likes to admit: HTTP/2 Server Push was a total flop. It’s deprecated, turned off in most browsers, and honestly, it was a nightmare to get right. Half the time, it made things slower.
So, are we stuck with slow-loading fonts and render-blocking scripts? Not even close. While everyone was arguing about server push, a much smarter, simpler tool was hiding in plain HTML: the <link rel="preload"> tag. This is the modern solution that actually works.
This isn’t some complex server hack. It’s you having a direct chat with the browser. It’s you saying, “Hey, I know you’re going to need this file in about two seconds. Go grab it right now, and put it at the front of the line.”
Why HTTP/2 Server Push Failed (And Created Problems)
Think of your browser like a careful chef following a recipe (your HTML). It won’t start chopping the onions (loading a font) until the recipe explicitly says “now chop onions.” This step by step process is the “critical rendering path.” If the onions are at the back of the pantry (a slow server), the whole meal gets held up.
HTTP/2 Server Push was like an overeager sous-chef who starts throwing ingredients at the chef before they’re needed. Sometimes it helps, but often you get onions in the dessert because the chef already had some.
The problems were huge, as documented in many web performance post mortems:
- It wasted data by pushing files people already had cached.
- It clogged the pipeline, blocking more important requests.
- Setting it up was way too complicated and nearly impossible to debug.
We needed a solution that worked with the browser, not against it. That’s where the <link rel="preload"> tag comes in.
Mastering the <link rel="preload"> Tag
Forget “push.” Think “priority pass.” When you use the <link rel="preload"> tag, you’re not forcing anything. You’re giving the browser a friendly, high-priority heads up.
You stick this tag in your <head>, and the browser thinks, “The developer says this is urgent. I’ll fetch this immediately, even before I finish parsing the rest of the page.” By the time the browser naturally stumbles upon the <script> or <link> tag for that resource, it’s already sitting in the cache. The wait time? Zero.
Here’s how you write it:
html
<link rel="preload" href="super-important-font.woff2" as="font" type="font/woff2" crossorigin> <link rel="preload" href="critical-styles.css" as="style"> <link rel="preload" href="hero-photo.jpg" as="image">
The magic is in the as attribute. You must use it. This tells the browser what it’s fetching so it can prioritize correctly. Telling the browser it’s a font lets it jump the queue ahead of a regular image. This one attribute is the secret to shaving milliseconds off your load time, especially for your Core Web Vitals like Largest Contentful Paint (LCP). For a deep dive on the as attribute and its values, the MDN Web Docs provide an excellent resource.
HTTP/2 Server Push vs. <link rel="preload">: The Clear Winner
Let’s make this simple. Here’s why the <link rel="preload"> tag is what you should use today:
| The Problem | HTTP/2 Server Push | <link rel="preload"> tag |
|---|---|---|
| Who’s in control? | The server admin. You have to beg your hosting company or mess with complex configs. | You, the developer. Just write an HTML tag. |
| Does it waste bandwidth? | Constantly. It famously pushed cached files. | Nope. The browser checks its cache first. If it’s there, the hint is ignored. Smart. |
| Is it easy to debug? | A nightmare. Good luck figuring out what went wrong. | Easy. Open DevTools, go to the Network tab, and look for the little “preload” marker. |
| Does every browser support it? | No. Chrome and Firefox dropped it. Safari never had it. | Yes. It works everywhere. |
The bottom line? The <link rel="preload"> tag is reliable. HTTP/2 Server Push was a science experiment that failed.
How to Use the <link rel="preload"> Tag Correctly
Don’t just preload everything. That’s like yelling “priority!” for every item in the grocery store. You’ll just create a new traffic jam. Be strategic. Use your browser’s DevTools (the Coverage tab is great) to find the truly critical, render-blocking files.
Use Case 1: Fixing That “Flash of Wrong Text”
If your custom font loads late, causing text to “flash” from a default font to your fancy one, the <link rel="preload"> tag is the cure.
html
<head> <!-- First, connect early to the font server --> <link rel="preconnect" href="https://fonts.gstatic.com"> <!-- Then, preload the specific font file --> <link rel="preload" href="https://fonts.gstatic.com/s/opensans/v34.woff2" as="font" type="font/woff2" crossorigin> <!-- Now, request the full font family as you normally would --> <link href="https://fonts.googleapis.com/css2?family=Open+Sans&display=swap" rel="stylesheet"> </head>
Use Case 2: Critical Hero Images
If a massive banner image is the first thing people see (your LCP), using the <link rel="preload"> tag tells the browser to start downloading immediately.
html
<link rel="preload" href="hero-banner.avif" as="image" imagesrcset="banner-small.avif 600w, banner-large.avif 1200w">
Common <link rel="preload"> Tag Mistakes
- The
asAttribute is Not Optional. Leaving it out is like marking a package “URGENT” but not saying if it’s medicine or a pizza. The browser will treat it as low priority. - Don’t Go Overboard. Preload only 2-3 of the most critical resources. More than that and you’re just creating noise.
- Fonts Need
crossorigin. This one gets everyone. For fonts, even from your own domain, always addcrossorigin. Otherwise, the browser will fetch the font twice. - Preload is for Fetching, Not Running. Preloading a JavaScript file just downloads it. It won’t execute. You still need your normal
<script>tag for that.
The Big Picture: The <link rel="preload"> Tag in Your Toolbox
The <link rel="preload"> tag isn’t a magic spell. It’s one powerful tool in a whole kit, which you can explore in comprehensive performance guides:
- Use
preconnectto set up early connections to critical third party sites. - Use
loading="lazy"for images that are below the fold. - Use modern image formats like WebP or AVIF.
The Takeaway: Ditch HTTP/2 Server Push, Master <link rel="preload">
The story of HTTP/2 Server Push teaches us a good lesson, complexity usually backfires. The web works best with simple, clear instructions.
Mastering the <link rel="preload"> tag is about finally taking control of your site’s first impression. You’re using your knowledge of what the page needs to give the browser a smart, strategic head start. No guesswork, no complex configs, just a clean, effective hint that turns a laggy page into a snappy one. The tool has been right there in your HTML all along. Time to use it.
New to HTML? Start Here: HTML Tutorial for Beginners: Your Complete Introduction to HTML Basics
[INSERT_ELEMENTOR id=”122″]
