My last batch of articles have discussed which mobile web development best practices I’ve adopted. I obviously can’t claim them as my own creation and should share my resources for these practices.

Some are more mobile-specific then others but all focus on optimizing sites for speed: the number one mobile web development best practice:

1) Steve Souders

The one that really showed developers the way in terms of creating fast-loading sites. Formerly at Yahoo! and now at Google, Steve Souders is the speed site guru mostly on the strength of his two books: High Performance Web Sites and Even Faster Websites. Paul Irish took the best tips from both of these books and applied them to the HTML5 Boilerplate build script.

2) PPK

Web developer Peter-Paul Koch, also known as PPK, is next on the speed guru list. He’s well-known for performing tons of mobile device/browser tests, displaying the results on the mobile section of his Quirksmode blog…spend some reading the Compatibility table on this page.

As he lives in Amsterdam, PPK can perform thorough tests on the Symbian browser, which not only gets heavy usage in Europe, but is also the world’s most popular mobile web browser. So…American-based web developers need to read his Symbiam results on his Quirksmode blog because they will have to code for it sooner than later.

3) Yahoo’s YUI and YDN blogs

Right now, Yahoo! is to site optimization what Google is to SEO: a well-respected authority in their area of expertise. Nowhere is this more clear than within the Performance category of their Yahoo! User Interface Blog (or just the YUIBlog). All of these posts offer great site speed tips, particularly the ones by Stoyan Stefanov.

Yahoo! also maintains the Yahoo! Developer Network blog (YDN), which doesn’t have the depth of site speed advice that YUI does, but is still good. Their “Best Practices for Speeding Up Your Web Site” article is pretty much required reading for any web developer right now, plus, YDN maintains the awesome Steve Souders-created YSlow browser plugin, used for testing a web page’s optimization.

(A related side-note: Yahoo released a beta version of YSlow for Mobile the day before this article’s posting. I downloaded it and believe me when I say that you should too).

4) YayQuery podcast with John Resig

YayQuery is an excellent jQuery podcast hosted by four jQuery experts: Paul Irish, Rebecca Murphey, Adam J. Sontag and Alex Sexton. jQuery creator John Resig appeared on the show in mid-2010, mostly discussing jQuery Mobile.

Prior to jQ Mobile’s release, Resig did a boatload of mobile device research, all of it interesting, quite a bit of it surprising. He shared his findings during this podcast…it’s a must-watch.

5) HTML5 Boilerplate Build Script

I’ve mentioned this before but let me be crystal clear right now: HTML5 Boilerplate’s build script does an incredible job of optimizing site files. With a simple command line prompt (or Windows batch file), you can run all your site files through YUI Compresser, optipng, jpegtran and many other applications to dramatically reduce their file size. The end-result is a faster-loading site.

Watch the Boilerplate how-to video..it’s well worth 28 minutes of your time:

Those are my biggies…feel free to share what you think are good mobile web development best practices because I can’t name them all!

For the Almay/Facebook project I recently worked on, I had to create a Facebook app under their new set of rules, which was interesting.

Creating Facebook apps, which are basically web pages, used to require the Facebook Markup Language (FBML) which is simply a flavor of XML. Facebook recently changed this, saying that developers now simply need to create FB app web pages with HTML, CSS, JavaScript, etc., then host the pages on their own web server. These pages then get fed to Facebook via an iframe.

This is an easier web development process and all the page content displays fine. But I’m in a headspace of creating page code that’s as optimized and as fast-loading as I can get it….my current “thinking mobile” process. That being said, there are two things about the Facebook app setup which, I think, could be made better from a page optimization standpoint.

And it all points back to a JavaScript file named “all.js” that needs to be installed on your web pages in order for the app to work:

1. CSS Expressions

According to my app page’s YSlow report, this “all.js” file is capable of inserting three inline CSS expressions on to the page. Affecting Internet Explorer 8 and lower only, CSS expressions are CSS selectors that are updated and manipulated with JavaScript. Here’s the CSS expression example from YDN page:

