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.
<link rel="prefetch" href="http://www.example.com/images/sprite.png" />
<link rel="prefetch" href="/images/sprite.png" />
- MSIE 11+/Edge
- Firefox 3.5+ (for HTTPS)
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.
Compared to gzip, Brotli claims to have significantly better (26% smaller) compression density woth comparable decompression speed.
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.
- Brotli outperforms gzip for typical web assets (e.g. css, html, js) by 17–25 %.
- Brotli -11 density compared to gzip -9:
- html (multi-language corpus): 25 % savings
- js (alexa top 10k): 17 % savings
- minified js (alexa top 10k): 17 % savings
- css (alexa top 10k): 20 % savings
NOTE: Brotli is not currently supported Apache HTTPd server (as of 2016feb10), but will likely be added in an upcoming release.
Until there is native support, you can pre-compress files by following instructions here…
While many people are happy when images from their websites get “pinned” on Pinterest, there are many times that you might not be so pleased. You may have a need to prevent images from being shared for copyright or similar reasons, or simply not want the extra website traffic.
Thankfully, you can stop this with the addition of a simple HTML META tag. Also, if you already use CloudFlare, they can add it for you at runtime!
<meta name="pinterest" content="nopin" />
There’s yet another new means to ‘help’ client User-Agents with preventing XSS on your websites.
In it’s simplest form you can simply use the following HTTP Header(s), the second one is for earlier versions of Webkit (Chrome/Safari):
Content-Security-Policy: default-src 'self'
Webkit-CSP: default-src 'self'
You can also add to the above to permit assets to load from other sources.
Content-Security-Policy: default-src 'self'; script-src http://example.com
Additionally, while failures are noted in the client’s browser console (that most users are not aware of), you can have them sent back to your server by adding a ‘report-uri’ attribute with an appropriate handler:
Content-Security-Policy: default-src 'self'; report-uri http://example.com/csp-report.php
Yahoo! initially introduced a CSS class that can be used to notify robots/spiders that a specific section or fragment of content should not be included for search purposes.
Most developers (myself included) are often unaware of the performance impact of the Content-Type / charset of a web page. Ideally you should set this as an HTTP Header vs. using
META http-equiv. It’s often though that this only helps with the transport and display of data, however, the browser also makes use of it when parsing CSS & JS assets. Tags related to those provide an optional ‘
charset‘ attribute should they ever need to vary from your content.
General guidance is to set this at the very top of the
<title> and within the first 1024 bytes, though there are reports that Firefox will look at the first 2048 bytes of the page for this
Not doing so may cause the browser to do a codepage restart to re-parse assets that were interpreted in the potentially incorrect codepage.
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
Best practices for web applications often call for the use of a CDN. Those of you that have worked with YSlow! are likely very accustomed to seeing warnings for this reason. I’ve found that CloudFlare is very easy to setup, and for basic services costs absolutely nothing. In addition to the obvious performance advantages of using a CDN to offload much of your network traffic, it also has the advantage of improved security.
CDN’s work by caching a copy of your static content at several locations around the world, making it closer and faster for your users.
Implementation takes only minutes as it requires that you:
- create a (free) account,
- retrieve your existing DNS values from your current provider,
- determine direct vs. CDN “cloud” routing for each subdomain,
- change your DNS records to point to the CloudFlare DNS servers
Some additional advantages I’ve seen since implementing:
- Site remains available in limited capability to users during server outages or upgrades.
- Simplified network configuration as all requests can be sent outside of the LAN for users local to the servers
- IPv6 dual-stack support
To prevent XSS/CSRF exploits in MSIE8 and newer, it’s often best to close as many attack vectors as possible. An easy one to implement is an HTTP Header to prevent MSIE from “sniffing” the content to change it when incorrect.
Example: we would not want an HTML page intentionally served with ‘text/plain’ to be rendered as HTML.
This could be added programatically to pages in your application, via a servlet or servlet filter or added to the httpd.conf file.
Apache2 example: httpd.conf
Header set X-Content-Type-Options nosniff