Don't fight the browser preload scanner One overlooked aspect of optimizing page speed involves knowing a bit about browser internals. Browsers make certain optimizations to improve performance in ways that we as developers can't—but only so long as those optimizations aren't unintentionally thwarted. One internal browser optimization to understand is the browser preload scanner. This post will cover how the preload scanner works—and more importantly, how you can avoid getting in its way. What's a preload scanner? Every browser has a primary HTML parser that tokenizes raw markup and processes it into an object model. This all merrily goes on until the parser pauses when it finds a blocking resource, such as a stylesheet loaded with a element, or script loaded with a Injected scripts are async by default, so when this script is injected, it will behave as if the async attribute was applied to it. That means it will run as soon as possible and not block rendering. Sounds optimal, right? Yet, if you presume that this inline This is the result: A WebPageTest network waterfall depicting how an async script loaded by using the HTML Fig. 6: A WebPageTest network waterfall chart of a web page run on Chrome on a mobile device over a simulated 3G connection. The page contains a single stylesheet and a single async