PrairieDevCon 2014 - Web Doesn't Mean Slow

1,488 views
1,370 views

Published on

Web sites can be fast and responsive once you understand the process web browsers use to load and run web pages. We'll look at using tools like WebPageTest to analyze and optimize web pages.

Published in: Software, Technology, Design
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,488
On SlideShare
0
From Embeds
0
Number of Embeds
615
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

PrairieDevCon 2014 - Web Doesn't Mean Slow

  1. 1. ● Maintains jQuery code and docs ● Supports web developers and standards ● Participates in standards process ○ W3C web standards ○ ECMA 262 (JavaScript) jQuery Foundation
  2. 2. builtwith.com
  3. 3. jQuery Team - World Wide
  4. 4. http://contribute.jquery.org
  5. 5. PERFORMANCE
  6. 6. "JavaScript / jQuery / browsers are a bad developer environment!"
  7. 7. A poor workman blames his tools
  8. 8. How the Programmer Sees It JavaScript Browser
  9. 9. Web Developer's Reality Browser JavaScript Mouse CSS HTML Content caching Keyboard Touch Screen paints Layout calculation Image decoding Focus management Network requests
  10. 10. Web Developer's Reality Browser JavaScript Mouse CSS HTML Content caching Keyboard Touch Screen paints Layout calculation Image decoding Focus management Network requests Optional
  11. 11. How Do I Make My Page Fast?
  12. 12. How Do I Make My Page Fast? 1) Find slow stuff 2) Make it not slow
  13. 13. What you can measure using tools today How Do I Find the Slow Stuff?
  14. 14. What you can measure using tools today What you should measure How Do I Find the Slow Stuff?
  15. 15. JavaScript Loop Optimization
  16. 16. JavaScript Loop Optimization Slowest looping style still only takes 140 microseconds to do 10 iterations of a loop
  17. 17. “Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time; premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.” --Donald Knuth
  18. 18. “Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time; premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.” --Donald Knuth
  19. 19. Client-side issues often can be solved by "peephole" optimizations and don't require massive architecture changes Many — most! — speedups can be done near the end of the project (or even after deployment, cough) Finding and Fixing the 3 Percent
  20. 20. With all the other things going on in a web page, it's unlikely the run time of your JavaScript is in the 3% worst case. However, your JavaScript may be doing things that cause bad performance by making the browser do more work. It's Not the JavaScript, Probably
  21. 21. Use the tools available (online and inside the browser) to determine where the bottlenecks lie, and fix them. Don't Guess, Measure
  22. 22. How the Browser Loads Web Pages
  23. 23. Your Browser
  24. 24. <!doctype html> <html> <head> <script src="jquery.js"></script> <link rel="stylesheet" href="main.css" /> </head> <body> <p>An awesome web page</p> <img src="cat.jpg" alt="Kitty!" /> <script> document.write('<img src="nope.gif" />'); </script> Browser Fetches the HTML Page
  25. 25. <!doctype html> <html> <head> <script src="jquery.js"></script> <link rel="stylesheet" href="main.css" /> </head> <body> <p>An awesome web page</p> <img src="cat.jpg" alt="Kitty!" /> <script> document.write('<img src="nope.jpg" />'); </script> Scan for Fetchable Resources
  26. 26. <!doctype html> <html> <head> <script src="jquery.js"></script> <link rel="stylesheet" href="main.css" /> </head> <body> <p>An awesome web page</p> <img src="cat.jpg" alt="Kitty!" /> <script> document.write('<img src="nope.gif" />'); </script> Parse/Run JavaScript (In-Place)
  27. 27. ● HTML is fully loaded, may be partially shown to the user already ● Images may not be loaded yet ● DOMContentLoaded event ● jQuery lets you have functions to run ○ $(document).ready() ● These may modify the document Document Ready
  28. 28. The User Sees Your Page!
  29. 29. Now It May Seem Obvious, But... Resources outside the HTML file can't be prefetched, resulting in further delays e.g. stuff injected by JavaScript/jQuery JS frameworks (Angular, Backbone) or initial content from client-side templates can make the prefetcher useless
  30. 30. From top to bottom of the page: ● Render-blocking CSS ● Fonts ● Scripts Avoid CSS @import and font loading when possible, they block rendering Resource Order Is Important
  31. 31. Maximize the Network Connection
  32. 32. ● Avoid 3xx redirects ● Start requests early ● Minimize number of requests ● Minimize byte size of requests ● Maximize browser cache usage ● Spread requests across domains ● Load non-critical stuff later Rules of the Road
  33. 33. Redirecting to another page penalizes load time by a full network round-trip! Unfortunately this can't always be avoided, search engines like "canonical URLs". Avoid 3xx redirects
  34. 34. Put references to resources (e.g., images) in the HTML first delivered to the browser, so the prefetcher can "see" them. Start Requests Early
  35. 35. Manual Prefetching Lets the browser get a running start on template content or later pages. <link rel="dns-prefetch" href="http://media.mysite.com"> <link rel="prefetch" href="/img/kitten.jpg"> <link rel="prefetch" href="/step2.html">
  36. 36. Combine similar resources (scripts, CSS, images) and download as a single file (or at least a small number of files). Weigh tradeoff of combining vs. CDNs or reusing subsets on multiple pages to take advantage of browser caching. Minimize Number of Requests
  37. 37. Use tools like CSSMin and Uglify.js to squeeze out useless bytes in source files. Compress images, avoid HTML cropping. Enable gzip compression on the server. Minimize Size of Requests
  38. 38. Make sure your server sets appropriate headers on content so the client can cache it. Don't expire content quickly unless it changes quickly! (Hint: Your company logo doesn't change quickly.) Maximize Browser Cache Usage
  39. 39. To maximize bandwidth, request resources from 2 or 3 domains at once; this is called domain sharding. A Content Distribution Network (CDN) can provide high-speed delivery of commonly used resources like jQuery. Spread Requests Across Domains
  40. 40. Wait until after page load to fetch things that aren't needed until well after the page has been loaded: ● Content not initially visible ● Social media scripts and styles ● Advertising ● Page analytics Load Non-Critical Stuff Later
  41. 41. Any code you include via a <script> tag has complete control over the performance and functionality of the page. It can do anything it wants to the user. Do You Trust Third-Party Code?
  42. 42. Internet Explorer Compatibility Views
  43. 43. ● Revives old crusty cold inside IE ● Restores old incompatible behavior ● Removes new fast JavaScript APIs ● Makes IE much slower and stranger ● Makes me (and users) cry <meta http-equiv="X-UA-Compatible" content="IE=8"> How Compat View Works
  44. 44. ● Don't use outdated jQuery or plugins ● Always specify a VALID doctype ● Don't use browser sniffing ○ Use Modernizr instead How to Avoid Compat View
  45. 45. modern.IE
  46. 46. Tools for Finding Page Loading Issues
  47. 47. YSlow
  48. 48. Google PageSpeed
  49. 49. webpagetest.org
  50. 50. Scan Results Summary
  51. 51. Scan with IE9, Virginia, DSL
  52. 52. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" xmlns:fb="http://www.facebook.com/2008/fbml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=1" /> <title>Breaking News and Opinion on The Huffington Post</title> IE Parser Restart (IE9 or earlier)
  53. 53. Blocking Resources (Horizontal) Invalid doctype, restarts because of an X-UA-Compatible tag Ran out of connections, had to wait for previous downloads Some JS files loaded before CSS, which will delay rendering TOO MANY REQUESTS FOR JAVASCRIPT FILES !!!!!1!ONE!
  54. 54. Same Site with IE11
  55. 55. Same Site with Chrome
  56. 56. Same Site with iPhone 5 (3G)
  57. 57. In this case, IE11 CPU usage was very high starting at 2.5 seconds from initial request and all during DOMContentLoaded CPU and Bandwidth Usage
  58. 58. Content Type by Count/Bytes
  59. 59. Filmstrip/Movie Views
  60. 60. But Wait … There's More!
  61. 61. Lots of Settings You Can Tweak
  62. 62. ● Simple scripting language ○ Lets you e.g. automate a login ● Share links to test runs ○ "Here's what our site looks like from Toronto using IE8 on a DSL-speed link." Even More!
  63. 63. Get to know webpagetest.org Are You Convinced Yet?
  64. 64. Maintaining a Good Frame Rate
  65. 65. You Have 16 Milliseconds … Begin 60 frames/second ~ 16 milliseconds/frame Long-running operations can make the page appear "janky" rather than smooth. Really long-running operations can make the page appear unresponsive to the user.
  66. 66. It Happens in 16 Milliseconds? From High Performance Browser Networking by Ilya Grigorik (O'Reilly)
  67. 67. Your JavaScript shares a thread with the browser's layout calculation and screen painting; they can't happen in parallel. Only a few things like downloading, image decoding, and garbage collection are done on independent threads. To Make Things Worse...
  68. 68. Don't ask the browser to do a bunch of work to answer a question if you could easily find/remember the answer yourself. Forced Layouts
  69. 69. Adventures in Dirty Layout :visible :hidden
  70. 70. "The Dot That Ate Performance" console.time("init"); $("body").removeClass("activated"); $("p:visible").css("color", "blue"); console.timeEnd("init");
  71. 71. ● Select all <p> in the document ● Ask the browser if any are visible ○ Browser may need to recalculate layout dimensions if the document has changed What $("p:visible") Means
  72. 72. "Hey Browser Can I Bug You?" 30 ms
  73. 73. What If We Track Visibility? console.time("init"); $("body").removeClass("activated"); $("p.visible").css("color", "blue"); console.timeEnd("init"); Note: Normally you'd use a more descriptive class name than "visible"!
  74. 74. "Hey Browser, I Know This" 8 ms
  75. 75. ● Avoid document-wide style/class change ○ Use data- attrs or jQuery .data() to store non-stylistic data unrelated to presentation ● Get JavaScript out of the path ○ CSS transitions ○ CSS animations Avoiding Forced Layout
  76. 76. The Softer Side of Performance
  77. 77. A page that loads quickly is great, but letting the user accomplish their task is your ultimate goal. Reduce the amount of waiting, clicking, typing, and searching the user must do to accomplish their task. Optimize for User Tasks
  78. 78. Twitter: @davemethvin GitHub: @dmethvin IRC-Freenode: DaveMethvin #jquery-dev Email: dave@jquery.com $("#talk") .find(".useful") .append(contactInfo) .end();

×