As digital workers we live in an extremely exciting time. New innovations are being developed every day, and they can be used to create incredible experiences for our users. There are endless amounts of fantastic open source projects on Github, and as many tutorials as you can walk through on sites like Nettuts and Smashing Magazine. Easy implementation of previously complex techniques have given rise to an abundance of sites using parallax, draggable elements, CSS animations, the list goes on.
With all of these possibilities, it can be tempting to throw them all into our web pages in the name of creating 'cutting edge' experiences. However, many developers are getting caught up in these temptations and losing sight of the real goal of our websites and webapps: to distribute our content to as many users as we can. As fancy as we can make our experiences, in the end we are still information disseminators and it is important to put on the blinders and make this a priority.
Recently, eyewear company Oakley released a site that did too good of a job at showcasing this lack of focus. On his WTF Mobile project, Brad Frost posted the Oakley site and the shocking 80mb download it required before it rendered. Phil Hawksworth was brave enough to attempt to access the site and wrote a follow up post on his blog that went into greater detail about the "experience".
He was also nice enough to save us all from the same fate and posted his viewing to Vimeo, which unsurprisingly is 60mb smaller than the website itself.
This is an almost comically exaggerated example, but there are many websites that are attempting similar effects and doing a huge disservice to their users.
Scott Jehl from Filament Group has a great talk that goes into great detail about this, and his experiences in rural Asia drive home the impact that oversights like this can have. Two minute downloads for a single website is bad enough on broadband or fiber, but the problems become even more obvious when thinking about the accessibility not just by us few that are lucky enough to have fast computers and connections, but those that don't have the means to have more than a dial up type connection.
After spending the past eight days in India, I have been able to see many of these problems first hand. The company I work for has a team in Pune, and the time difference requires us to visit each other once in awhile to get through big projects face to face. Working in one of the upcoming IT hubs in a country brimming with young technologists and programmers, the problems with the way many websites are developed come into focus more than ever.
Workstation In Pune
Most of my coworkers here are single, and they are all in their mid to early twenties, speak great English, and have well paying jobs that affords them disposable income. Not only that, but they know computers better than most of the people I know in the west and they all own smartphones. Unfortunately, the electricity and internet here is spotty at best. There are frequent rolling blackouts that cause the building to go dark and the internet to reset for a few minutes at a time, and the ISPs are unreliable enough that constant router and modem resets are a daily ritual. Keep in mind, this is in a brand new technology park housing beautiful office buildings. Many of the situations in Scott's talk appear here, and websites with a much smaller load than Oakley's can still be too large to be rendered properly. There are over 3.1 million people in Pune, and this is a **small** city compared to others like Mumbai, Delhi, and Bangalore. That sounds to me like an Internet marketer's dream, and certainly not a market that you would want to overlook.
Brand new office building going up across the street
Considering the purpose of adding these features is to bring new users to see your content, all of these bloating features start to seem extremely unproductive. In an era of fast advancement of the web, this is an area where we have taken a huge step backward. There are a few main problems showing up consistently in today's websites.
One of the most overlooked and potentially damaging issues with website reliability is the amount of HTTP requests the website needs to load. Every single asset including individual images, external stylesheets, and JavaScript files require a separate request from your computer to the server before the entire website will render.
A bare minimum website done for a client may look contain something like the following.
That's thirty five http requests on a simple website, and there are few times a client would ask for less than this. Now keep in mind that modern browsers can run about eight concurrent requests at a time and that they each represent a point of failure for a user trying to access your content. The statistics kept at the http archive showcase the problems with many modern websites.
In May, the average website had to make 91 requests in order to load fully. That's a huge burden for a slow connection, and an avoidable option when there are other sites that will reliably load.
All of the sample files in our bare minimum website can be optimized to cut down on requests.
With web designers leaning towards using icons along with titles in their menus, adding tens or hundreds of icon images can increase requests quickly. Using sprites is an easy way to cut these down to one request for a single image.
In the age of table layouts and Photoshop to HTML conversions, it was common to slice up a website design and then stick the pieces back together in the HTML. Though loading them seperately (and visually seeing them load individually when the page is loading), made the page appear to be quicker, it was also creating far more requests and increasing the amount work that had to be done before the content was fully loaded. Because we have the ability to display only certain parts of an image using positioning, we can simply place all of our small icons and image in one PNG and only show the area that makes sense.
For example, if we wanted to show an icon before the titles in our navigation using the pseudo :before element, we could do the following.
Normally, we would add the images seperately.
Instead, let's combine the icons into a sprite image.
Instead of copy and pasting them seperately...
Taking another look at the total transfer chart from earlier, there is another obvious problem. The asset size of an average website is 1.4mb, which is bulky especially when considering those who buy mobile data by the megabyte. Constantly testing on amazing connections can make us take things like download speed for granted, but viewing any of these "average" sites on a mobile connection in a rural area will show you immediately why this trend is a problem. Like the issue of http requests, this is a common problem that already has many possible solutions.
One of the complaints against many of the new JavaScript libraries like jQuery is that they are too bulky to be used efficiently. There is certainly a lot of functionality packaged inside these libraries, much of which will not be used depending on the site's functionality. Luckily, many of these libraries offer custom builds of their libraries so you can keep your users from requesting and downloading unnecessary code.
The jQuery UI project includes a Download Builder directly on it's download page.
Simply piece together your ideal build eliminate the need for unnecessary bulk. jQuery UI is a great example of a framework that has a lot of great potential, but applying it all to your website when it is unused or unnecessary can result in a lot of added load time. MooTools has a similar Download Builder page for your convenience.
If your favorite library doesn't have a custom builder, RequireJS is a widely popular module loader that services a similar purpose, and is extremely beneficial if you are using multiple libraries and plugins or have your own spread of JavaScript files that are each used in different locations. All you need to do is link to the require.js file in your markup, then use require() to dynamically load your JavaScript modules as you need them.
It is easy to see the massive potential of this new spec, but it isn't something that can be used in production yet. Because of this, Scott Jehl created Picturefill, a polyfill that expands the picture element idea but uses currently supported <div>s instead. This allows the same responsive image techniques to be used right now. The following sample markup is given as a starting point.