How Do Preload and Prefetch Improve Mobile Speed? Google Hackathon on AIR

TL;DR

Preload and prefetch improve mobile speed by telling the browser which resources to retrieve now and which to prepare for later. The Google Hackathon on AIR session distinguishes DNS-prefetch, preconnect, preload, prefetch, and prerender according to timing, priority, and cost. With 53% of consumers abandoning pages that take longer than three seconds to load, read on to learn how each hint supports faster rendering.

Transcript

DENNIS RASPOTNIG: Hi, guys. Sorry for that. We had a small delay here, but are ready to get going. We know there were a couple of people already waiting. So we hope that everybody can hear us can see us, and we will obviously share the slide deck as well with you guys very soon. So we're back after a couple of weeks now. Going into the next topic o... Read More

Key Insights

• Priorities shape perceived performance: The session moves beyond reducing file sizes and asks whether the browser is loading resources in the order that best serves the page. A smaller resource is not automatically the most important one. By identifying the assets needed for early rendering, developers can direct attention toward what users must see first and postpone resources that matter less in that moment.
• Three seconds define urgency: The speakers cite anonymized Google Analytics data showing that 53% of consumers abandon a site when loading takes longer than three seconds. Dominik Heyberg presents this as an average rather than a guaranteed result for every site. Even if a specific site loses 20% or 25%, losing every fourth visitor during the opening seconds remains a serious problem.
• Rendering beats a blank screen: The central concern is not only when every page asset finishes downloading. Users may leave while the screen remains blank and content has not begun rendering. The session therefore emphasizes the critical rendering path and speed index. Getting meaningful content onto the screen sooner creates a better chance of retaining visitors who might otherwise choose another provider.
• DNS work can start early: DNS-prefetch removes one preliminary delay by resolving a domain name before the browser needs a resource hosted there. When the request is eventually made, the domain resolution step has already occurred. This is useful when the page can identify external domains in advance, allowing the browser to prepare without retrieving the complete resource prematurely.
• Preconnect prepares the transport: Preconnect performs more work than DNS-prefetch because it establishes a socket connection and carries out TLS negotiation before the resource is required. This can make externally hosted assets available sooner once the page asks for them. The session highlights web fonts as a practical use case because delayed font access can hold back the appearance of rendered content.
• Preload serves the current page: A preload hint is intended for a high-priority resource that the active page will need. It fetches that resource asynchronously and helps prevent it from blocking rendering when it becomes necessary. The technique is most valuable when developers can accurately identify critical assets, since preloading noncritical files can spend bandwidth without improving the part of the experience users encounter first.
• Prefetch anticipates later navigation: Prefetch is designed for a lower-priority resource that is not immediately required but is likely to be used after the user moves to another page. The browser retrieves and caches it ahead of that future need. Applied to a predictable funnel, this approach can make later steps feel faster while preserving priority for the resources required by the current page.
• Preload and prefetch differ: The dividing line between these hints is both priority and timing. Preload targets important resources for the page currently being rendered, while prefetch prepares lower-priority resources for a subsequent navigation. Treating the two as interchangeable would weaken the prioritization strategy because the browser needs to know whether an asset supports the immediate view or a likely future action.
• Prerender carries greater cost: Prerendering prepares an entire possible next page and all of its assets, not merely a selected resource. That breadth can produce a very fast transition when the prediction is correct, but it also makes the method resource-intensive. If the user chooses another path, the downloaded work may be wasted and may consume bandwidth unnecessarily, especially on a mobile connection.
• Prediction requires behavioral evidence: The stronger the optimization hint, the more confidence developers need about what the user will do next. Prefetching and especially prerendering depend on anticipating later navigation. Analysis of user behavior helps identify probable resources or pages, so preparation is directed toward likely needs instead of consuming bandwidth for speculative paths that users rarely follow.
• Browser support changes implementation: The session notes that support is not uniform across the pre family. DNS-prefetch and preconnect are widely supported, while preload and prerender have more limited compatibility. Developers therefore need to consider whether a browser recognizes each hint and provide fallbacks where appropriate. A technique cannot improve the experience if the user’s browser cannot apply it as intended.
• Community questions extend the series: Dennis Raspotnig and Dominik Heyberg invite viewers to submit questions during the live Hangout, including broader speed questions that are not fully related to preload or prefetch. Questions may be answered during the session, addressed by peers in the chat, or developed into a later Hackathon on AIR topic. The series is positioned as a forum for sharing mobile performance practices and ideas.

Questions & Answers

Q: What is the difference between preload and prefetch?

Preload retrieves a high-priority resource required by the current page, while prefetch prepares a lower-priority resource for a later navigation. Preload works asynchronously so an important asset can arrive without becoming render-blocking when the page needs it. Prefetch places an anticipated resource in the cache so a likely next step can load faster. The distinction matters because current rendering should receive priority over speculative future needs.

