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.
A picture is worth…a lot
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
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
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.
Trevor Santariushttp://blog.znode.com/Blog/wp-content/uploads/2018/05/znode-mrr.pngTrevor Santarius2014-03-25 13:47:212017-11-15 10:03:42Lose Some Weight...Reducing The Size of Your Ecommerce Website Pages