You are previewing Web Performance Daybook Volume 2.

Web Performance Daybook Volume 2

Cover of Web Performance Daybook Volume 2 by Stoyan Stefanov Published by O'Reilly Media, Inc.
  1. Web Performance Daybook, Volume 2
  2. SPECIAL OFFER: Upgrade this ebook with O’Reilly
  3. Foreword
  4. From the Editor
  5. About the Authors
    1. Patrick Meenan
    2. Nicholas Zakas
    3. Guy Podjarny
    4. Stoyan Stefanov
    5. Tim Kadlec
    6. Brian Pane
    7. Josh Fraser
    8. Steve Souders
    9. Betty Tso
    10. Israel Nir
    11. Marcel Duran
    12. Éric Daspet
    13. Alois Reitbauer
    14. Matthew Prince
    15. Buddy Brewer
    16. Alexander Podelko
    17. Estelle Weyl
    18. Aaron Peters
    19. Tony Gentilcore
    20. Matthew Steele
    21. Bryan McQuade
    22. Tobie Langel
    23. Billy Hoffman
    24. Joshua Bixby
    25. Sergey Chernyshev
    26. JP Castro
    27. Pavel Paulau
    28. David Calhoun
    29. Nicole Sullivan
    30. James Pearce
    31. Tom Hughes-Croucher
    32. Dave Artz
  6. Preface
    1. Conventions Used in This Book
    2. Using Code Examples
    3. Safari® Books Online
    4. How to Contact Us
  7. 1. WebPagetest Internals
    1. Function Interception
    2. Code Injection
    3. Resulting Browser Architecture
    4. Get the Code
    5. Browser Advancements
  8. 2. localStorage Read Performance
    1. The Benchmark
    2. What’s Going On?
    3. Optimization Strategy
    4. Follow Up
  9. 3. Why Inlining Everything Is NOT the Answer
    1. No Browser Caching
    2. No Edge Caching
    3. No Loading On-Demand
    4. Invalidates Browser Look-Ahead
    5. Flawed Solution: Inline Everything only on First Visit
    6. Summary and Recommendations
  10. 4. The Art and Craft of the Async Snippet
    1. The Facebook Plug-ins JS SDK
    2. Design Goals
    3. The Snippet
    4. Appending Alternatives
    5. Whew!
    6. What’s Missing?
    7. First Parties
    8. Parting Words: On the Shoulders of Giants
  11. 5. Carrier Networks: Down the Rabbit Hole
    1. Variability
    2. Latency
    3. Transcoding
    4. Gold in Them There Hills
    5. 4G Won’t Save Us
    6. Where Do We Go from Here?
    7. Light at the End of the Tunnel
  12. 6. The Need for Parallelism in HTTP
    1. Introduction: Falling Down the Stairs
    2. Current Best Practices: Working around HTTP
    3. Experiment: Mining the HTTP Archive
    4. Results: Serialization Abounds
    5. Recommendations: Time to Fix the Protocols
  13. 7. Automating Website Performance
  14. 8. Frontend SPOF in Beijing
    1. Business Insider
    2. CNET
    3. O’Reilly Radar
    4. The Cause of Frontend SPOF
    5. Avoiding Frontend SPOF
    6. Call to Action
  15. 9. All about YSlow
  16. 10. Secrets of High Performance Native Mobile Applications
    1. Keep an Eye on Your Waterfalls
    2. Compress Those Resources
    3. Don’t Download the Same Content Twice
    4. Can Too Much Adriana Lima Slow You Down?
    5. Epilogue
  17. 11. Pure CSS3 Images? Hmm, Maybe Later
    1. The Challenge
    2. Getting My Hands Dirty with CSS3 Cooking
    3. Cross-Browser Results
    4. Benchmarking
      1. Payload
      2. Rendering
    5. Are We There Yet?
    6. Appendix: Code Listings
      1. HTML
      2. CSS
  18. 12. Useless Downloads of Background Images in Android
    1. The Android Problem
    2. And the Lack of Solution
  19. 13. Timing the Web
    1. Conclusion
  20. 14. I See HTTP
    1. icy
    2. Some details
    3. Walkthrough
    4. Todos
    5. The Road Ahead
    6. All I Want for Christmas…
  21. 15. Using Intelligent Caching to Avoid the Bot Performance Tax
  22. 16. A Practical Guide to the Navigation Timing API
    1. Why You Should Care
    2. Collecting Navigation Timing Timestamps and Turning Them into Useful Measurements
    3. Using Google Analytics as a Performance Data Warehouse
    4. Reporting on Performance in Google Analytics
    5. Limitations
    6. Final Thoughts
  23. 17. How Response Times Impact Business
  24. 18. Mobile UI Performance Considerations
    1. Battery Life
    2. Latency
    3. Embedding CSS and JS: A Best Practice?
    4. Memory
      1. Optimize Images
      2. Weigh the Benefits of CSS
      3. GPU Benefits and Pitfalls
      4. Viewport: Out of Sight Does Not Mean Out of Mind
      5. Minimize the DOM
    5. UI Responsiveness
    6. Summary
  25. 19. Stop Wasting Your Time Using the Google Analytics Site Speed Report
    1. Problem: A Bug in Firefox Implementation of the Navigation Timing API
    2. Solution: Filter Out the Firefox Timings in Google Analytics
    3. Good News: The Bug Was Fixed in Firefox 9
    4. Closing Remark
  26. 20. Beyond Web Developer Tools: Strace
    1. What About Other Platforms?
    2. Getting Started
    3. Zeroing In
    4. Example: Local Storage
    5. We’ve Only Scratched the Surface
  27. 21. Introducing mod_spdy: A SPDY Module for the Apache HTTP Server
    1. Getting Started with mod_spdy
    2. SPDY and Apache
    3. Help to Improve mod_spdy
  28. 22. Lazy Evaluation of CommonJS Modules
    1. Close Encounters of the Text/JavaScript Type
    2. Lazy Loading
    3. Lazy Evaluation to the Rescue
    4. Building Lazy Evaluation into CommonJS Modules
  29. 23. Advice on Trusting Advice
  30. 24. Why You’re Probably Reading Your Performance Measurement Results Wrong (At Least You’re in Good Company)
    1. The Methodology
    2. The Results
    3. Conclusions
    4. Why Does This Matter?
    5. Takeaways
  31. 25. Lossy Image Compression
    1. Lossy Compression
  32. 26. Performance Testing with Selenium and JavaScript
    1. Recording Data
    2. Collecting and Analyzing the Data
    3. Sample Results
    4. Benefits
    5. Closing Words
    6. Credits
  33. 27. A Simple Way to Measure Website Performance
    1. Concept
    2. Advantages
    3. Limitation
    4. Conclusion
  34. 28. Beyond Bandwidth: UI Performance
    1. Introduction
    2. After the Page Loads: The UI Layer
    3. UI Profilers
      1. CSS Stress Test
      2. CSS Profilers
      3. CSS Lint
      4. DOM Monster
    4. Perception of Speed
    5. Tidbits
    6. Call for a Focus on UI Performance
  35. 29. CSS Selector Performance Has Changed! (For the Better)
    1. Style Sharing
    2. Rule Hashes
    3. Ancestor Filters
    4. Fast Path
    5. What Is It Still Slow?
  36. 30. Losing Your Head with PhantomJS and confess.js
    1. Performance Summaries
    2. App Cache Manifest
    3. Onward and Upward
  37. 31. Measure Twice, Cut Once
    1. Identifying Pages/Sections
    2. Identifying Features
    3. Optimizing
  38. 32. When Good Backends Go Bad
    1. What Is a Good Backend Time?
    2. Figuring Out What Is Going On
    3. Fixing It
    4. Finally
  39. 33. Web Font Performance: Weighing @font-face Options and Alternatives
    1. Font Hosting Services Versus Rolling Your Own
    2. What the FOUT?
    3. Removing Excess Font Glyphs
    4. JavaScript Font Loaders
      1. Introducing Boot.getFont: A Fast and Tiny Web Font Loader
    5. Gentlefonts, Start Your Engines!
      1. My Observations
    6. Final Thoughts
  40. About the Author
  41. Colophon
  42. SPECIAL OFFER: Upgrade this ebook with O’Reilly
  43. Copyright
