Hey Pat,
We started seeing some odd behavior in our waterfalls starting around Oct 29/30th. We are seeing long SSL gaps with our sites with EV certs. In some cases the waterfall looks normal(run 1) but all other cases have the gap. We’ve checked on our side and can’t pin this down to anything that was changed. It’s across several of our sites and we can’t find a common link between them. Is there anything going on with the WPT system that would cause this?
The gaps is when the browser is issuing OCSP requests to check the validity of the certificates. In case of EV chain it seems to be aggresive, and will try to check the status of all of the certificates in the chain, and it also seems that this operation is blocking.
Unfortunately it’s not shown in the waterfall - it’s just a gap, but if you swithc to firefox - it all becomes clear - what is going on behind the scenes, you can see all the ocsp requests clearly. Have a look here:
You can enable OCSP stapling on your server - but this will cut just one OCSP request, the rest will still be there.
Debugging OCSP is hard, as no dev tolls will show you those requests being made - you need to dump the traffic, and analyze it later. You can do it easily in WPT in the options.
Just a follow up. Noticed this issue is no longer happening and we have not changed anything on our side. This had to have been some kind of bug with WPT and EV certs:
There were 2 changes made recently that could be responsible:
1 - I switched back to using dev tools timing data instead of netlog. It’s more reliable but not as granular and it’s possible that gaps could now be hidden in the actual negotiation times. I have work on deck that will remove any dependency on getting timings from Chrome but it won’t be ready for a few months.
2 - (most likely) I changed the chrome extension to not intercept every network request to modify the outbound headers and add the PTST string to the UA string (it is added differently now). Apparently there is a CRAZY amount of overhead in routing the requests through the extension.
Awesome! Thanks for the response Pat! I know we bug you a lot about bugs and such with WPT but it shows you how much our company relies on your tool. Keep up the great work!
This doesn’t make any sense, all the metrics are faster than the ones from the non-EV test, but the EV one is still getting the “F” grade. It’s as if the gaps were still there - maybe not visible anymore in the waterfall, but these are still taken into account when calculating the grade?
Thanks. I’m planning on re-vamping the target TTFB logic as it seems to have a fair number of cases where it is calculated incorrectly. Should be fixed in the next couple of days.
[quote=“pmeenan, post:8, topic:9665”]
OK, just finished fixing the TTFB grading logic so it should be a lot more consistent (and logical) now.
[/quote]Is this also partly addressing the unattainable target FBT times when a CDN is detected?
