Basically we have zero posibility to do a full page cache implementation (for business model, fresheness of the results), that is the first constrain, the second one is that in some countries (not the one of the example) the query to SOLR is extremely slow.
In order to improve performance we’ve implemented an early flush (chunked delivery) of a part of the that includes a of the javascript resource (in mobile we embed the css) that is included in the footer with an defer tag (to avoid render block because is not critical for our business, only adds enhancement and lots of trackings )
In the attached screenshot the WPT test looks like the DNS lookup consumes like a lot of time… and the position where the script does the preload is like not in the head but in the Chrome console (throttling a ‘Good 3G’ connection) the script is right where is meant to be.
so i’ve two questions: Is there any explanation for this behavior? and… i’m doing something wrong or harmful for the site performance?
It looks like the Internet takes a fairly long route to get to your origin from EC2 Brazil: http://www.webpagetest.org/result/170123_WF_14R5/ (somewhere around 300ms) which gets added to the 3G connection profile. That is likely why the first request takes so long for each of the components before the content actually starts downloading.
That said, the long DNS for the script could have been an intermittent issue. I recommend always running at least 3 runs when you run a test just to be sure it isn’t an outlier. That said, I saw similar behavior every time.
Chrome’s built-in throttling doesn’t work at the connection level and doesn’t slow down DNS lookups or socket connections so it isn’t going to be all that useful to compare to.
You were right, the server chosed for the first test was from BR and we serve the page from Barcelona, so… yes a big round trip time there (we’re working to serve locally through Amanzon but that is going to take a while)
Since that original post i’ve been doing some improvements… i implement preconnect and preload (only Chrome supports them for now… but that is better than nothing :), we already had dns-prefetch.
)
(we’re working to serve locally through Amanzon but that is going to take a while)