You are previewing High Performance JavaScript.

High Performance JavaScript

Cover of High Performance JavaScript by Nicholas C. Zakas Published by O'Reilly Media, Inc.
  1. High Performance JavaScript
    1. SPECIAL OFFER: Upgrade this ebook with O’Reilly
    2. Preface
      1. The Internet Evolves
      2. Why Optimization Is Necessary
      3. Next-Generation JavaScript Engines
      4. Performance Is Still a Concern
      5. How This Book Is Organized
      6. JavaScript Loading
      7. Coding Technique
      8. Deployment
      9. Testing
      10. Who This Book Is For
      11. Conventions Used in This Book
      12. Using Code Examples
      13. Safari® Books Online
      14. How to Contact Us
      15. Acknowledgments
    3. 1. Loading and Execution
      1. Script Positioning
      2. Grouping Scripts
      3. Nonblocking Scripts
      4. Summary
    4. 2. Data Access
      1. Managing Scope
      2. Object Members
      3. Summary
    5. 3. DOM Scripting
      1. DOM in the Browser World
      2. DOM Access and Modification
      3. Repaints and Reflows
      4. Event Delegation
      5. Summary
    6. 4. Algorithms and Flow Control
      1. Loops
      2. Conditionals
      3. Recursion
      4. Summary
    7. 5. Strings and Regular Expressions
      1. String Concatenation
      2. Regular Expression Optimization
      3. String Trimming
      4. Summary
    8. 6. Responsive Interfaces
      1. The Browser UI Thread
      2. Yielding with Timers
      3. Web Workers
      4. Summary
    9. 7. Ajax
      1. Data Transmission
      2. Data Formats
      3. Ajax Performance Guidelines
      4. Summary
    10. 8. Programming Practices
      1. Avoid Double Evaluation
      2. Use Object/Array Literals
      3. Don’t Repeat Work
      4. Use the Fast Parts
      5. Summary
    11. 9. Building and Deploying High-Performance JavaScript Applications
      1. Apache Ant
      2. Combining JavaScript Files
      3. Preprocessing JavaScript Files
      4. JavaScript Minification
      5. Buildtime Versus Runtime Build Processes
      6. JavaScript Compression
      7. Caching JavaScript Files
      8. Working Around Caching Issues
      9. Using a Content Delivery Network
      10. Deploying JavaScript Resources
      11. Agile JavaScript Build Process
      12. Summary
    12. 10. Tools
      1. JavaScript Profiling
      2. YUI Profiler
      3. Anonymous Functions
      4. Firebug
      5. Internet Explorer Developer Tools
      6. Safari Web Inspector
      7. Chrome Developer Tools
      8. Script Blocking
      9. Page Speed
      10. Fiddler
      11. YSlow
      12. dynaTrace Ajax Edition
      13. Summary
    13. Index
    14. About the Author
    15. Colophon
    16. SPECIAL OFFER: Upgrade this ebook with O’Reilly

Chapter 1. Loading and Execution

JavaScript performance in the browser is arguably the most important usability issue facing developers. The problem is complex because of the blocking nature of JavaScript, which is to say that nothing else can happen while JavaScript code is being executed. In fact, most browsers use a single process for both user interface (UI) updates and JavaScript execution, so only one can happen at any given moment in time. The longer JavaScript takes to execute, the longer it takes before the browser is free to respond to user input.

On a basic level, this means that the very presence of a <script> tag is enough to make the page wait for the script to be parsed and executed. Whether the actual JavaScript code is inline with the tag or included in an external file is irrelevant; the page download and rendering must stop and wait for the script to complete before proceeding. This is a necessary part of the page’s life cycle because the script may cause changes to the page while executing. The typical example is using document.write() in the middle of a page (as often used by advertisements). For example:

   <title>Script Example</title>
  <script type="text/javascript">
    document.write("The date is " + (new Date()).toDateString());

