We’ve all learned by now that websites need to be fast. The time-to-first-response from a serve is measured by Google, and slow-responding sites get penalized. Mobile browsers whose patience is measured in single-digit amounts of seconds are quite likely to end up on your desktop-oriented website if you’re not careful, and those don’t like to play at cellular speeds.
So how can you improve the speed of your website when you’ve already done everything you can server-side, cached as aggressively as you can, used CSS sprites, and pulled every trick in the book to reduce loading times? By prebrowsing — in other words, using mouseover and other triggers to start the page on the other side of a link to start loading before the link is ever clicked.
<link rel=”dns-prefetch” href=”X”>
The power of rel=”dns-prefetch” shouldn’t be ignored. Essentially, what it tells your browser to do is engage its own internal DNS pre-resolution engine (which almost all modern browsers have) without waiting for the user to get their mouse near the link. It can shave a half-second or more off of your load times if the link goes through a redirect or two before arriving at its destination, and that’s something worth celebrating.
The best part about this little nudge is that browsers that support it — which is most of them — will handle it easily, while older browsers will simply ignore it. There’s no effort needed, and it’ll improve load times for things like Javascript and external-domain analytics and social sharing code.
<link rel=”prefetch” href=”X”>
As you might imagine, if dns-prefetch tells the browser to pre-resolve the domain name(s) of everything on the other side of a link, a straight-up re=”prefetch” tells the browser to go ahead and go get whatever’s on the other side of the link and store it in the cache for quick access.
Needless to say, you don’t want to get overaggressive with this feature — the last thing you want is to make some poor mobile browser waste their limited bandwidth preloading items they’ll never actually get out of the cache. That said, if there’s a very logical flow to your page — say, because it’s a sales funnel — there’s little reason to not preload the next step’s fonts, CSS, Javascript, and image files.
<link rel=”prerender” href=”X”>
Now for the big pappy of all prebrowsing: the rel=”prerender” command will fully download and even render the page in the background while they brows the page they’re currently on. Assuming they browse the existing page for long enough for the prerender to complete, the switch from the existing page to the next page would be literally immediate.
Prerendering is only supported on Chrome and IE11 at the moment, but support is becoming more commonplace. If your analytics tell you that you can predict with near-certainty where a browser is going to go from a given page, prerendering the next step in the process can keep the user engaged and keep them from getting distracted during load time — again, especially useful in a sales funnel kind of situation.
Prebrowsing is a power that must be used wisely to prevent a user from spending a lot of resources loading things they’ll never see — but used wisely, it can do an immense amount to reduce or even eliminate load time, which is a pure bonus in terms of the final user experience.
Leave a Reply: