A tool that we ran against some of our sites is Google’s Page Speed (http://code.google.com/speed/page-speed/), which is a free Firefox plugin. After running the tool, we were presented with a Page Speed Score, which is a number between 1 and 100 that is based on a number of criteria, including browser caching, downloads across hostnames, static content, minifying CSS, etc. Although some of the items are a little more difficult to tweak without a major overhaul, we noticed that some items can be tweaked with minimal effort. Some of the easy fixes we were able to implement to boost our score (by an average of 8 points) were:
We then got curious and ran the tool against several popular websites, such as Google News, Apple, Yahoo, Dell and Microsoft. Needless to say Google News had the highest score (98, no surprise there) and Apple had the lowest (71, kind of surprised). The one metric that this tool does not measure, which I would like to see, is server load time. Overall, we have found Google’s Page Speed tool to be a valuable part of our SEO implementations projects.
Smartphones are becoming more commonplace among mobile phone users these days. People are now relying on them for daily functions such as checking email, running applications and browsing the internet. Most, if not all smartphones come bundled with some sort of web browser. One of the many challenges web developers face is getting mobile websites to render properly amongst the many different mobile web browsers available. A tool that web developers can use to see how their mobile pages will render, prior to implementing in a live environment, is called a mobile emulator.
There are many different mobile emulators, some of which are free, that can be downloaded from the internet. These emulators work fairly well, but I’ve found that they portray a somewhat idealistic view of how certain devices will behave. For example, recently we have begun developing several mobile websites for clients. When a certain website was in the testing phase, we used a variety of different mobile emulators to see how the website would render on the multitude of mobile devices available. One specific device that we tested for was a BlackBerry. The emulator displayed the site just as we intended, but we noticed after we rolled out the site and started testing it on the actual devices that some BlackBerry devices would not render the website properly. After a lot of head-scratching and research, we found that the default settings for some BlackBerry devices turned off critical browser functions, such as CSS and tables, in order to speed up download time. Once we made the necessary settings on the BlackBerry device, the page rendered as intended.
There is still a lot of trial and error when it comes to mobile development. What we have learned, is not to rely so much on mobile emulators, but rather use them as only one part of the testing phase. Of course, you can’t test your mobile websites on all the actual mobile devices available, but in time, you will learn the various nuances of the most widely used ones, so that you can then explain to your clients how to get the most out of their mobile browser.
More and more frequently companies are adding a mobile version of their website to their online arsenal. Mobile sites are a great way to provide quick information to people on the go or to serve as a portal to your main website. There are many different ways for a user to arrive at your mobile site. The simplest, is to just place a link on your main site to the mobile version. That kind of defeats the purpose though, because mobile devices have a limited viewing area, so users may never be able to find the link, which would render your mobile site almost useless. The most ideal way for your users to find your mobile website is to place a browser detector script on your main website’s homepage, which will then redirect the user to your mobile website, if they are using a mobile device.
If your website is one of the unlucky ones that is exclusively using HTML, you may still be able to properly redirect your users to your mobile website. The first thing to determine is if your host allows you to run a server-side scripting language. Just because your site is coded in HTML does not mean your host does not allow you to use a server-side scripting language.
If your host does allow you to use a server side scripting language, then you have two options. The first is to have the HTM and HTML extension be processed by a server-side scripting language. This means that although your page is an HTML page, it will be able to process server-side code, such as ASP or PHP. This approach is probably the easiest and does not require modifying any of the actual code of your website. There are many different ways to create this setting, but you should check with your host or IT department to see if this is possible with your current hosting setup.
If your host does not allow you to change the way HTML or HTM files are processed, your next option is recode your site’s homepage in a server-side language that your host allows. This could be as simple as saving the current homepage, index.html for example, to a new extension, such as index.php. After you do that, it is extremely important to 301 redirect the homepage URL to the newly created URL. Again, check with your host or IT department to see if your hosting setup has the ability to perform 301 redirects. If you cannot perform 301 redirects, then you should manually change all the links back to your new homepage and do a meta refresh to the new page. A meta refresh is not ideal for SEO, but it is the only way to preserve links to the old homepage. The only other alternative at this point is to select a different host.
Now that your homepage is set up for the browser detector script, you just need to add it to your homepage. I will discuss how to do this in a future post, but as you can see, there is a lot to consider when “going mobile” and you need to make sure you have all your ducks in a row, or your new mobile site will never get the traffic it deserves.