![[object Object],[object Object]](https://image.slidesharecdn.com/aholisticviewofwebsiteperformance-110913112051-phpapp02/85/A-Holistic-View-of-Website-Performance-1-320.jpg)
![[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à A Holistic View of Website Performance
Similaire à A Holistic View of Website Performance (20)
Dernier
Dernier (20)
A Holistic View of Website Performance
- 6. User starts to see something in their browser
- 7. Reassures the user that their information is coming.
- 8. JavaScript NOT executing yet.
- 10. Buttons/forms active and clickable
- 11. This is when the onLoad() event fires.
- 12. JavaScript may still be loading elements in the background.
- 14. All of the initial AJAX calls have been made
- 18. Load & Compile PHP
- 19. Execute PHP & Database Queries
- 21. Fetch CSS, JavaScript and Images
- 22. Render page
- 24. Profit!
- 30. Analytic programs can handle multiple domain names
- 31. Use wildcard cookies to avoid domain name redirects: setcookie($name, $value, $time, '/', '.example.com' );
- 32. Put your preferred domain name into the Canonical link to avoid Google penalties for duplicate content: <link rel="canonical" href="http://www.foo.com/bar.php" />
- 35. Do not include/require unnecessary code Frameworks - More harm than help? $foo = new Widget(); // What PHP runs?
- 40. Varnish Cache Server - http://www.varnish-cache.org/
- 42. nginX - http://nginx.org/ (less memory usage)
- 43. php-fpm - http://php-fpm.org/ (less memory usage)
- 50. Shorten CSS tags <p class="a23r7"> vs. <p class="paragraph_style_alpha23_rev7">
- 57. etc.
- 63. Rollover images
- 64. Ratings (stars, dots, whatever)
- 65. Thumbs up
- 66. Thumbs down
- 67. Rounded corners
- 68. Buttons
- 69. etc.
- 76. Not supported in IE 6 & 7 (Workaround: Mime HTML: http://www.phpied.com/mhtml-when-you-need-data-uris-in-ie7-and-under/ )
- 77. IE8 requires encoded data to be less than 32kb
- 80. JavaScript at the bottom of the page
- 81. Defer loading images below the fold so JavaScript event onLoad() can fire. http://developer.yahoo.com/yui/imageloader/
Notes de l'éditeur
- Website performance can be viewed from many different perspectives. This talk will cover some of the things you can do as a webmaster to improve how quickly your site renders on your users machines. This means only making changes on the server since you do not have control over the end-users browser settings.
- Render start vs Page Complete, which is more important depends on your website. A table of statistics would care about render start because the user can start reviewing the data before the page is done. A e-commerce site may care more for page complete because that is when the &quot;Buy This&quot; buttons appear.
- At this point people can start interacting with the webpage (in theory)
- This is a waterfall graph from the site WebPageTest.org, which is a huge help in understanding the entirety of how long it takes your webpage to load. We'll be covering the information shown on this graph in detail throughout this presentation.
- Not much you can really do to speed up a DNS server. They're amazingly fast already, almost 100% of the time involved in the query is network lag between your browser and the DNS servers. Keep in mind that every widget that you add to your webpage adds at least one more domain name. AddThis.com, Facebook like buttons, Google Analytics, etc., etc., etc. DNS queries are cached by the browser but the cache doesn't help on that all-important first pageview.
- Socket communication requires an acknowledgement before the connection is established, so a minimum of 2x the network latency. Not all that much that you can do to speed this up. Content Delivery Networks can help reduce the network lag, but not many of us are in a financial position to take advantage of this. Avoid redirects, especially on that all-important home page. Yes, it makes handling your cookies easier, but it can easily add a half-second to your first and most important pageview. Redirects add another DNS lookup and another connection request if the domain name changes. CDN - Content Delivery Network. A collection of servers placed around the country. DNS tricks are employed so that the server closed to the user is picked.
- Variations on the domain name doesn't help performance wise, but it's a nice touch and avoids the misspelling squatters.
- Here you can see the cost of redirecting to a specific version of the domain name. It includes another DNS lookup and a second socket connection. Also notice that IE8 allows up to 6 simultanious connections, each taking a thread/server.
- The controversial item on this page is the question about frameworks. When that constructor fires, how much is actually being included/compiled/run? How do you know?
- Since we're a programming group, most of what we talk about is here in this section. And we're pretty good at it, to the point where it's not a major portion of the problem.
- Pardon the sloppy drawing, it's hard to draw nice curves with a trackball Even if I eliminated the back-end PHP time to generate this page, the vast majority of the time that the user is kept waiting is NOT involved in PHP.
- User specific content could be the contents of their shopping cart, their username, etc. All of the little personalization touches could be done via AJAX.
- Balance the bandwidth reduction via gzip against the CPU time used to compress things. If the server is heavily loaded, the CPU time may be more valuable than the bandwidth.
- Because gzip encodes data in chunks and is implemented as an output filter, flush() cannot arbitrarily push partial blocks out the pipe. So if the HTML that you generate is fairly small, skip gzip and see if flush() makes more of a different in pageload time. Personally I get better results from gzip/deflate than flush()
- Everything we've discussed so far is minor. The major gains are right here. All of the extra stuff listed on your page. Any external reference that you make in a page gets pulled from the servers during this step.
- Note that using multiple domain names does increase the DNS resolution time, but it's a tradeoff between the number of downloads that you can simultaniously get rolling.
- Reusing the image here.
- The VAST majority of users to your website are NOT going to have anything in their cache for that all-important first-page. Google Analytics released a newsletter recently showing that the average bounce rate over all the sites they analyze (that opted into sharing data) was 47%.
- Note that combining all of your javascript into a single file means ALL of your JavaScript, even those libraries that you're using from somebody else. This can cause conflicts when you're using something like GoogleMaps and they change/improve their libraries. Also, this can cause havoc when many people are changing the website because you're all making changes to the same file. So save this step until the end, just before the site is pushed live.
- This one larger image results in a single HTTP request rather than a horde of them. Since bandwidth is less of an issue these days, the larger image size is less of a problem than the multiple requests.
- This one larger image results in a single HTTP request rather than a horde of them. Since bandwidth is less of an issue these days, the larger image size is less of a problem than the multiple requests.
- Obviously, creating these sprite images can be quite time-consuming, so this step is often best left until the site is almost ready to go live, after the customer has signed off on the design look & feel. Hint: To make creating these a little easier, create an HTML table with all of the image in it and then do a screenshot. If you do the table trick try adding borders, it'll make later edits much easier and you can just crop out the border when you are positioning the sprite.
- JavaScript blocks other downloads, so any external script references in your header will block images from downloading. document.write() calls cannot be moved to the bottom of the page, but they can be deferred.
- The end user gets to control which JavaScript engine is used by their choice of browser. We could restrict the site to a specific browser, but that's just slitting our own throats. Keep the &quot;Gee-Whiz&quot; factor under control. Yes, that subtly changing background gradient may be really cool, but does it actually help move product? Again I'm bringing up frameworks. I've seen major chunks (like 250k worth) of JavaScript included in order to use one or two 20-line JavaScript utility functions. There's no reason to abuse bandwidth like that.
- KeepAlive - tradeoff between server resources and browser speed. Recommend a minimum of 5-15 seconds, a maximum of a little more than the average time spent on a page for your site, but no more than 5 minutes. On a high volume site, you may not be able to afford the server resources to keep that many connections alive.
- The HEAD requests are done on subsequent page loads to see if a page/image/file on the server has changed. Setting the Expires header can eliminate these checks, speeding up 2nd page load times.
- I'm not picking on FoundLine in particular here, their page reload time is quite good, but they were the first site I could find that wasn't using the Expires headers. A 304 result means &quot;Not Modified&quot; in response to a HEAD query.
- I know this is pretty much unreadable, but here is a more extreme example, smalldog.com. Lots of graphics all of which haven't changed. Only the white lines are changed elements.