O'Reilly logo

Chapter 3. Why Inlining Everything Is NOT the Answer

Guy Podjarny

Every so often I get asked if the best frontend optimization wouldn’t be to simply inline everything. Inlining everything means embedding all the scripts, styles, and images into the HTML, and serving them as one big package.

This question is a great example of taking a best practice too far. Yes, reducing the number of HTTP requests is a valuable best practice. Yes, inlining everything is the ultimate way to reduce the number of requests (in theory to one). But NO, it’s not the best way to make your site faster.

While reducing requests is a good practice, it’s not the only aspect that matters. If you inline everything, you fulfill the “Reduce Requests” goal, but you’re missing many others. Here are some of the specific reasons you shouldn’t inline everything.

No Browser Caching

The most obvious problem with inlining everything is the loss of caching. If the HTML holds all the resources, and the HTML is not cacheable by itself, the resources are re-downloaded every time. This means the first page load on a new site may be faster, but subsequent pages or return visitors would experience a slower page load.

For example, let’s look at the repeat visit of the New York Times’ home page (Table 3-1, Figure 3-1). Thanks to caching, the original site loads in 2.7 seconds. If we inline the JavaScript files on that page, the repeat visit load time climbs to 3.2 seconds, and the size doubles. Visually, the negative impact is much greater, ...

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