A common misconception is that this performance only impacts highly sophisticated web applications, such as web-based games or online image editors. This is definitely not the case – the slower hardware impacts practically every web page, and to a significant extent.
To test that, we measured the Top 100 Sites in the US (as defined by Alexa) on iPhone 4, iPhone 4S and an iPhone Simulator running on a recent MacBook Pro. All tests were using iOS 5. To use the simulator, iPhone applications are recompiled for the host’s architecture, so each test was leveraging its local hardware. Lastly, we ran the tests over a fast network and overnight, to reduce any other variability.
- Loading a web page ahead of time in a headless browser (in the relevant context)
- Applying any changes it would make to the HTML content itself
- Removing code that is fully utilized, and modifying the rest to avoid duplicating the dynamic content
- Making the remaining code asynchronous
Let’s break down each of these steps.
Step #3 is closely tied to the way Blaze works, and creates Transformation Instructions that will guide the Blaze agents on how to modify the page in real time. The analysis itself is not done every time the page is fetched, but rather every time the page changes substantially. The conclusions drawn from the analysis are applied to every single page view, and are designed to work well with dynamic and personalized content.
Step #4 uses algorithms and user configuration to decide whether a script was executed to completion, and can be entirely removed from the page. Even if the scripts are left on the page, they are modified to ensure the dynamic content isn’t generated again on the client side.
Step #5 is the last step, where any remaining scripts are made asynchronous. These scripts will still suffer from the performance challenges the mobile web presents, but at least they won’t slow down the page load. Since all or most of the dynamic content has been generated already, in most cases the user would get a visually complete and usable page before they finish processing.
Can everything be Pre-Executed?
No, some scripts cannot be pre-executed, but often times at least parts of the script can be processed ahead of time.
For instance, Google Analytics has to run on the actual browser each time. However, the integration script Google recommends dynamically adds the analytics code to seamlessly handle http and https content with one script. Pre-Executing the script can turn that link into an embedded link, and allow browsers to process it more intelligently.
Running scripts asynchronously is a great way to keep the scripts from delaying other parts of the page. However, on many pages – mobile and desktop alike – scripts create content that is necessary for the page to be usable by the user. Running the scripts asynchronously can therefore make the user experience no better, and sometimes worse, than it was before.
The Cherry On Top