Skip to main content

You may not need meta charset

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).

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.


  1. 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.
  2. 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.

Popular posts from this blog

Laravel, Codio, and Nginx

I have recently come across a *sweet* online IDE, this would be Codio . Codio lets you develop in the cloud and run the code on an actual server. This way you can write your code and run it in the cloud, keeping your development environment universal and in my case safe-guarding against my own nonsense. While Codio does offer their own  documentation  on getting Laravel going, it uses Apache and MySQL. So here is getting going with Nginx, MariaDB, and PHP-FPM on Codio for Laravel development. Create your project Create a project just how you normally would, except select "Git" as the method for getting the base code into the workspace. This will give you an input where you can either put in an HTTP or SSH based git repository URL. If you are using SSH and you haven't setup the SSH key on your repository, it will prompt you to do so automatically with a key Codio generates. For now, I'm going to just use the standard HTTP URL for Laravel which is

My PHP Wishlist

PHP Wishlist These are things that I think would help developers build better programs with far fewer lines of code. Simple enough? Let's get to it. Scalar Type Hints and a Strict Mode Currently one of the hottest RFCs in PHP history perhaps, Scalar Type Hints. This is a feature that allows developers to specify any type a given parameter should be. Currently PHP only supports object types and arrays for type hinting. This allows for string, integer, boolean, and the like.  However, nothing is simple in PHP. With this, some developers want conversion to happen if the wrong type is given (string to integer for example if '3' is passed in) while others want strict enforcing of types. The RFC has a middle-ground of loose typing by default like everything else in PHP, but the option to turn on a strict mode. My issue with the RFC is... The syntax is horrible for declaring strict mode. I was actually entirely for it up until a few days ago. I read a comment on

Form macros in Laravel

Form macros are a really cool part of Laravel. They are described in the documentation , but that doesn't show you exactly how to use them in your application. So here is how I do it. Load macros on the start of the application To register the macros if we follow the docs we simply need to do something like Form::macro('myField', function() { return '<input type="awesome" >'; }); But how do we get this to load when needed? My solutions is to simply have it load on the start of the application. I do this by making a folder in my app directory called "misc" which just holds files for different things that I have to startup this way. Inside of that folder I make a file called "form_macros.php". To load this file on startup, we are going to require it within app/start/global.php. Simply add require app_path() . 'misc/form_macros.php'; to the end of the global.php file. This will make sure that the form macros are