There’s nothing more discouraging than stepping in front of a mirror on New Year’s Day and seeing the travels of holiday feasting in every curve, lump and sag that you don’t remember being there in November. Wouldn’t it be nice if you could just slap on a Tatum Channing or Penelope Cruz suit and step out into the New Year without the bathroom scale and mirror taunting you?
This is probably what’s going on with your web site, right now. It may be beautiful, chic, and web 2.0 on the outside, but the outer skin is probably lying to you, hiding a twisted nest of bloated code, heavy graphics, and inefficient methods under the hood. Like the extra padding that has winnowed its way to your waist on New Year’s Day, this can affect your web site’s health in ways you’ve never thought of.
I’m an old school coder. In the early days, we were forced to understand the importance of efficient coding. Broadband was just a concept and our downloads were measured in kilobytes, not terabytes. Every line of code, graphic, element or widget had to be examined for importance to the message, optimized for speed over quality, and eliminated if it didn’t make the cut. Today’s resources have left developers unbound by the limitations of bandwidth and user environment, and they can pretty much code any way they want (and get away with it.) Who cares if it’s inefficient, if it works, it works, right?
Things are changing; the rise of the mobile web has brought the need for efficient coding full circle. Today it’s more important than ever to consider your end user’s environment and code as efficiently as possible.
We Don’t Mean To. Really.
The coders of today aren’t evil (well, some of them are, but that’s a different story.) They’re trained by a very basic programming concept: “don’t re-invent the wheel.” If a class or library exists that does what you need it to, no matter how monolithic its libraries or how demanding it is on resources, then use it. This is how one bloated resource gets piled on top of another, dependency on dependency, until what you wind up with is a very slow web site that does poorly in search results.
Did that one get your attention? In 2010 it became clear that Google added the speed at which a web page loads to its ranking algos.1 Page speed is indeed one of the many factors that helps you achieve respectable positions in SERPS or sends you to page 50.
It’s also important to mention that developers aren’t always the culprit of a heavy web site. To code a site efficiently one must first have a design that lends itself to lightweight implementation. Full page or other heavy graphics are an issue with design, not coding.
Cutting the Fat
What are the signs my site is not as efficient as it could be, and what can I do about it? There are several things even the non-technical site owner can check to increase performance. Let’s look at the client/design side, where the pages are rendered in your browser, and work down to the server level, where your web page requests are served.
There are many speed test web sites out there to check your site’s performance. Pick at least two of them and run some tests on an average page of your web site. One such site:
The reason for this is that different sites will check your site over different networks, and you can eliminate a reasonable variation in bandwidth from your load time assessment. Be sure to print out or save the results of your tests for comparison after making changes to your site.
#1: Number of Requests
From the tests, look at the number of requests sent to the server for this one page, and compare those with your competitors or a similar page. Are there ways you can reduce the number of those requests? According to Google’s metrics (from 2010,) the average web page makes +-44 request to the server.2 Every time you load a page, you’re making requests from that server 44 times. Any slowness in the connection or difficulty in making the request is amplified by 44. It’s important to note that this is just an average – larger sites often make many more requests.3
#2: Optimize Files
#3: Use CSS Sprites
The genius of proper use of CSS sprites is that you can convert multiple requests into one. Instead of, say, 10 images for a graphic-based navigation, we just load a single image and position it on each element as needed.
#4: Combine Files/Eliminate Excessive Files
#5: Uncomplicate Dynamic Coding
#6: Uncomplicate Your Layouts
One of the gripes I have with WordPress is that the underlying structure, “out of the box,” is excessively complex. Div’s inside div’s inside other div’s when usually only one or two of these are required to output a page. For each of those extra elements, there are multiple selectors in the CSS that also aren’t necessary, increasing the problem. Additionally, the more elements there are, the more time and memory it’s going to take the browser to render. Every byte you eliminate from your page will increase its speed, and it all adds up. Can any elements, containers, or boxes be eliminated from the markup to reduce its load time?
#7: Avoid Inline Markup
The initial source code of your page can be optimized too. If you can view the source code of your page and see multiple instances of inline markup (<style> tags, <font>, or other presentation elements,) your page can be optimized considerably. All of your presentation styles should be in an external style sheet. Adhering to these coding practices will make your pages easier to maintain as well.
#8: External Requests
Not to be confused with external requests to a CDN (Content Delivery Network,) try to localize files that you can localize and minimize external requests, which sometimes can’t be avoided (such as tracking, analytics, and social media codes.)5
#9: Use Only the Resources You Need
At its most basic level, serving up web pages is a very fast process, taking nanoseconds to perform. In later years this process has been complicated with CMS technology (Content Management Systems.) CMS’s are database-driven server softwares such as WordPress, Drupal, modx, and others that allow site owners to modify their site content and output dynamically driven pages. Your website now doesn’t directly serve a page, it connects to a dynamic programming language, which connects to a database, does some magic stuff to it, then serves the page.
Consider it an “added feature” to your web site: you can now edit it but it’s going to require more players in the game to serve your pages, consume more memory and resources, and can potentially affect site responsiveness. Do you really need a CMS? If so, does it require large resource intensive libraries or frameworks? Are there lighter weight solutions that serve your needs?
#10: Eliminate Excess CMS Code
No matter what CMS you are using, find out if the database server is a local or remote server; if the remote database server is slow or unresponsive, it will slow your web site with every page request. Find out what plugins, modules, or add-ons your CMS software is using, and the performance effects of each. Can you live without any of them or find faster ones?
#11: Enable Gzip
Gzipping basically compresses all files on the server, then when requested, the browser will uncompress them prior to rendering. This is a fairly technical implementation and often not supported by all environments, but if you can implement it, you should.
#12: Server Environment
Are your expectations unrealistic for the environment you’ve selected? A CMS may suffer performance hits in a shared environment, but may thrive in a VPS/VDS. After pursuing all the items above, consult a developer for advice on whether the selected environment is underpowered to run your web site.
#13: Server and Rewrite Optimization (warning: tech talk ahead)
Here is one quick fix for WordPress (and most CMS softwares like it) that I’ve seen speed up web sites as much as 200%. Unfortunately it’s a bit technical, but it’s also the one server-level optimization that can do you the most good with the least investment.
Most CMS software that implements “pretty” or “search engine friendly” extensionless URL’s comes with this bit of mod_rewrite code for the domain’s .htaccess file. It is the “engine” that turns ugly query string URL’s into pretty, keyword-rich, extensionless URL’s.
What does that do? “If the request is not a file, and the request is not a directory, send the request to index.php.” Index.php then determines what “the request” is (identifies the URL) and outputs the appropriate resource.
RewriteRule ^([^.]+)$ /index.php [L]
“If there’s no dot in the requested file name, send it to index.php.” No searching the file system at all.
This is by no means an exhaustive list, and each web site will have unique conditions that will determine the degree to which these suggestions will apply.3 You may not need to implement them all, and sometimes you won’t be able to follow all the rules (like this blog post,) but if your site is slow and bloated any of these suggestions could help. As you dig into the details of your site and see what pages are slow, you’ll also see which ones are fast, and learn why, which will lead to faster loading pages for your visitors – which is really why we’re here, isn’t it?
4 Often multiple files is an optimization in itself; for example, if there is a single page that requires additional CSS, it does the rest of the site no good to carry around that added CSS in the master style sheet.
5 A browser can make multiple connections at once, which makes external connections to CDN’s or subdomains a way of speeding up the web page. Here we refer to connections to sites that, if they have a slow response time, will affect the performance of your site.