The Coffee Desk

Two Birds, One Stone: Optimizing Your site In Both Speed And SEO

We’ve talked about what needs to be done in terms of better search engine ranking, but hand-in-hand with search engine optimization comes speed optimization for your website.

Having a speedy website means visitors have a more pleasing experience in terms of faster page loading/rendering times, and it also means search engines have less to dig through in the process of indexing your content. The tips we offer here will allow you to speed up the upload speed, rendering time, and lessen the server-side processing time of your website in a highly effective way of optimizing any website for both search engine and user appeasement.

Kill the Whitespace

Whitespace within the actual HTML markup of a website is only useful to human eyes. Search engines, web browsers, and any other automatic parser completely disregards any whitespace outside of formatting tags, where &nbsp should be used for long strings of spaces anyways.

I realize that during the development of a website, you may wish to visibly inspect the HTML structure of a dynamically-generated web page, but this is the only time you would ever need to waste the bandwidth to send whitespace to the client. Tabs, line endings, HTML comments, and generic blank spaces all fall into this category.

Web browsers, search engines, and any other HTML/XML processing engines all utilize a lexical analyzer for parsing a web page once it has been downloaded. Any whitespace encountered by the lex function (e.g. yylex() ) by the rendering engine is completely discarded, save for being stored into memory for the DOM structure or for offline viewing.

So why waste the bandwidth involved in sending characters to the browser that it will just discard anyways? All those bits add up when you have many users hitting your site at once, and in addition to the download overhead the web browser must then take that one more nanosecond to process a web page per whitespace character, and keep in mind that search engine crawlers have a timeout preset in case a site takes too long to load/parse.

If you must store comments or whitespace within an HTML source file, consider using generated static HTML. Simply have a server-side page that generates the static, browser-friendly HTML document at your request, allowing you to use the server-side copy to clutter with whitespace and comments. This also takes out the server-side processing overhead from the page, since it is generated dynamically only one time. This may not work for all applications, but consider working it into your plan.

In addition to trimming the actual HTML whitespace, do the same to any JavaScript and CSS documents your website uses. They incur an extra request into the web page’s download time, so be sure to strip out the parsing and download time for the client by applying a CSS/JavaScript compressor to your human-readable “developer copy” to save time for the client.

Server-side Time Savers

Making your pages as static as you can get them cuts down on any server-side processing latency you can. Disks have to spin up, database servers have to be queried, and executable code has to be loaded from the disk on the server just to generate the typical dynamic page. Most of these pages have content that is either not changing unless the developer modifies the database, or else can safely be cached without any loss of information.

We touched up on this already, but to cut down on this overhead, consider generating a static web page for the client’s viewing pleasure from a private developer/admin page. By this, I am saying that you should have one page that generates the static .html page that the client views based on database queries and other dynamic information that can be carved out of the overhead.

This may not work for all sites, however, as some sites genuinely need the page to be regenerated every request for sensitive informational updates. Most sites, however, can safely do this. The server side application, which should be restricted to the developer, should automatically strip out any whitespace/comments/line-endings before writing the static page out.

(Also consider using a cron job/scheduled task to automatically update the static pages at a defined interval)

That way, when the client follows a link to a (static) page, it is already updated with the current information (as of the last page generation) but without the server-side overhead, and optimally without any whitespace contained within.

Many of us, however, like to have a ‘header.php’ file applied across all pages to simplify the task of changing, say, the nav bar of all pages on a site. Don’t let this be a monkey wrench into your plans – you can either generate the header file dynamically in the same manner as the other pages and simply have them include it as the only server-side statement in the page, or you can further craft your developer page to update all of the page headers automatically on a whim.

Either way, static content trumps per-request dynamic content in speed, so by generating a static page ahead of time from a (CMS) control panel of sorts, you can drastically cut down on your server-side latency.

Server-side Trickery

If you either host a site yourself or have a VPS hosting plan, there are some server-side tricks you can employ to further save time in your pages’ load.

Disks are a tremendous bottleneck on any server. RAID, and the debate about SSDs in the datacenter both aim to cut down on disk bottlenecks, but both can be trumped in speed with a little developer-friendly trickery (i.e. no required computer engineering degree).

Modern Linux systems come with a builtin ramdisk, contained via the /dev/shm directory (or /var/run as well). Anything placed into these directories are stored directly within RAM, instead of on the physical hard disk, while remaining within the filesystem for easy access from a dynamic application. The directory is world-writable by default.

Placing files from your web application into this directory will make loading them from the filesystem a breeze, since they aren’t subjected to disk I/O latency of any kind. Use it whenever you can to store files in on the server, while being aware of its limits and keeping application security in mind.

The Result

If you follow all of the advice on this page, while also adhering to The Ten Commandments of SEO for the actual content, your site will not only load much faster for clients (including search crawlers), but will also be faster to parse and render in either a web browser or a crawler seeking to index your content.

A few additional things worth mentioning are to always use external stylesheets (try to cram it all into one sheet, rather than have multiple sheets if you can), and the same with JavaScript. This allows clients to cache both the file and the compiled code, and will speed up the load of future pages. Most sites should already be doing this, but you would be surprised.

And as always, carefully plan your site’s design out while factoring in these considerations before you employ something nearly impossible to maintain or scale.