Q: How do preload and prefetch improve mobile web speed?

They give the browser information about when resources will be needed and how important those resources are. Preload brings forward critical assets for the active page, helping content render sooner. Prefetch uses otherwise available time to cache assets that are likely to support the user’s next navigation. Together, they align network work with both the immediate page and the anticipated journey instead of treating every request as equally urgent.

Q: What does DNS-prefetch do?

DNS-prefetch resolves a domain name before the page requests a resource from that domain. This removes the need to wait for domain resolution when the actual request begins. It is useful when a page already knows that it will depend on assets hosted elsewhere. The benefit comes from completing a necessary setup step early without loading the full resource at that moment.

Q: How does preconnect improve loading performance?

Preconnect establishes the socket connection and performs TLS negotiation before an external resource is needed. When the page later requests that resource, some of the connection setup has already finished. The session identifies web fonts as a useful example because they need to become available quickly for rendering. Preconnect therefore reduces the delay between deciding to fetch an important external asset and beginning its transfer.

Q: When should a page use prerendering?

Prerendering should be used when there is high confidence that the user will visit a particular page next. It loads that page and all of its assets in advance, which can make the predicted navigation fast. The method is resource-intensive, so an incorrect prediction wastes work and bandwidth. That cost is particularly important on mobile networks, which is why the session recommends applying prerender cautiously.

Q: Why is user behavior important for resource hints?

User behavior reveals which pages and resources people are most likely to need next. That evidence helps developers choose realistic targets for prefetching or prerendering instead of preparing arbitrary paths. Accurate anticipation can maintain a fast experience through later navigation and across a conversion funnel. Poor anticipation can waste bandwidth, so behavioral understanding is what connects these techniques to genuine user needs.

Q: What browser support issues affect the pre family?

Support differs among DNS-prefetch, preconnect, preload, prefetch, and prerender. The session describes DNS-prefetch and preconnect as widely supported, while preload and prerender have more limited support. Developers should therefore verify that their chosen hints can operate in the browsers serving their users. Fallbacks are important because an optimization that is not recognized should not prevent the page from loading its required resources normally.

Q: Why does the Google Hackathon on AIR focus on the first three seconds?

The session cites anonymized Google Analytics data showing that 53% of consumers abandon a site when it takes longer than three seconds to load. Dominik Heyberg explains that this is an average across verticals and on a global scale, not a fixed result for every individual site. Even a lower abandonment level of 20% or 25% would mean losing a substantial share of visitors early. Faster rendering reduces the time users face a blank screen and gives the site a better chance to retain them.

Summary & Key Takeaways

• Why mobile speed matters: Dennis Raspotnig and Dominik Heyberg open the Google Hackathon on AIR session by framing speed as a major part of the mobile experience. Research discussed in the session indicates that waiting for a slow page is a leading user annoyance and a reason people abandon one provider for another. An anonymized analysis of Google Analytics data across verticals and regions found that 53% of consumers leave when a page takes longer than three seconds to load.

• Changing the optimization angle: Earlier sessions concentrated on making individual assets smaller, optimizing images, deferring JavaScript, and extracting further CSS improvements. This session instead examines the browser hints called the pre family. The aim is to load the right resources at the right time, especially for mobile users. Rather than treating every request equally, developers should identify the job a page serves, determine which resources matter most for that job, and prioritize them over less important resources.

• Starting connections before requests: DNS-prefetch resolves a domain name before a resource from that domain is requested. Preconnect goes further by establishing the socket connection and completing TLS negotiation early. These hints reduce setup work that would otherwise delay an important request. Preconnect is especially useful for resources such as web fonts, which must be available quickly for rendering. Both techniques are described as widely supported, making them practical options when a page depends on resources hosted on other domains.

• Separating current and future needs: Preload retrieves high-priority resources required by the current page, doing so asynchronously so those resources do not become render-blocking. Prefetch handles lower-priority resources that are expected during a later navigation and places them in the cache. This distinction connects resource priority to the user journey. Preload accelerates resources that affect the page being viewed, while prefetch prepares for the next likely step and can preserve a fast experience throughout a conversion funnel.

• Using stronger hints carefully: Prerender loads a possible next page together with all of its assets, making it more resource-intensive than the other techniques. It should therefore be reserved for situations where the next navigation is highly predictable. Otherwise, it can consume unnecessary bandwidth, particularly on mobile networks. Browser support also varies across the pre family, with preload and prerender having more limited support than DNS-prefetch and preconnect. Effective use ultimately depends on understanding likely user behavior and providing suitable fallbacks.