Is Your Site More Bloated Than After a Holiday Dinner?

code bloat

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.

Speed Test

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:

Web Site Optimization Test

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.

Client/Design Side

#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

Can multiple CSS files be combined into one, then optimized, and the same trick applied to included Javascript files? Are there features that aren’t so necessary that they cost your customers extra wait time when visiting your page? The first stop is to reduce the number of requests.

#2: Optimize Files

File optimization is as necessary today as it was in 1995: can your images and included files be compressed into smaller file sizes? A common trick for Javascript, CSS, and other text-based file includes is to run the deployment copy through an optimizer that removes all white space (a process called “minifying”,) sometimes saving up to 40% of the original file size.

#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

View the source code of your page. Look in the <head> section for included files; these will generally come in two flavors, CSS and Javascript. Examples:

<link type=”text/css” rel=”stylesheet” media=”all” href=”/defaults.css”>
<link type=”text/css” rel=”stylesheet” media=”all” href=”/system.css”>
<script type=”text/javascript” src=”/jquery.js”></script>
<script type=”text/javascript” src=”/utilities.js”></script>

How many of these included files can be eliminated or combined?4 Do you really need jQuery on every page to do something that can be coded in 20 lines of Javascript or less? I have observed pages with up to 20 Javascript library includes for functions that can be coded with a single jQuery library and a few lines of code. Which brings us to . . .

#5: Uncomplicate Dynamic Coding

Javascript and its jQuery library are the tools responsible for most of the fading, sliding, flashing, and animating you see on the web, and often manifests itself via multiple libraries in the head sections of web pages. Are these libraries overkill for some of the more simple functions on your web site? One example is the use of Javascript to create drop down menus. This can be done with pure CSS6, no Javascript required. Review your site’s dynamic features to see if there is a less complicated way to do the same thing.

#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

Server Side

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

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

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.

This is a very bad approach because it tells the rewrite engine to search the entire file system twice. It first searches the hard drive to see if the request is a file, then again to see if it’s a directory, before sending it on to index.php. A better solution starts with the fact that all other files – CSS, images, Javascript – will all have a dot in their file name. Anything without a dot should be sent to index.php, correct?

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?

1 Using site speed in web search ranking, April 9, 2010, Webmaster Central Blog

2 Web metrics: Size and number of resources, May 26, 2010, Google Developers

3 Including this one . . . including this one.

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.

6 Most of the time.

Posted in Team eBoost | 2 Comments

2 Responses to Is Your Site More Bloated Than After a Holiday Dinner?

  1. Wilbur says:

    Hello! I just wanted to ask if you ever have any trouble
    with hackers? My last blog (wordpress) was hacked and I ended up losing months of hard work due to no
    back up. Do you have any methods to stop hackers?

  2. Bill Snowman says:

    Thank you – and of course we do! Fortunately we’ve only had one incident on a **server** level due to a client’s insecure scripts.

    First is a regular backup policy. As often as possible schedule database and file backups.

    I’d say the server environment is probably the next thing to look at. In a shared server environment, an insecure script hosted by another domain can affect the entire server, including the WordPress hack (and other CMS hack) that injects malicious Javascript into all index.php/html files.

    Probably most often ignored, use a secure password for all resources and change it as often as possible. This is a big deal.

    Every software vendor (including WordPress) has security recommendations. Follow them.

    In the case of WordPress, most hacks come from themes or plugins that have security holes. Do your best to cut out the fat and keep those updated as well.

    Last of course is diligence, enable and review server logging, review it from time to time, and make really good friends with your hosting company’s tech support department. Many of them are very good at helping out.

Leave a Reply

Your email address will not be published. Required fields are marked *