It is generally accepted that web pages should have a meta tag to set the charset of the document. However, you may not need it. The HTML5 specification clearly states that when determining the character encoding that if it is found in a content-type header attribute, then the engine should no longer look for one in the document or anywhere else. You can set the header either in your application logic or in your server configuration (Apache and Nginx examples).
Well, we all know performance matters. Let's say after gzipping your content this declaration adds just an extra three bytes of data to your page. Across millions of requests around the web per hour which leads to billions per year, that ends up saving a lot of space.
Not only that, but think about how the network functions. Packets on the internet have a set amount of space. This is called the maximum transmission unit size. It is generally at 1500 bytes per packet for ethernet. This makes what is in your initial packet or two going to a client of the utmost importance. Why should a few bytes be wasted on a charset declaration when that is already done in your header? Or, why should you run the risk of needing a whole extra round trip to the client to finish off a pages content, when it could have been done in one less trip if this declaration wasn't in your page needlessly?
Every byte counts when the network conditions are against you. This is especially true on mobile networks. Check the headers on your site, and if you see a content-type set, then drop this declaration from your document and profit.
So what does this mean for developers?
Well, we all know performance matters. Let's say after gzipping your content this declaration adds just an extra three bytes of data to your page. Across millions of requests around the web per hour which leads to billions per year, that ends up saving a lot of space.
Not only that, but think about how the network functions. Packets on the internet have a set amount of space. This is called the maximum transmission unit size. It is generally at 1500 bytes per packet for ethernet. This makes what is in your initial packet or two going to a client of the utmost importance. Why should a few bytes be wasted on a charset declaration when that is already done in your header? Or, why should you run the risk of needing a whole extra round trip to the client to finish off a pages content, when it could have been done in one less trip if this declaration wasn't in your page needlessly?
Every byte counts when the network conditions are against you. This is especially true on mobile networks. Check the headers on your site, and if you see a content-type set, then drop this declaration from your document and profit.
Updates
- According to freeone3000 in IRC if you are targeting feature phones or other systems that use middle proxies to try and conserve bandwidth, you will need to keep the charset declaration anyways. Because they are built to work off the charset tag instead of headers. I have no other sources for this information, so it is only something to keep in mind that could become an issue.
- Also from freeone3000, the charset tag is the only way for browsers to detect the encoding offline. Maybe some testing should be done to see if browsers save with the encoding type given and will open with that as well from the file. However, if you can't specify the character set in a manifest.xml for offline apps, then that should probably get looked into for App Cache 2.0.