The new Google Chrome technology can play a supporting role in optimizing for first paint or Start Render Time, but that’s it.

I love comparing IT to automobiles. Have you ever seen someone who’s bought some “racing” kit for his/her car without actually making the car race-ready? Some marvel of modern automotive technology comes out, becomes consumerized, and is assumed to work in a vacuum to change the behavior of something it wasn’t designed to change. Enter the latest web technology innovation from Google: Reactive Prefetch.

Lest you misinterpret my snark as open derision, I’ll note that I do think Reactive Prefetch is a very cool idea.  But because I’m writing for Yottaa, where we focus on optimizing web apps so businesses can optimize their EUE, Reactive Prefetch makes me think of a teenager who’s bolted an NoS canister to his Honda Civic.  He thinks it will help him race like the actors in the Fast and Furious franchise movies when really the NoS won’t do much else than help burn out his clutch, bald his tires, and overheat his brakes. He won’t win any races unless the rest of the car is adapted to take advantage of the extra power.

For web apps, from both performance and business channel optimization perspectives, the most relevant takeaway is simple:

Reactive Prefetch will do literally nothing to optimize your web app.

Why? It’s simple: reactive prefetch will proactively retrieve static assets required by the target page before the user clicks on a link. That means:

• If you’ve performed a Google search using Chrome (and at present only if you’re on an Android mobile device, though the impact will be no more impactful once this makes it to every mobile OS and to the desktop), reactive prefetch will do what your CDN is doing for you already. But only for that one page.
• Subsequent clicks (what business analytics users think of as increasing page depth) will not benefit from reactive prefetching because the optimization requires Chrome+Google Search. The gaps in the user experience will remain.
• Pages that require dynamic content – things like JavaScripts or database queries – will not realize a benefit because Google Search can’t proactively cache dynamic personalized or localized content. The page load will still be bottlenecked or blocked when the requests for dynamic content occur.
• Non-optimized assets will still slow you down too. If you aren’t adaptively serving images and other content based on the end user’s device – taking into account device capability and visible viewport area – reactive prefetch won’t help there either. Chrome will right-size images for you when it’s rendering the page, but it will download the full image first.

Reactive prefetch can play a supporting role in optimizing for first paint or Start Render Time, and it’s an interesting bit of technology from Google. If your web app is like a race-tuned car – the kind the stunt drivers actually drive in Fast and Furious movies – you may realize some incremental improvement when the referrer is a Google search (on Android for now) and if you’re not using a CDN or only using a CDN to optimize content. But to realize business channel improvements from optimizing EUE, you need to implement a holistic web application optimization strategy.

Photo: via Flirk user pb2