The use of document.write() has always been a bad “code smell” in JavaScript. Most web performance guides such as WebPageTest and Yahoo Exception Performance have warned against this practice.

In most cases, document.write() can be replaced by inserting innerHTML into an empty element after the rest of the page loads. This approach also allows the developer to “think” about how the page might react in cases where JavaScript is disabled or not available on the client.

Google has recently changed the default behavior, such that when on a slow (currently 2G) connection, but discussions have also leaned toward including any slow connection.
As such, right now, the following will occur on slow (2G) connections:

For users on slow connections, such as 2G, external scripts dynamically injected via document.write() can delay the display of main page content for tens of seconds, or cause pages to either fail to load or take so long that the user just gives up. Based on instrumentation in Chrome, we’ve learned that pages featuring third-party scripts inserted via document.write() are typically twice as slow to load than other pages on 2G.

My advice – remove all use of document.write() for required content in your code now, as your users MAY NOT see that content if you do not.

Link prefetching is used to identify a resource that might be required by the next navigation, and that the user agent SHOULD fetch, such that the user agent can deliver a faster response once the resource is requested in the future.

If you look at HTTP Headers as often as I do, you’ve likely noticed something different in Firefox 44 and Chrome 49. In addition to the usual ‘gzip’, ‘deflate’ and ‘sdhc’ , a new value ‘br’ has started to appear for HTTPS connections.

The smaller compressed size allows for better space utilization and faster page loads. We hope that this format will be supported by major browsers in the near future, as the smaller compressed size would give additional benefits to mobile users, such as lower data transfer fees and reduced battery use.

Website network performance is usually a very complicated process. Over the years, I’ve outlined many development techniques that can be used toward this goal. I’d heard about mod_pagespeed for some time, but never had the opportunity to experiment with it until recently. My first impression is that it is a VERY EASY means to gain performance improvements without reworking your existing website to implement techniques for establishing far-future expires, cache-busting, minification and static file merging.

Out of the box, most common techniques are automatically applied to your assets and a local server cache is created to utilize them.

Default installation is trivial:

Download the latest version for your server architecture:
wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-stable_current_amd64.deb

OR
wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-stable_current_i386.deb

sudo dpkg -i mod-pagespeed-*.deb

sudo apt-get -f install (if required)

sudo service apache2 restart

NOTE: Using tools like Firebug will enable you to see an HTTP Header indicating the version being used for your requests.

If you need to modify configuration from the default:
sudo vi /etc/apache2/mods-available/pagespeed.conf

For VirtualDomains, you can selectively enable and disable PageSpeed and many of it’s settings in your appropriate configuration files with:
<IfModule pagespeed_module>
ModPagespeed on
</IfModule>

NOTE: Appending ?ModPagespeed=off to your URL will disable functions for that request.

This HTML4 attribute was intended to defer/delay execution of specific javascript code until after the page is rendered. In theory, this makes the website “appear” faster as the functions relevant to the User-Interface can be executed before other “background” processes that would otherwise block the screen from displaying.

<script defer="defer" src="example.js"></script>

NOTE: Do not use defer for external scripts that might depend on each other if you need to support MSIE9 and earlier.