Next gen optimizations

Hi Patrick,

We have tried all possible site speed optimizations to improve the site speed and looking for more new optimization techniques.

In our HTML, we have lot of white space. This would not effect the payload to be downloaded since we use GZIP. I am wondering whether this extra white space in the HTML effects rendering (slowness in rendering)?

If you have any new site speed optimizations, please let me know.


Do you have a link to a test result or a page that you can share? It’s unusual for someone to have exhaused all optimizations so there may be some not-obvious ones (Data URI’s, async scripts, etc).

Unless you have HUGE amounts of whitespace it won’t have a measurable impact. It will use more memory and take a little longer to parse but it should compress away on the wire so you’re probably talking microseconds (depending on how much whitespace).

Megabytes of whitespace could certainly be an issue, particularly for mobile.

Here is the link :

We tried following.

  1. Progressive rendering (chunked encoding)
  2. Added image dimensions
  3. Moved all the JavaScript to bottom of the page (It improved rendering speed significantly).
  4. Using Data URIs for the above fold images


I really like DNS prefetch as it is pretty much a free win as far as I can tell.

Putting an empty body tag before the css might get Chrome to request a few of the css images a bit earlier. i.e. to behave like FF.

And that’s me fresh out.

@p83822 : Yes, I am trying DNS per-fetching already. Can you provide a sample HTML for chrome optimization you are talking about.


From the looks of things, your biggest bang would come from doing more work on the back-end. Looks like chunked encoding and early flush is working fine but the thumbnails don’t start loading until the base page completes the more expensive operations. Given the scale of your systems I’m sure it’s not a simple task but it looks like you have 500+ms of savings that you could achieve if you can get the back-ends to respond faster.

I’d also spend some time digging into the visual experience:

It looks like the results don’t display at all until well after all of the product thumbnails have loaded (and well after the content itself should be available). Under the advanced settings you can capture a dev tools timeline if you use Chrome for the browser and that should help track it down but without knowing the page logic better it’s hard to say what is causing it to block for so long.

I ran a test using Chrome which also provides the “Initiator” (line of code that causes a given resource to load) and it looks like there is a combination of the first 4 thumbnails being loaded directly by the HTML and the rest being filled in by javascript:

The javascript that is used to load the other thumbnails is loaded pretty late in the waterfall and holds things up as a result. I don’t usually recommend moving javascript higher but since you have some spare time because of the back-end processing time you would probably benefit from loading the script in your first flush so it is ready by the time you need to start loading the thumbnails.

You might also want to look at using Data URI’s for those first 4 thumbnails and embedding them in the HTML directly.

Thanks Patrick for the response.

Regarding results don’t display until all product thumbnails have downloaded issue is only specific to all versions below IE8.

Here are IE9, Chrome and Firefox webpagetest links which are not having this issue. In these tests I am not using JS to load the images and first 6 images are Data URIs.