Can someone explain the (huge) gap in the waterfall below? I don’t see any resource being downloaded between 44 and 45 that can account for the 30s loadtime.
http://www.webpagetest.org/result/140926_VW_c10aa33bc86ba6a5af0375eebb3274a2/1/details/
Note that there are 2 instances of this in a 9-run test, so although the average is good, I’m concerned why it happened on 2 tests:
http://www.webpagetest.org/result/140926_VW_c10aa33bc86ba6a5af0375eebb3274a2/
TIA!
I ran it with timeline, tcpdump and response body capture turned on and managed to repeat it: http://www.webpagetest.org/result/140926_YZ_XGR/8/details/
In the timeline ( http://www.webpagetest.org/chrome/timeline.php?test=140926_YZ_XGR&run=8 ) it looks like there is a message about seal.verisign.com/getseal?host_name=www.myspicesage.com&size=L&use_flash=YES&use_transparent=YES&lang=en finishing right before everything frees up.
Looking at the page code it looks like that is an external script though I’m not sure why it’s not showing up in the waterfall.
From the looks of it, the verisign seal is timing out intermittently causing the 30-second page loads.
I’m kind of violently opposed to those things anyway because they don’t actually add any value or security (and add failure modes like this) so if you can I’d highly recommend just ripping all of the seals off of your page anyway.
Thanks Pat, this is helpful.
Could you help me “read” the timeline though? When I tried to view it, I looked for “seal.verisign…” and all I saw was the Send request and not where it was “finishing right before everything frees up”.
At the top you need to change the window to zoom into the chunk of HTML parsing just before the load event (after the big long gap). Then look around for anything that looks like it might have caused things to get held up. In this case the error event with the load finish event for the verisign seal looked like a prime candidate.
[attachment=434]
Pat,
This is an old post - I am, nonetheless, interested in why you are opposed to seals generally.
I ask because SSL is required generally in eCommerce and Google encourages secured sites - so should we simply use the https part of Verisign (or whoever) and skip the part where the end user can click on the Seal?
In the case of “credibility” would end users believe use if they could not verify that we are “real” and using “fake” seals that could not be clicked on?
We have run into similar issues with speed delays on our site with Seals.
Thanks
Newell[
quote=‘royster’ pid=‘24551’ dateline=‘1411760386’]
Thanks Pat, this is helpful.
Could you help me “read” the timeline though? When I tried to view it, I looked for “seal.verisign…” and all I saw was the Send request and not where it was “finishing right before everything frees up”.
[/quote]
I am strongly in favor of SSL and secure communications. That is completely independent of the verisign seal (or any other) in the content.
The browser will already take care of security indicators in the address bar and that is the only secure place for them to be displayed. Seals within the content are pure marketing (and usually marketing for the cert provider, not you), do not add any actual security value and are completely spoofable.
I’m saying you should use the certificates from Verisign/whoever and not have any seal within the page itself. If users want to verify the validity of the connection they should be looking at the address bar. In the case of actual invalid certificates they will get massive warning pages and it’s actually really hard to get through to the fake content.
Thanks Pat, very helpful. I’ve since disabled the seals from the footer and monitoring other aspects of the site. The timeline would definitely be helpful moving forward.
They are still in our cart and checkout process/pages though as we have seen that they do provide a lift in sales/conversion.
I run into the same problem for our site with tests from china node. http://www.webpagetest.org/result/141209_1W_52afa8e8baf401b0f0357860d54ff476/
Pat, can you please provide detail instruction for how you capture the Verisign url that you see from this external script?
The verisign (or other similar) checks only apply to SSL connections and there are none on that page. Whatever is going on is a separate problem. From the timings, my guess is that there is a connection to a domain that is failing but it isn’t showing up in the waterfall (missing feature I’ve been meaning to add for failures in connecting to a server).
To figure out which server is causing the issue your best bet is to capture a tcpdump (in advanced settings). Post a link to it here if you need help reading it.
Considering it’s from China, odds are the great firewall is blocking one of the domains you are using (maybe for 3rd party widgets).