background-color: expression( (new Date()).getHours()%2 ? “#B8D4FF” : “#F08A00″ );

Basically, this code updates the background color ever hour; however, it runs much more frequently then that. Simple things like scrolling and mouse movements can fire this code off, which slows down the page overall.

This sucks, but no where NEAR as bad as…

2. Render Tree Reflows

According to Safari’s Activity Monitor, the “all.js” dynamically adjusts lots of DOM properties when scrolling the page. One simple scroll changed the following DOM properties on the fly:

• clientWidth
• clientHeight
• scrollLeft
• scrollTop
• offsetLeft
• offsetTop

Changing properties like this triggers a render tree reflow, the recalculation of a web page’s layout and geometry. All of this takes time and browser resources, meaning all of this slows down a page…no good.

Paul Irish discusses this in his most-recent how-to video, “HTML5, CSS3, and DOM Performance” that’s listed below. He alludes to Stoyan Stefanov’s brilliant reflow/relayout article, which is the end-all-be-all discussion on the subject.

So Facebook apps are now easier to create but, I feel, still need improvement in terms of page optimization. Feel free to comment and agree or disagree.

My last two articles, reviewing my work for both the Almay/Facebook project and the new Mitchum site, have tried to drive the same point home: it’s good to apply mobile web development best practices when coding up a website, even if the site is only meant for desktop browsers. This article expands on that point.


Here are the topics for this article:

• Why We Need To Code For Mobile
• The List of Tactics
• The Golden Rule Of Site Speed
• The Images
• The Page Elements
• Tweak All The Files
• Compress The Files
• YSlow & Page Speed
• Conclusion

Why We Need To Code For Mobile

There are two good reasons for you to start “thinking mobile” when writing code:

• 1) applying mobile development tactics to a desktop-based website results in a site that loads faster.
• 2) in April 2010, Google announced that site speed would be factored into their search algorithm. They were only doing this for 1% of sites at the time of the announcement and I can’t find any statements by Google saying that the number has changed. But you can bet that it will increase as mobile usage, which is VERY dependent on fast-loading sites, also increases.

The List of Tactics

Following the suggestions mentioned in YDN’s “Best Practices for Speeding Up Your Web Site” article is the best way to begin building some best practices into your coding habits. The article lists many things but for now, let’s just focus on some beginning tactics:

• optimize all your photos and graphic files for fast loading
• make sure each page has as few page elements as possible
• remove code that you’re not using
• compress your files
• constantly test your page speed with Yahoo’s YSlow tool and Google’s Page Speed tool

This outlines the “mobile thinking” method I used when doing the Almay/Facebook project I mentioned…let’s walk through that.

First, let’s look at the What’s New section on Almay’s Facebook page which is three pages long and the end result of all this “mobile thinking.” Feel free to review it as you’re reading.

Next, let’s look the golden rule of site speed…

The Golden Rule Of Site Speed

In 2010, the Yahoo User Interface team ran thorough tests on the cache limits of the most-popular mobile devices. They found that the iPad running iOS 3.2 had the lowest limit, only caching elements that were 25.6kb or less.

It’s important to note that newer iOS devices have, at least, double this cache limit. It’s also important to note that these tests show that devices with an older iOS didn’t cache anything at all, affecting older iPhones. And, interestingly enough, the cache limit for the Android 2.1 OS and up can go up to a whopping 2MB!!!

Therefore, the Golden Rule Site Speed is to try to keep the page element file sizes at 25.6kb or lower: this was my mindset during the Almay/Facebook project. Older iPhones can’t cache anything at all: there was nothing I could do about this so I didn’t worry about it.

The Images

With this file size limit in mind, I created image sprites for almost all the site images. I basically compiled a lot of my images into one image like this:

As you can see, this 24kb transparent PNG bundles six images used on the Almay Facebook page, most of which will be used on all three pages of the Almay/Facebook page. I basically used CSS to display certain parts of it when I needed to, while effectively blocking out the others.

Since its file size is less than 25.6kb, the image will be stored in browser cache for most mobile devices. So when it’s needed on other pages, it will be pulled from the cache instead of getting called from the server. The less calls made to the server, the faster the site will be.

There are tons of great sprite tutorials out there so there’s no need for me to create another one. This sprite tutorial at CSS Tricks is simple, yet descriptive. Give it a read.

The Page Elements

