, ,

Lose Some Weight…Reducing The Size of Your Ecommerce Website Pages

There are several factors that impact the time it takes a web page to load. Some of those you can control, some of those you can’t. Regardless, you need to always be aware of how much data is getting sent to your visitors. We kept this in mind when rebuilding the demo store front that ships with our Multifront product and the result was an average page size well under 1Mb.

Some reports have the average web page size upwards of 1.5Mb, regardless of device (which is scary). This number includes images, Javascript files, stylesheets…everything. As things like responsive design have come of age, certain resource sizes increase. You can’t avoid it but you can manage it.

A picture is worth…a lot

My own unscientific research shows that about one-third of any given ecommerce web page size is images. Fortunately, this is probably the easiest aspect to deal with. One simple quasi-solution is lazy loading your images, that is, calling them after the page has loaded using Javascript. True, this still sends the same amount of data to the visitor’s device, but by deferring the load the page will at least load faster.

However, the real solution here is different sized images based on device (screen size). There are many techniques out there for loading responsive images, some may soon be official. Regardless which method you choose, having different sizes of your images is the best way…and if you combine that with lazy loading you’ll be way ahead. In short, just be aware of which device your visitor is (probably) using. If they’re on a phone, send them a smaller image, maybe only 400-pixels wide. If they’re on a desktop, send them the 800-pixel image. Just make an educated guess and that’ll be a start.

The jQuery dilemma

As we now have to worry about different devices and interactions, Javascript has become more critical. Thankfully libraries like jQuery look to make things easier…and they do…but that comes at a cost.

We chose jQuery as the base library for our store front because it’s the most popular, plain and simple. We’re selling a product so it makes sense to use something most people know. However, in an ideal situation, I’d love to avoid jQuery. There are many alternatives to jQuery available, many of which are half the size but still provide the core features you need most (like Ajax, DOM manipulation, event handling, etc).

jQuery weighs in right around 100k. That might not sound like a lot but some alternatives are less than 40k and if you can get the same benefits but pay less, why wouldn’t you? Of course, without jQuery you’re limiting yourself to the number of plug-ins you can use…but that’s okay. In fact, that’s one reason why we were able to get our average page load under 1Mb. We avoided using third-party plugins when possible. Plugins aren’t evil and can save you a lot of time and effort but plugins are also trying to cast the widest net possible so it can serve as many users as possible. Plugins shouldn’t be used as an excuse to avoid producing code that you could otherwise write better (and leaner). Could we have used more plugins? Sure but by writing our own modules that serve just our site’s needs, the smaller files are…and frankly, the less there is to maintain.

Stylesheets, large and in-charge

Reducing the impact of images and Javascript will go far for your web site, and that’s good because the footprint of stylesheets has gone up considerably.

Thanks to responsive design, stylesheet files have seemingly doubled in size. The need to account for (at least) three different screen sizes per page can lead you down a road of CSS bloat. I feel it is a necessary evil but thankfully CSS compresses wonderfully. The use of precompilers like SASS make it easier to create and maintain stylesheets but they can also lead to extra code.

Since you can use imports, functions and other shortcuts with SASS, you can find yourself doubling up on code or creating extra rules that you don’t need. If you’re going this route just make sure you review the actual generate stylesheet (or at least inspect it) and cut out any duplicate rules.

All in all, keep it small

Keeping things light and fast is crucial for any web page. Thinking in terms of mobile devices will help keep things light but it also helps to just give yourself a filesize budget. Pick a maximum filesize for any given page (be reasonable) and then use that as your warning flag to start removing and refactoring. Start generous, maybe 700k, and then work down from there. As you build and test you’ll find out if you can go lower, or if you really need to increase things.

Of course, if nothing else, at least minify your code and bundle things together to reduce the number of remote calls. Even if you can’t avoid jQuery or plugins, at least you can reduce the number of times a page has to go out to the internet and retrieve a file.

Just don’t forget that faster pages means happier customers.