Web Design & Marketing Blog

Speed Matters Part 2 - More Basic Tips To Keep The Impatient Citizens Of Cyberspace On Your Page

Category: Blog

Written by Matthew Millet

Does it take more than a few seconds to load the main content of a page on your site?  If so you're almost certainly doing something wrong.  Sure there are a few exceptions that can't really deliver the content they absolutely need on a page any quicker, but chances are you're losing visitors, resources, and conversions if a visitor doesn't see what they want in the flash of an eye.  I've said it before, but it can't be said enough: speed makes or breaks a good website, and a good website shows.

It may seem hard to believe, but in my years of experience over half of any necessary speed optimizations can be accomplished simply by using indexes and minimizing queries in your web sites SQL.  Following are some other vital basics to getting your information to the world fast, and speed matters.

Minimizing Queries

The easiest way to reduce the queries to your database is to make sure you aren't getting anything you don't need.  Even if you believe you'll never slip up and write any code that will get redundant data from a database, chances are you'll find yourself working on some code where someone else has.  Beyond that, if you can get what you need in fewer queries so much the better.

If you need to get any additional information on at least two thirds of the records you're retrieving, you should use a join statement.  Joins are best on indexes and foreign keys if at all possible, and any time you need to make a join on fields that aren't indexed you should give some serious consideration to indexing those fields.  Also, remember to join on all fields in a complex index, or an index of multiple fields.

Another neat trick to minimize queries is to leave out some information that can be delivered asynchronously using AJAX.  If the majority of your use cases don't involve certain data, you could probably leave it out of the first page load and provide it as the user interacts with the site.  Anytime you're getting additional information using AJAX, such as when a user clicks on a row in a table to expand details about an invoice, you should consider whether or not you can prevent that load from needing to happen again, as is the case if the data isn't likely to change between clicks and if the data to be returned is going to be the same for the same activity like in our invoice example.  That way if they close the invoice and click on it again, they aren't taxing your database resources more.

Try to think of adding queries to the database as a last resort.  Whenever you have a data heavy page, pay special attention to each use case and make an effort to minimize the calls to the database for each one.  Also, don't forget to give yourself some time to exercise forethought on how some queries could get out of control if your database is particularly dynamic.

Images

After database queries, most of the load time on a web page is likely to be images.  One thing that baffles me to see in this day of the internet is a 1900 x 1080 jpeg that is displayed in a 100 x 100 element on a web page.  It may be a little bit of a learning curve, but if you expect to be taken seriously as a developer you need to learn how to resize images using server side code.  If ever possible, these images should be saved for further use, but if there's little chance of this image being viewed again or there is a risk of over burdening disk space resources images need to be resized on the fly and sent to the user.  The methods used to do this are varied and can be quite specific to a site.  If you don't know how to do this, I could fill up an article with links to guides for you, but instead I'll just advise you to Google your server side code language followed by 'resize images' and leave you to your own devices.

Another good rule of thumb is to avoid loading small images for buttons and such.  I have sometimes favored keeping a single 10 x 10 button background in its own individual file for various reasons; mostly concerning file organization.  But even if a button background isn't strongly related to any other small icons or backgrounds for your site you could get a surprising speed boost by adding it to a sprite.  A sprite is just a name for a bunch of images put together into a single image file that is only intended to show part of itself at any time.  One file of a certain size will load faster then several smaller images adding up to the same file size.  Also, it's probably going to take up less disk space, and that's less bandwidth to your visitors.  If you make the sprite well, it should be trivial to use CSS to display only the part of the file you need.

On a similar note, any patterns should contain the absolute minimum image size required to repeat the pattern.  Additionally, patterns should be encouraged in any place where they could be used in the place of a fixed size diagonal gradient background color or something else equally inflexible.  Not only will it speed up your website to use small pattern images repeated using CSS, but it will make it easier to change the size of any element using that pattern.

Another technique that can provide great results is to wait to load certain elements of your page until the main content has loaded.  If you have some annoying banner ads you have to put up with for whatever reason, make them load after the content of your page has loaded.  If any elements outside of the main content are taking up valuable resources and you can't make them load in a satisfactory time, try to use JavaScript to open them in an onload statement in the parent element of the content you want your visitors to get now.

Further Optimizations

I could probably make a life's work refactoring some of the web applications I've developed over the years.  Once your users and bosses are happy, you need to walk away.  One of the most disheartening necessary evils of development is needing to turn away from a project before you've perfected it.  It may seem like the end of the world when you look at an interns code commits and you want to refactor everything they did while your department's budget no longer allows you to work on that website, but at the end of the day you need to detach yourself from it. Chances are no one will ever notice or care that a learning dev makes you embarrassed about a website your in charge of.  If you're lucky, you work for a solution that gets reused by many clients and you have the opportunity to devote yourself to constant improvements and speed optimizations like we here at VivaNet 2.0 do with our Lexy Sites.  If you don't have the resources to devote to the server administration and web development required to keep your websites robust and fast I would strongly recommend a service like Lexy for you.

Most developers could respectably get by never delving into topics of optimization that that these last two articles have scratched the surface of, but like all subjects in technology, the sky is the limit.  If you need to get more advanced than this it may be more cost effective to just scale.  However, remember this rule of thumb, I call it a rule of thumb but it's almost a sin to do otherwise, optimize before you scale.  Scaling costs money, and I envy your fairy tale land of employment if that doesn't make your bosses face go red, and understandably so.  The only bosses I've had that didn't cringe at an invoice are out of the game.  Still, there does come a time when scaling is a better investment of resources than further optimizations, and there isn't an easy rule of thumb to tell when that is.  But remember that as daunting as optimization is you should give it a valiant go before tacking more line items onto your company's expenses.