As you’re coding, keep a constant eye on how many page elements, or DOM elements, are on the page. A page element is any tag that you have on the page: <doctype>, <div>, <br>, etc. The less you have, the faster the page loads.

Using the Console in either Firebug for Firefox or Google Chrome Dev Tools is the easiest way to do this. Let’s use the one in Chrome tools:

• open your page in Google Chrome
• right-click on somewhere on it and click “Inspect Element”
• click on the “Console” Button
• a command-line prompt will open…type the following line:
  • document.getElementsByTagName("*").length
    

  What this line is saying is:

  • “Go through the entire page and search for all the page elements with a tag name. We definitely want all of them so we’ll add a wildcard symbol, which is “*”. We also want to see the exact number of how many you found, so we’ll end our command with “length.”
    

By doing all of this, I got the page down to 44 elements, which is great! But…

…while having a low amount of page elements is important to site speed, I don’t see them as weighing the page down TOO much. The YDN article points out that the Yahoo! home page loads pretty fast and it has a little less than 700 elements. Yes, the elements should be marked up correctly, but I wouldn’t spend a whole lot of time keeping the total page elements down when you have other things to do. I say, track it…don’t over-think it.

Tweak All The Files

The less code on your page, the smaller its final file size will be. It’s that simple.

I attached the HTML5 CSS Reset file that comes with HTML5 Boilerplate to these pages, which not only makes your site more cross-browser compliant, but also safely renders the newer HTML5 elements on the page without issue.

At a lowly 9.6kb, this file follows the Golden Rule. But I still made it smaller by doing the following:

• the stylesheet adds code for CSS3 media queries…I didn’t create media queries so I deleted that code.
• the stylesheet adds code for that target’s Internet Explorer 6…I didn’t code for IE6 so I deleted that code.
• the stylesheet adds a lot of extra CSS classes that I didn’t even come close to using so I deleted that code.
• Page Speed (which I’ll discuss shortly) showed me which CSS code wasn’t being used so I deleted that code.

Compress The Files

After you’ve tweaked the files as much as you can tweak them, it’s time to compress them, or, “minify” them. Using HTML5 Boilerplate’s build script is the best way to achieve this.

This script does many things: removes unreferenced images, combines multiple CSS files into one file, runs the same combination process for JS files and so on. It also removes whitespace from files and shrinks the images using optiping and jpegtran: for this project, these last two things can in handy.

If you run the build script on a Mac OS 10.x machine, it will only run on a command line via the Terminal application. If you run it on a PC you can run it either on a command line via DOS or with a batch script that comes with the Boilerplate template.

IMPORTANT POINT: if you saved your graphic files using Photoshop’s “Save for Web and Devices…” functionality or something similar, the build script won’t shrink them anymore than that. There’s only so far that you can compress images and saving them out with this functionality takes them that far.

YSlow & Page Speed

As you’re coding, you should use Yahoo’s YSlow and Google’s Page Speed to estimate your site speed. Both are browser plugins for both Chrome and Firefox that scan your code and, based on its findings, grades how optimized for speed to determine how optimized it is.

YSlow grades site speed from A to F while Page Speed grades it from 0 to 100. So obviously, the higher the grade your site receives, the more optimized it is.

After tweaking images, deleting code, limiting page elements and minifying files, the Almay/Facebook earned a B from YSlow and an 85 from Page Speed. Not the highest marks, but good for now.

YSlow for Almay/Facebook Page

Page Speed for Almay/Facebook Page

• No content delivery network (CDN) to store images and files – we have one at Revlon but due to the depth of projects among the web team, we couldn’t configure it in time.
• No gzip compression – gzip compression is server-side functionality that compresses all the site files hosted on your server. This Almay/Facebook content runs on a .NET/IIS setup so setting gzip up would have meant adding the related code to the web.config file,testing it in a development environment, then pushing it to the live site…again, no time.

Conclusion

These are beginning tactics that mostly deal with front end code: there are many ways to speed things up on your web host as well. But if you’re just starting to “think mobile,” start with these steps, then ramp up on the server stuff.

We’re talking about the front end code I created for this Facebook project, but not Facebook itself. I have some things to say about this, none of it good. That will be the next post.