alvinashcraft
shared this story
from 
Webdesigner Depot.
Speed is usability.
To say it more accurately, website speed is a major part of usability. The most intuitive interface ever created by the mind of man will do you no good if the user is pee’d off by the time it loads.
That’s it. The article’s done… Ok, so there’s actually a lot more to it, but that first sentence is about half of what you need to know. We’ve got to make our websites fast.
I could use a lot of superlative expressions like “blazing fast”, or “extremely fast”, or even “faster than a speeding bullet”, but they would be inadequate. It’s simpler to say that there’s no such thing as “too fast”.
So what do we mean by “fast”?
We do need to take a minute to talk about what kind of speed I’m referring to. In short, all the speed. More specifically, three kinds of speed:
1) Loading time
This would be the time it takes for all of the information to download to your users’ devices. This is affected primarily by the speed of the internet connection, and the actual size of the files.
You can’t do much about the connection, but you can do a lot about file size.
2) Processing time
After your files are downloaded, they have to be processed and rendered by the browser. All of that processing and rendering is affected by how well your code was written, and everything else going on on the user’s phone, tablet, or laptop/desktop.
The only thing you can control is your own code, but that makes a big difference.
3) Perceived website speed, or perceived performance
And then there’s the psychological factor. Fast websites can look and feel like they’re going slow. Slow websites can be made to feel a tiny bit faster with the judicial application of some tricks.
This part is all about studying your user, and letting them know what’s going on when they interact with your website or app.
You need to pay attention to all three aspects of website speed to make your site feel like it’s going fast. And the bigger the site is, the more there is to optimize.
Let’s get started, then.
Speed up your CSS
Many times, especially on those smaller, experimental projects that I love so much, I find myself spending more time on the CSS than any other part of the code. Oftentimes there is also more CSS written than HTML or JavaScript. So that, right there, is an indicator of just how much your CSS can affect file size.
Then, of course, there is the matter of how fast your website will actually run on your user’s desktop, laptop, tablet, or phone. Much of the actual “work” or rendering a web page is done by the software, with a little help from your GPU.
It might load quickly, but scroll slowly. The way your CSS is written has a direct effect on how fast a particular device is able to actually display the web page once the files have been downloaded.
When optimizing a website to run faster, the CSS is usually a good place to start.
Unused code
CSS that sits in your stylesheet and doesn’t do anything makes your files unnecessarily bigger. Okay, so this one might seem like a no-brainer; but it still happens to the best of us.
You take out some content and forget to delete the old CSS. You change a container element’s class or ID, and forget to delete the old CSS. You write some CSS, realize there’s a better way, and forget… you get it.
Throw multiple front-end developers into the mix, and you’ve got a recipe for an unwieldy, unmanageable stylesheet, or collection of them, if you’re not careful. Unused code slows down page loading by virtue of its very existence as data. It slows down development because it can confuse people reading the stylesheet.
It can also mean slower rendering times, because it’s just more CSS for the browser to look through while it matches all of the CSS to its appropriate HTML elements.
Whether you review and delete all old CSS manually, use automated tools to help you find unused CSS selectors, or just delete things at random until something breaks (don’t do that), you’ve got to take that old code out.
CSS selectors
Speaking of how the browser matches the CSS with the appropriate HTML, it’s time to look at CSS selectors. Much has been written about which selectors render the fastest, which ones are slow, whether you should bother with the slow ones at all, and so on.
The problem is that much of this information is old. Back in the year 2000, Dave Hyatt (a developer working on Safari, and active member of the W3C’s CSS Working Group) wrote this:
The sad truth about CSS3 selectors is that they really shouldn’t be used at all if you care about page performance.
If you’ll take a look at the document that quote came from, you’ll see that he was talking about selectors like :first-child and other pseudo-selectors. And he was right.
He still is; but in the last fifteen years, computers have advanced a little bit. Nowadays, the extra effort required of the computer to render that CSS shouldn’t be noticeable by anyone except those using the cheapest of cheap mobile devices.
That is a concern in itself, so really, it will depend on the project at hand, your target demographics, and so on. Simply put, use your best judgment, and perhaps don’t go overboard on the pseudo-selectors.
Otherwise, unless your pages reach book-length, the selectors you use should have very little effect on your site’s performance. Still, take a look at the document linked above and get familiar with what renders the fastest and what doesn’t. You may still find the information useful.
You can also see this article from CSS-Tricks for a slightly more recent take on the subject.
Resource-heavy properties
Of course, there are also CSS properties that take longer to render than others. The classic properties like width, height, and color are still the fastest. The ones that tend to take a little longer (and may vary from browser to browser) tend to be CSS3 properties like box-shadow.
The process of adding a drop shadow to an element is complex, as far as rendering web pages is concerned. What’s interesting to note is that, as pointed out on HTML5 Rocks, the processing power required can vary greatly depending on the specific dimensions of the drop shadow.
This article indicates that the same holds true for other properties such as border-radius and transform.
Again, these would have little effect on the rendering of a page on your average desktop or laptop. Mobile devices might take a bigger hit, though, and the experience could suffer as a result. Everyone hates choppy scrolling.
Still, that has to be weighed against the cost of using images to produce the same effects. Anyone remember the things we did to get rounded corners, once upon a time?
Just don’t go overboard, and your styles should render fast enough.
CSS animations
Now we get into other territory. CSS animations can be blazingly fast, or they can slow down the browser to the point that gaming rigs have trouble keeping up.
This is partially because not all animation is rendered equally. Some of the heavy lifting is done by the hardware, whereas other kinds of animation have to be rendered entirely by the browser’s own functions. This is especially costly on mobile devices.
In another article on HTML5 Rocks, the CSS properties that are the fastest to animate are position, scale, rotation, and opacity.
Check out the article for a more complete overview of what can be animated while keeping the “cost” low.
Use CSS preprocessors
Here’s where I offer you the most practical advice that I, the author, can give you. Use CSS preprocessors like LESS, SASS, and Stylus. Sure, if you use them wrong, you can generate larger stylesheets than you intended; but the potential benefits are worth it.
For example, if you want to reduce the number of HTTP requests made to the server (always a good idea), include all resets, frameworks, into one LESS/SASS file. When it compiles, it will all be in a single stylesheet. Plus, most preprocessors offer the option to output all CSS in minified form.
This way, you can use as many different files as you need for code organization purposes, without unduly affecting file size.
Speeding up your JavaScript
JavaScript can be really slow. To be more specific, JavaScript can have a much more direct effect on the “processing” part of the speed equation than the CSS. Worse, JS can get exponentially heavier in terms of file size in order to achieve seemingly trivial things.
It’s a double whammy of painful slowness, and our users are often the victims, especially those on mobile browsers. This is not, however, the fault of the language. How screwed up our JS gets is often in direct proportion to our ignorance of programming in general.
I’m a non-developer. I’ve often used libraries like jQuery, or individual stand-alone JS plugins to get stuff done. The more I need to do, the more plugins I need to make it all work. These plugins and frameworks come with extra options and features that I may never use.
There’s the bandwidth-stealing bloat, right there.
In addition, plugins might not work well together. They might slow each other down, or one might stop another from working altogether.
There’s the wasted processing power, right there.
If you really want to speed up your website, shave off milliseconds (or whole seconds, in some cases) here’s what you need to do:
JavaScript should almost always be external
Like CSS, it’s best to keep JS in external files, and linked into your HTML. You might not think it’s such a big deal if you don’t have much JS code, and it does add an HTTP request, but here’s the thing: external CSS and JS files get cached by the browser.
So when that same page is requested again, or other pages on your site that use the same CSS or JS get requested, those cached external files get used instead of being downloaded again. That’s faster site loading times and slightly faster processing. It’s worth the extra call to the server every now and again.
Include your JS files at the bottom of the page
Basically, the theory goes like this: the browser renders whatever is at the top of a page’s source code first. That’s why things like the tag go near the top.
JavaScript files, however, can slow everything down by stopping the browser from rendering your HTML until they’re loaded. Since most of the commonly-used JS effects and plugins only need to work after the rest of the page is on the screen, this is less than ideal.
Improve the user’s experience and reduce the perceived loading time by linking to those external files at the bottom of the page, right before the tag.
By the time a user gets around to interacting with anything that requires JS, it should be ready to go.
Avoid frameworks and other dependencies if you can
If you’re designing a full-fledged app, then you can and maybe should ignore this section. A good, flexible, and light framework can give developers a huge edge. For small-to-medium-sized websites, however, including a JavaScript framework may be overkill. On these websites, JS will be mostly used in the back-end of the CMS for administrating content. On the front-end, you might have an image slider, or masonry layout or two. If you’re really fancy, you might have auto-complete on the search bar.
Most content doesn’t need to be fancied up and animated like this. JavaScript should, as much as possible, be reserved for improving the user experience. Relying on it to simply pretty up a site can result in a slow, slow site, especially on mobile devices.
In a way, all code frameworks are all the same, whether it’s JavaScript, PHP, Python, HTML, or CSS: every feature is a bunch of code. When choosing a framework or plugin for a job, ask yourself if you’re going to use every feature it offers, or even most of them.
If not, is the framework modular? Can you pick and choose only the parts you actually need? If so, and you believe the file size trade-off to be worth it, then by all means go for it! Otherwise, it’s best practice to see what you can take out more than what you can cram in.
Turn JavaScript off
Not permanently! Think of it this way, is there any content or functionality on your site hidden away by JS? Can people access it without have JS enabled in their browsers?
If so, then great. However, if people can’t see important information, contact you, or navigate properly without JavaScript, then you’ve got a problem. Sure, you can rely on most people still having it enabled, but you’ve always got those edge cases.
How does this relate to website speed? Imagine how slow browsing is gonna get if a part of your website suddenly just doesn’t work.
Hire a developer
No seriously, if you’re not a developer, and you have the budget for one, go get one, even for small, simple jobs. It’s cheaper in the long run to hire someone experienced to do it right, once.
In the event that things go horribly wrong (and we’re talking about computers here, so something will go wrong), they’ll find out what went wrong faster. They’ll have experience in finding those sorts of problems and resolving them. If nothing else, they’ll be better at googling those particular topics.
Most importantly, they’ll know how to do what needs to be done with less code. Less code (usually) runs faster and (always) downloads faster. That’s the simplest advice I can possibly give.
(If you are a developer, or are learning, I’ve compiled a list of tutorials which will be at the bottom of this article. Included are some beginner’s guides to writing JavaScript that runs fast.)
Images & compression
When you take video out of the equation, the biggest thing on any given content-driven site is the images. Images tend to be big, bulky, and slow as hell when they’re not optimized.
Now, with the proliferation of retina screens forcing us to use bigger images if we want things to look good on every device, the problem isn’t going to get any easier to solve. And worse, it’s an issue that’s easy to forget about until you end up spending more than intended on bandwidth.
When every byte counts, we can’t afford to forget.
The good news is that this isn’t a new problem by any means. Why is that good? It means that there are tons of potential solutions to pick from, and you can use more than one of them at a time. In fact, that’s generally a good idea.
So until ISPs and hosting companies start giving us all unlimited free bandwidth (don’t hold your breath), here are some things you can do:
Do more with code than images
Simply put, do as much as you can, visually speaking, with CSS and JavaScript before you turn to images. Code will always be cheaper to transfer than images, so stick with that as much as you can. Despite the processing power consumed by CSS-based drop-shadows, gradients, and the like, consider the trade-offs.
Also keep in mind that SVG images count, in this instance, as “code”, because that’s all they are: XML code that’s rendered as an image. Thus they should be used whenever you need anything vector-related.
Use responsive images
Now, returning to those aforementioned retina screens, what do we do about them? How do we save on bandwidth there?
This is where we turn to the element and the image-set property. They’re relatively new, and not fully supported, but they do allow browsers to pick the appropriate image size for the device that’s being used.
So while this won’t save you any bandwidth for someone viewing your site in their iMac, it’s not as big of a deal because they’ve most likely got broadband. Someone on their phone, meanwhile, gets a smaller version of the same image, keeping them from waiting too long.
Pick the right format for the job
Many image size woes get fixed once you learn which image format to use in any given situation. I could go on about the specific image formats, how the compression works, and so on, but you really only need to remember a couple of things:
For complex graphics, such as photos, use the JPEG format.
For simpler graphics that use few colors, like icons and logos, use SVG and/or PNG.
GIF is for animation only, and only when you wouldn’t be better served by animating something with CSS3 or JavaScript. Animated GIFs work better as content than as interface elements.
That’s really all of it. If you do this, and play with the optimization settings when you save the images, you can often get pretty decent quality at relatively small file sizes.
Looking forward
However, there is a new format out called WebP, which is supported by Chrome and Opera automatically. Google claims that WebP files are 26% smaller than PNGs, and 25-34% smaller depending on a couple of factors.
This is great news, except for two things: Firefox and IE. Now, if you don’t mind using fallbacks and an extra script, you can use the WebP format now, today. Just download WebPJS, and you’re good to go.
WebPJS uses JavaScript and a little bit of Flash (sigh… but that’s only for IE) to make it work, but it does work. You might consider it if you need to serve up lots and lots of larger images fast, with the downside being that it won’t work without the JS.
Compression
There are two kinds of compression that you can use on your images. First, we have lossy compression. This is used on lossy formats like JPEG. It allows you to compress any image about as much as you like with the understanding that the quality will get worse and worse and worse. Things will get pixelated and lose definition.
Lossless compression is used on formats like PNG, and can reduce their file size to some extent. However, it has its limits. There always comes a point at which it is impossible to make an image smaller without losing quality.
If you have Photoshop or a similarly advanced image editor, it’s often best to use those to compress your images so that you can see what the output will look like when you’re done.
(Automatic tools, especially online tools, in my experience, tend to compress things maybe a little too far. Nevertheless, I’ll be listing the best compression tools that I’ve found in the links section below.)
Implement image compression and resizing in your CMS
If you’re using a CMS like WordPress, it will automatically resize images that are too large. It’s also easy to find plugins that will automatically compress them for you.
Mind you, I only recommend automatic compression in cases where you know you’re going to be uploading lots, and lots of images of similar quality for the same purpose. A photo blog is one example.
If you’re running a site where users are uploading their own images, well… automatic resizing and compression is an absolute must, and that’s why every social network does it.
General tips
Here are a couple bits of advice that didn’t fit in any of the three categories above.
Minify everything
“Minifying” your code just means that all extra spaces and line breaks get taken out. This can reduce file size rather significantly.
It might sound like a lot of work, but there are tools out there for minifying CSS and JS automatically, and keeping the minified files separate for your source files, for fairly obvious reasons.
As previously mentioned, various CSS preprocessors can output all of your code in minified form in the first place.
Compress everything
Provided your server is set up right, all of your code can be sent to the browser in a compressed format. Text files compress very well, reducing the size of the files sent considerably.
Now, your server does have to take an instant or two to compress the files it sends, and the user’s browser has to decompress them, but this is usually worth the bandwidth trade-off.
For a full explanation of how this works, see How To Optimize Your Site With GZIP Compression.
Cache your site
Browser caching happens automatically to some extent thanks to modern browsers. A browser goes to a site, and temporarily stores the images and other information it finds there.
That way, if the same user returns within a given period of time, the browser doesn’t have to ask for the same images all over again. It just loads the ones it already has, and requests any new images that it might not have.
There is, however, something you can do to tell browsers what to cache and for how long, as seen in this guide.
Server caching
And then there’s server caching. Server caching basically just takes your site and puts a sort of ”copy” of it between your users and your actual server. Why would you bother?
Well, it’s especially useful for people who are using content management systems on a large scale. Having your users access a temporary copy of your site instead of the actual thing reduces the number of calls to your database. Information gets displayed and loaded faster because it doesn’t have to be re-processed every time.
Depending on how it’s set up, server caching can also reduce bandwidth costs in general. Basically, the bigger your site is, the more reason you have to look into caching it.
Links
And now, the section you’ve all been waiting for: the list of links! We’ve got tutorials and guides, mostly, and a couple of image compression tools to recommend.
General information
From the Yahoo Developer Network
Yahoo! may not be as big a deal as it once was, but their developer network has a lot of good stuff on it. This includes their Best Practices for Speeding Up Your Website, which covers some of the basic things you can do. Some of it covers the same ground as this article, but there’s more besides.
In the introduction, I mentioned perceived site speed, also known as perceived perfomance. If you’d like to read more about that, check out A Beginner’s Guide to Perceived Performance: 4 Ways to Make Your Mobile Site Feel Like a Native App.
CSS
Effeckt.css
Effeckt.css is a set of CSS-based animations that are designed to render fast, no matter what platform the user is on.
Optimize CSS delivery
This is a guide to making sure that your CSS gets downloaded and processed as fast as possible by the browser.
JavaScript
24 JavaScript Best Practices for beginners
When you’re just starting out, learning to code correctly can be just as big a speed boost as any random tips of tricks you might learn. Bad code costs more in terms of processing time, so learn to do things the right way.
Writing Fast, Memory-Efficient JavaScript
Here’s a basic guide that focuses more specifically on writing JavaScript that runs fast.
Performance Tips for JavaScript in V8
Just like the title says, this is all advice targeted specifically at JavaScript V8.
5 Tips for More Efficient jQuery Selectors
And sometimes, you probably will end up using jQuery. If you’re going to do that, at least you should know how to write jQuery selectors that won’t slow you down. And here’s where Sitepoint has you covered.
Images
A Beginner’s Guide to Image File Formats
Read this for more information about image formats on the web. The information is a bit old, but still valid, and good to know.
Image optimization
This is a more technical guide to image optimization provided by the Google Developer Network.
Compressor.io
Compressor.io is one of the more impressive tools that I have personally encountered. It’s an online app, so you’ll have to upload any files that you want to compress, but it can do wonders for JPGs. It offers both lossy and lossless compression options, each with pretty amazing results, and it can do batch processing as well.
Trimage
Trimage specializes in lossless compression, but it can be installed on your own computer, on Windows, Mac, or Linux. Since it installs to your computer (and yes, comes with various command line options as well as a GUI), it can easily be run automatically as part of a development workflow.
Conclusion
As always, there’s a lot more to learn. But armed with the information we’ve provided, and the resources we’ve linked to, you’ll be on your way to building sites and apps that don’t annoy the Hell out of your users.
And that’s the first step towards impressing them.
Master Photoshop with 55+ Modules of Online HD Videos from GoSkills – only $39!
Source
