I am developing a new template for mobile and created a test file using only the header and footer. i.e… Master template. Every time I run the test, I get different results that vary by 300% or more. It generally is 2 or 3 files that push the results out. I am speaking about the time to finish loading the page. i.e… Your blue line. Not the script files that load after that, although I will deal with them too. Here are some results:
Waterfall Performance Test = 9.735s for First View and 0.417s for repeat view. // Note: This test is does NOT seem to be accurate, as it will hang up on connecting on some of the files. In fact, /hide-show-content.js is what pushed it out to 9 seconds. Rerun the test and First View = 3.76 Seconds with /hide-show-content.js only taking 195 ms (milli seconds - 0.195 seconds) and horizontal.gif (a .4kb file pushing it out to over 3 seconds. Allowing for this, it looks like it takes about 2.5 seconds to load the page, which I question since this is a small file (about 200kb). Here is an example result: http://www.webpagetest.org/result/140515_ND_GSW/1/details/. Notice the files #5, #8, #24 are out of balance. If I run the test again, these files will be normal and 2 or 3 others will be out of balance.
At first I thought it might be a connection problem with our server, even though it is a dedicated server and it should be quite fast. I tried another waterfall test on another site and did not get this behavior. To simplify the test better, I guess I could get rid of all the JavaScript and try it again, but it is NOT the timing that bothers me. It is the lack of consistency and the variations in the delays that should really not be happening. Thanks for any insight. Great site, by the way.
p.s. I am aware that I have Keep Alive off for the time being.
I see very little problem at all with first party calls (Ones you have hosted locally.) However, the third party calls are giving you the trouble. Take a look at call numbers 27-39, the ones highlighted in yellow are giving a 302 redirect comment and appear to be loading slowly for the size files they are.
Your test results are going to be quite variable if you have alot of 3rd party calls, because those might or might not load consistently on repeated testing. You have no control over that. It’s the nature of the third party beast.
Anton,
Thanks for the answer and it had some good information, but it addressed files that have no bearing on the issue. i.e… They were NOT blocking the download of those delayed files. In fact, they loaded after the page was completely loaded, so they have no impact on the page load.
Your test came out right, but as I said, mine do not. Maybe you guys use a better bandwidth for your test, then you give everyone else. I can run the test 1/2 dozen times and there will always be these delayed files from both our server and 3d party (although I do not care about 3d party right now because they are deferred and do not impact what the user sees.
I specially mentioned before your blue line. The actual page load time. I understand about 3d party 302s, but they are not important to the page load time, nor to the delayed file results I pointed out. The all are downloaded AFTER the page is fully loaded because I have them deferred. Although I need to do a little more work to get it completely right. These are Adroll, Google Analytics, etc and as long as they do not block the page loading, they are less important.
I can run a test on pingdom 1/2 dozen times and the test always come out right with acceptable variations. i.e. This page loads from .7 seconds to 1.5 second. I can run the test on webpagetest and every single time, there will be some files that will show the delayed results. i.e. 5 to 9 seconds, which of course is NOT correct.
To make this clearer to you , I ran the test a few more time until I got one that only had 1 file delayed. http://www.webpagetest.org/result/140516_4R_A2E/1/details/. As you can see, the page load time is 3.7 seconds, because of the delayed actions of #5, which took the 3.6 seconds. This file is our file. It is twitter-buttons.gif which is only .4kb.
This is why I suspected our server at first. i.e. Maybe some of the TCP port creation was being slowed. It is the reason why I search for other waterfall chart test and ran the test on them. Results: This never happens.
Which indicates that it is something on your side, since the test is strictly between your server and the traceroute path to our server.
I went one step further. I deleted the contents of the 3d party scripts and ran the test again and true to what I have been seeing, your test show that one of the files (a 0.4mb search-icon.jpg, took over 3 seconds to connect. WebPageTest Test - WebPageTest Details
Again, the indicating might be that our server is the culprit, but as I said, this behavior is not seen on other sights that have a timing or waterfall test.
To take it one step further, I also tested a page on another box, with a different hosting companies. Here is the results. WebPageTest Test - WebPageTest Details. Note: This is a VPS, but a good one. This file has no compression, nor other efficiencies. Note the /list-check.gif file takes over 3 seconds to connect. Run test again and it is normal and some other file will take excessive time to connect.
[quote]Your test came out right, but as I said, mine do not. Maybe you guys use a better bandwidth for your test, then you give everyone else…
Again, the indicating might be that our server is the culprit, but as I said, this behavior is not seen on other sights that have a timing or waterfall test.[/quote]I don’t have any special tools different from anyone else… The tests at WPT are just real browsers, real connections with their own bandwidth. If you use the same WPT parameters as the next guy, you’re getting the exact same test as the next guy. I don’t know about other sites and how they do their tests, I just know WPT is real world testing on real computers and doesn’t ask for your email address so it can spam you later, and doesn’t try to sell you optimization services. This is why I use WPT exclusively. I don’t work for WPT or Google, I am just a regular guy - a webmaster like yourself.
I apologize for not understanding your problem right away but since I could not duplicate it, it failed to stand out to me.
And thus far I have no helpful answer other than “vagaries of the internet” to explain the apparent intermittent issues you’re having with some of these files.
I note however that you continue to use the IE9 parameter in WPT, and this might be strictly a IE9 issue. Try WPT using other browsers as the test browser, like Chrome, Firefox and IE 10 and 11, and see if you still see the intermittent file load delays. I’ve been completely unable to duplicate them myself, thus far - except when using the IE9 test browser.
I just realized that it defaulted to ie 9. I tried other browsers, including Chrome and it still does it. In fact using Chrome showed a small graphic as taking 3 seconds to connect and 26 seconds to first byte. http://www.webpagetest.org/result/140518_TP_F5N/1/details/
My only concern is that I am missing something that may be reflective of our server, although I do not see any delays when downloading pages directly. I will keep digging. Thanks Frank
[quote=“ae3799t, post:5, topic:8727”]
I just realized that it defaulted to ie 9. I tried other browsers, including Chrome and it still does it. In fact using Chrome showed a small graphic as taking 3 seconds to connect and 26 seconds to first byte. http://www.webpagetest.org/result/140518_TP_F5N/1/details/
My only concern is that I am missing something that may be reflective of our server, although I do not see any delays when downloading pages directly. I will keep digging. Thanks Frank
[/quote]Well if it helps any, I see this type of behavior intermittently myself with my own sites. I’ve always just written it off as part of the randomness of the interconnecting web.
I too am seeing this. It’s more pronounced on the Moto G client and seems to affect various static assets (CSS and JS) served by a CDN (in my case Edgecast). One hint I recieved was that its perhaps a non-optimal handling of dropped packets. I’ll be trying a different CDN to see if I can replicate.
Because look here, request #1 in the waterfall: URL: http://www.roadtrucker.com/t/master.htm
Host: www.roadtrucker.com
IP: 173.247.243.121
Location: Santa Monica, CA
Error/Status Code: 200
Client Port: 57441
Start Offset: 0.127 s
DNS Lookup: 34 ms
Initial Connection: 89 ms
Time to First Byte: 100 ms
Content Download: 3 ms
Bytes In (downloaded): 3.2 KB
Bytes Out (uploaded): 0.3 KBThat IP is not Edgecast’s CDN, it’s your host, InMotion. All your native file calls are this way. The CDN isn’t in effect. It’s doing nothing.