When the browser encounters a <script> tag, as in this HTML page, there is no way of knowing whether the JavaScript will insert content into the <p>, introduce additional elements, or perhaps even close the tag. Therefore, the browser stops processing the page as it comes in, executes the JavaScript code, then continues parsing and rendering the page. The same takes place for JavaScript loaded using the src attribute; the browser must first download the code from the external file, which takes time, and then parse and execute the code. Page rendering and user interaction are completely blocked during this time.


The two leading sources of information on JavaScript affecting page download performance are the Yahoo! Exceptional Performance team ( and Steve Souders, author of High Performance Web Sites (O’Reilly) and Even Faster Web Sites (O’Reilly). This chapter is heavily influenced by their combined research.

Script Positioning

The HTML 4 specification indicates that a <script> tag may be placed inside of a <head> or <body> tag in an HTML document and may appear any number of times within each. Traditionally, <script> tags that are used to load external JavaScript files have appeared in the <head>, along with <link> tags to load external CSS files and other metainformation about the page. The theory was that it’s best to keep as many style and behavior dependencies together, loading them first so that the page will come in looking and behaving correctly. For example:

   <title>Script Example</title>
   <-- Example of inefficient script positioning -->
   <script type="text/javascript" src="file1.js"></script>
   <script type="text/javascript" src="file2.js"></script>
   <script type="text/javascript" src="file3.js"></script>
   <link rel="stylesheet" type="text/css" href="styles.css">
  <p>Hello world!</p>

Though this code seems innocuous, it actually has a severe performance issue: there are three JavaScript files being loaded in the <head>. Since each <script> tag blocks the page from continuing to render until it has fully downloaded and executed the JavaScript code, the perceived performance of this page will suffer. Keep in mind that browsers don’t start rendering anything on the page until the opening <body> tag is encountered. Putting scripts at the top of the page in this way typically leads to a noticeable delay, often in the form of a blank white page, before the user can even begin reading or otherwise interacting with the page. To get a good understanding of how this occurs, it’s useful to look at a waterfall diagram showing when each resource is downloaded. Figure 1-1 shows when each script and the stylesheet file get downloaded as the page is loading.

JavaScript code execution blocks other file downloads

Figure 1-1. JavaScript code execution blocks other file downloads

Figure 1-1 shows an interesting pattern. The first JavaScript file begins to download and blocks any of the other files from downloading in the meantime. Further, there is a delay between the time at which file1.js is completely downloaded and the time at which file2.js begins to download. That space is the time it takes for the code contained in file1.js to fully execute. Each file must wait until the previous one has been downloaded and executed before the next download can begin. In the meantime, the user is met with a blank screen as the files are being downloaded one at a time. This is the behavior of most major browsers today.

Internet Explorer 8, Firefox 3.5, Safari 4, and Chrome 2 all allow parallel downloads of JavaScript files. This is good news because the <script> tags don’t necessarily block other <script> tags from downloading external resources. Unfortunately, JavaScript downloads still block downloading of other resources, such as images. And even though downloading a script doesn’t block other scripts from downloading, the page must still wait for the JavaScript code to be downloaded and executed before continuing. So while the latest browsers have improved performance by allowing parallel downloads, the problem hasn’t been completely solved. Script blocking still remains a problem.

Because scripts block downloading of all resource types on the page, it’s recommended to place all <script> tags as close to the bottom of the <body> tag as possible so as not to affect the download of the entire page. For example:

   <title>Script Example</title>
   <link rel="stylesheet" type="text/css" href="styles.css">
  <p>Hello world!</p>

   <-- Example of recommended script positioning -->
   <script type="text/javascript" src="file1.js"></script>
   <script type="text/javascript" src="file2.js"></script>
   <script type="text/javascript" src="file3.js"></script>

This code represents the recommended position for <script> tags in an HTML file. Even though the script downloads will block one another, the rest of the page has already been downloaded and displayed to the user so that the entire page isn’t perceived as slow. This is the Yahoo! Exceptional Performance team’s first rule about JavaScript: put scripts at the bottom.

The best content for your career. Discover unlimited learning on demand for around $1/day.