![]() |
What do you make of my results? - Printable Version +- WebPagetest Forums (https://www.webpagetest.org/forums) +-- Forum: Web Performance (/forumdisplay.php?fid=3) +--- Forum: Discuss Test Results (/forumdisplay.php?fid=4) +--- Thread: What do you make of my results? (/showthread.php?tid=12055) |
What do you make of my results? - geemonkey - 02-20-2013 01:27 AM Hi I am a new web developr and have made the small webshop at energyshop.se and I am trying to optimize it and ran this test. What o you guys htink about the result and what should I really take care of and what is not so important? http://www.webpagetest.org/result/130219_5J_H17/ RE: What do you make of my results? - rviscomi - 02-20-2013 05:34 AM Hi geemonkey. You're definitely off to a good start by coming to WPT for your performance analysis. There are a few things you should know as you get started... WPT is great at pointing out areas in need of improvement. It also gives you times for how long resources load, and even how long the page itself loads. Don't take these load times too seriously. It's not that they're wrong, but they're just not *representative* of what all of your visitors would experience. The other note about timings is that they're easily influenced by anomalies on the network. Among many other factors, some random packet loss could make it seem like a request is taking too long to load, so you won't be able to duplicate those results consistently. The trick to minimizing these anomalies is to run a few tests and let WPT choose the *median* test run. In effect, this smooths out the outliers and what you're left with is the common case. In addition to the increased test runs, you should also opt to record a video of the page load. This enables other features dependent on the video including filmstrips, visual progress charts, and comparison against other tests. This should be selected by default because it offers so much in addition to the standard info. I'd also add that you're testing in IE 7, which is over six years old. I know you're testing from London, which has a limited selection of browsers, but whenever possible try to test using a browser that is popular among your visitors. (let's hope it's newer than IE 7) So you've run the test and you're confident in the results - now it's time to analyze the results. The first thing you do is look up at the grades A through F. These are the most rudimentary performance best practices that nobody has an excuse to ignore. Clicking on each grade will give you more information about it. The big ticket items for this test are first byte time, compress transfer, and cache static content. I'll get into first byte time in a bit. The "F" grade for "Compress Transfer" is really easy to fix on the backend. You need to make sure you enable gzip compression for text-based resources including HTML, CSS, and JS. Make sure you talk to whoever works on your backend about getting this changed. It could literally be a one line code change, but it has a noticeable improvement on performance. The "F" grade for "Cache static content" is made evident by the yellow background behind requests in the repeat view. They are getting a HTTP 304 response because the browser knows about the last time the resources were modified and even some unique identifiable information about them (E-Tags) but the server never tells the browser to explicitly keep these resources in cache. The two HTTP headers that do this are Expires and Cache-Control. I suggest using a combination of Last-Modified and "Cache-Control: max-age" to specify how long you'd like the browser to hang on to these resources before bothering the server. Some people are afraid to set the lifetime of a resource too far in the future, but if you do this right it won't be a problem. The trick is to implement some sort of "cache busting" to let the browser know that no matter what is in cache, it needs to pull down a newer copy of the file. The most straightforward way to do this is to change the file name itself. So if you have style.css, maybe you want to call it style_20130219.css (for today's date) and set the time to live of the file to one year. If you change the file tomorrow, keep the caching info exactly the same but simply update the file name to style_20130220.css. The browser will treat it as a totally new resource and the old one in cache will go away in time. This can be a pain to maintain, so work this into an automated build process if you can. The colorful waterfall chart is the crux of the performance analysis. There are many many things to look out for here, but I'll point out some of the big ones that I can see in your test results. Starting at the top, your first problem is the long time your server takes to output some content (700ms). This is indicated by the bright green portion of the bar, aka time to first byte. This is the reason for the "F" grade on First Byte Time. Optimizations to this are going to be on the backend, which may be out of your purview. As for what exactly is causing this delay, the waterfall cannot say -- but it usually ends up being slow database queries to build the initial HTML. Monitoring tools would be necessary to pinning this down. The biggest thing that jumps out at me is the green vertical line, start render, which takes place at about 4.5 seconds. This is the time it takes for something/anything to be displayed on the screen. As a reminder, we don't really care about the number 4.5 but we know that there are things we can do to improve it. So there are a couple of reasons why this could be taking so long: 1. You're loading most of the page resources before it. It's possible to use HTML attributes to defer the loading until later, or even some basic JavaScript to wait until the document is ready or the onload event fires. By taking these requests out of the flow, the page can start to render sooner. One important change you should make is to load scripts before your closing </body> tag, not in the HTML head. 2. Between 2 and 3 seconds, you can see a gap where not a lot is happening over the network, but the browser is doing a lot of work. At the bottom of the waterfall chart there are a couple of line charts that illustrate what's going on. A couple of reasons why this could be happening are long-running JavaScript code or complicated HTML. So long-running JS is a problem because the browser waits for the code to finish before moving on with UI. The other cause is unoptimized HTML, the best example of which is using <table> incorrectly for page layout. I'm not seeing either of these red flags in your code, which is great. This may not be an issue after all, but you can see how you need to chase down anomalies. This is why it's important to run multiple tests from different locations. IE 7 from Dulles, VA does not show this gap consistently. IE 7 from London, UK does show this gap consistently. Bottom line, synthetic testing is especially prone to anomalies. Dulles: http://www.webpagetest.org/result/130219_90_QTC/ London: http://www.webpagetest.org/result/130219_7G_P75/ Hope this wasn't too low-level or boring. If not it should be of some help to others new to performance analysis. RE: What do you make of my results? - pmeenan - 02-22-2013 06:53 AM +1 Awesome write-up Rick RE: What do you make of my results? - geemonkey - 02-22-2013 09:49 PM (02-20-2013 05:34 AM)rviscomi Wrote: Awesome text Hi again and thanks for the great reply. Now I had some time to invetigate it further and dig into it (its my first time...) and I have spent some time to try to edit the .htaccess (which I didnt even have in my foder to start with) and after some scouting on the web I came up with this document: Code: # BEGIN W3TC Browser Cache But I still get only 82/100 http://www.webpagetest.org/result/130222_EN_DK5/ and its telling me that stuff I thought i got rid of with the .htaccess is still not set up properly. Is there anything I should really consider here or can I move along really? I will today try to optimize my images to the fullest and then run the test again. UPDATE: Fixed images - now have 90/100. Now onto next thing, why isnt my JS/CSS compressed? I use "correct" gzip/deflate but they still show up as not compressed on different test sites. The things that are still there now mainly is about JS and CSS. It might be some setting on not my end? Didnt get your tester to work today so I used this: https://developers.google.com/speed/pagespeed/insights#url=http_3A_2F_2Fenergyshop.se_2F&mobile=false RE: What do you make of my results? - pmeenan - 02-26-2013 06:08 AM Any chance mod_deflate isn't installed on your server? |