If you are still stuck having to support older browsers when developing your brand new sites, or even developing sites for an intranet, then chances are you are using the X-UA-Compatible meta tag. It’s that meta tag that you place in your header to let Internet Explorer know to use a certain rendering engine. There are a few issues with it though, best practices, validation, site speed to name a few… Lets fix this once and for all!
When Internet Explorer comes across this line it will change the engine that is being used to first Chrome Frame, if the plugin is installed, and then to Edge (the highest supported document mode of the browser). We need to override this in certain situations as by default, any website running on an Intranet will run in Compatibility Mode (Quirks mode) and any website on Microsoft’s Compatibility List will change to it as well.
Note: In Internet Explorer 9 and earlier versions, quirks mode restricted the webpage to the features supported by Microsoft Internet Explorer 5.5. As of Internet Explorer 10, quirks mode behaves differently than the previous versions of the browser. In Internet Explorer 10, quirks mode conforms to the differences specified in the HTML5 specification. For more info, see Specifying legacy document modes.
So If the above line works what is the problem, why should you fix it and what are the reasons you should fix it?
Validation
One of the first things I notice is that this meta tag is used on quite, a few, websites already, but it causes validation errors when checking against the HTML5 doctype. When checking on Twitter what to do about the X-UA-Compatible entry here are some of the responses I received.
@aaronlayton Don’t live your life by HTML validation, sometimes it’s ok to be invalid!
— Colin Bacon (@iambacon) December 20, 2012
@aaronlayton nothing! Validation is just a guide.
— Joe Kendall (@_JoeKendall) December 19, 2012
So should you worry about this? Probably not, but it’s easy to fix and I am a believer that if you can fix a validation error then you should.
Note: I agree that validation is only a guide and I too don’t follow it 100%. It is a guideline of best practices, use it as such.
Rendering Speed
The last nail in the coffin for the Meta fix is the overall rendering speed for your pages. Lets say you are on an Intranet so the website will load up in compatibility mode. The browser will request the page and then start downloading as normal, then it will start rendering as normal… until it comes to your meta tag.
The browser will then have to discard anything that it has done and start all over again. This is the same as causing Layout or Style recalculations, it is just another stop along the way to a fast site.
TMI my friend
Too much information! Now days there are a lot of people out there that don’t use Internet Explorer so you just end up sending this data needlessly. Browsers like Chrome, Firefox, Opera, Safari ..etc… just don’t need to see this, but we send it anyway as adding the meta tag is an easy fix for a problem that only occurs on Internet Explorer.
While the extra 62 bytes are negligible, they are still removable and as we know “Every little helps”. As people are increasingly browsing the internet on some form of mobile device, it starts to become more important to think about all of these small wins. For every byte of data we have to wait, it is another ~ms in the delay to a site being usable. Remember just because you have a fast site, doesn’t mean your user has a fast internet connection.
Visitor loss vs page load time
http://www.pearanalytics.com/blog/2009/how-webpage-load-time-related-to-visitor-loss/
Just removing this meta tag could save you lots of time overall. A site that I work on gets on average 6 million page views a month and if you multiply that through out the year it is still a saving of over 260mb of data.
The fix
The fix is simple enough but obviously it is not as easy as dropping in a line of HTML. The new fix will be implemented server side and to make this fix complete we need to
- Fix the page validation – This is achieved by simply removing the tag
- Rendering speed – Instead of waiting for the browser to see the tag and then change modes we will send the correct mode upfront as a response header
- Make sure that we only show the fix for Internet Explorer – We will just use some server side browser detection and only send it to IE
PHP
To add the header in PHP we can just add this to our page
Or you could add it to your .htaccess file like so
2
3
4
5
6
<IfModule mod_headers.c>
BrowserMatch MSIE ie
Header set X-UA-Compatible "IE=Edge,chrome=1" env=ie
</IfModule>
</FilesMatch>
You can change the files that are matched and doing it this way will mean the header isn’t set for every resource (images / javascript / css). That should be everything to make sure your site is running good and you are following best practices for a PHP site.
C# (csharp)
You could add in a new customHeader to your web.config file like below, but as far as I am aware you can’t do browser detection in here.
2
3
4
5
6
7
8
9
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-UA-Compatible" value="IE=Edge,chrome=1" />
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>
So the better solution would be to inherit all your pages from a custom Controller (or extend from System.Web.UI.Page if you are using WebForms) and add in the following check.
2
3
Request.ServerVariables["HTTP_USER_AGENT"].ToString().IndexOf("MSIE") > -1)
Response.AddHeader("X-UA-Compatible", "IE=edge,chrome=1");
So that’s it… “ Bad value X-UA-Compatible for attribute http-equiv on element meta.” fixed for good…
In the future we won’t need to include this in our projects but for now we have to just stick with it. Let’s hope that everyone adopts Windows 8 😉
