An understanding of website fundamentals and load times.

If you're brand new to web development, you're not familiar with the consequences of large file sizes. By "large", I mean anything higher than a standard size, which varies based on image size, JavaScript features, styling, and so on.

Consequences 

The first thing you should be aware of is the main consequence: load time. 

If you're using large images, a large JavaScript library, too many libraries or resources, or too much wasted CSS, you're making the user load more resources than what's necessary. All of this adds up to a slow loading website, which causes the user a lot of frustration. 

Slow loading pages rank poorly on Google

Have you eve been on a website and while you're reading an article the page moves down? Or the images aren't fully loaded yet? Or menu links don't work? And you undoubtedly noticed the spinning icon in your tab (or on the page) and it never seems to go away? 

All of this leads to a terrible user experience. Users hate waiting. But it goes beyond that... if you serve a webpage that's like 10mb (all files included), you have to remember that's 10mb of data from somebody's mobile device (phone, tablet, etc). Without intensionally being harsh about this subject — this is completely irresponsible development from the developer. 

Let's take a look at what causes slow pages.

Large Images

Images are by far the worst culprit of slow loading websites. It's easy to create an image in PhotoShop, save it as a .png, and upload it to your website without thinking about the file size. But PhotoShop bloats your images! There's often ~5x larger than they need to be. So you should shrink these images using a tool like https://tinypng.com/ — more on TinyPNG later in this article. 

If your page has a small image gallery with thumbnails... let's say there are 10 images sized at 1024x1024, and each one is 1mb in size. This adds up to 10mb in total, and most people in the world with a mobile connection don't get fantastic speeds. Not to mention, most mobile devices don't has a width resolution over 1024 pixels, so now you're serving them unnecessarily large images that their phones can't even take advantage of. 

Do everybody a favour and keep your images as small as they can be without losing quality. If you've noticed the max image size on any device is 800px, try resizing the image to be only 800px wide (maximum). That will cut down the size by roughly 20%. Then compress the image and you could see compression gains up to 80% more. Your users will thank you. Google will thank you. I thank you. 


Large JavaScript Files 

Many developers are using SASS and Webpack to write fancier code that compiles into a single .css or .js file. This is actually a fantastic feature for developers, but there's a cost...

Webpack is notorious for creating oversized JavaScript files

Webpack is very intelligent! But if you don't have a setting enabled to compress and minify the JavaScript, you could see your JavaScript files bloat over the size of 2mb. 

Not only does this 2mb (this size is often much larger!) JavaScript file take time to load... but your JavaScript features aren't typically enabled until ALL the HTML and JavaScript is loaded on your page. This creates an annoying problem when people try to click on a link and it doesn't work... or a user will try to scroll immediately but the page is stuck loading. 

This 2mb (or more) file is acceptable when developing a website on your localhost website, but in production it should never be this large. 

In production, your JavaScript file should be as small as possible. Don't load extra libraries if you don't need them. Don't forget to minify and obfuscate your JavaScript files! Oh, and remove your source maps in production!

Large Stylesheets

Many people, including myself, love using SASS and LESS. It allows us to write cleaner, re-usable CSS and it compiles into a single .css file for us. But the compiling is where the damage can be done. 

Let's take this example:

// This is SASS
#body {
    h1.main-title { font-size: 50px; }
    h2 {
        &.banner-title { font-size: 35px; }
        &.article-title { font-size: 28px; } }
}

When compiled, this looks like:

/* Example 1: This is CSS; Compiled from SASS */
#body h1.main-title { font-size: 50px; }
#body h2.banner-title { font-size: 35px; }
#body h2.article-title { font-size: 28px; }
Doesn't look like much, does it? But is the #body h1 and #body h2 necessary? If you markup your page properly, you won't need to specify the elements and container (#body). Here's what it could look like:
/* Example 2: Removed the #body and h1/h2 nesting */
.main-title { font-size: 50px; }
.banner-title { font-size: 35px; }
.article-title { font-size: 28px; }

One looks cleaner than the other, and one is faster to load (and easier on your browser to understand and parse).

Let's look at the math. This will be painless, I promise. 

The first example, Example 1, has CSS that's roughly 127 characters long (127 bytes). And Example 2 has a more flat CSS (no nesting), and it's roughly 102 characters (102 bytes).

102 bytes / 127 bytes = 0.803 (or roughly 80% of the larger file; meaning it's 20% smaller). 

So our flat CSS is 20% smaller and faster to load. Here's what the SASS would look like:

// New SASS. Looks a lot like regular CSS, doesn't it?
.main-title { font-size: 50px; }
.banner-title { font-size: 35px; }
.article-title { font-size: 28px; }

By keeping your styles simple, you are essentially reducing overly complicated code back into it's purest and simplest form. Not only is it easier to read, you don't have to worry about nesting, conflicts, typos, etc. 

Too Many Round Trips

This section gets into HTTP requests. It's a big part of web development that isn't often spoken about in common blogs. But it's increasingly important these days.

HTTP requests are very simple. When your browser hits a webpage and it loads 3 JavaScript files, 15 images, 4 style sheets... each one of those is an HTTP request. More often than not, browsers have to wait for a response from the server before moving on to the next HTTP request. That's why some images load first, and others look like they load slower.

Next time you're on a slow loading website, like CNN or some other notoriously slow loading website, take a look at the source code and count how many images, how many .js and .css files, and how many videos are trying to load at the same time.

This bottlenecks your load times. 

The opposite, less HTTP requests, are typically basic websites with minimal styling and functionality, but they load ultra fast. There is a middle ground in here. Keep your website looking and acting nice, but don't throw in additional JavaScript libraries for some extra sizzle if it's not really needed. It's slows the site load time and it adds too much distraction (bad for User Experience, UX).

Every file you load, often called static assets, requires an HTTP request. It's how the internet and browsers work together. While these are relatively inexpensive costs, too many certainly has an effect on your load times. 

Above the fold

If you can, make everything above the fold load as fast as possible. Everything else can load a bit slower because it's not in sight — the user needs to scroll to see it. 

"Above the fold" refers to the section of a website that your screen can see the second it loads. If you have to scroll, everything below the scroll line is "below the fold"

This is hard, because tools like Google PageSpeed want you to write inline CSS to load faster, but they also want you to be mobile friendly and write the least amount of code possible — these are conflicting notions. It's either: more inline CSS orput the CSS in a stylesheet and write media queries to keep it mobile friendly. 

Lazy Loading

Lazy loading is the act of loading images or other resources on your site on a as-needed basis. 

If you have an image gallery below the fold, for example, you can lazy load the images when the user scrolls down to the gallery. 

If this is a new term to you this is how it works:

There's usually a class or ID on your page, and JavaScript watches for when the user scrolls to that certain class or ID. When the class or ID becomes visible (it's inside the viewport), it will look for a URL and load it at that moment. 

For example:

<div id="gallery">
    <img data-img="http://via.placeholder.com/350x150" src="" />
    <img data-img="http://via.placeholder.com/150x350" src="" />
</div>

The image URL's are kept in the data-img attributes, and the src attributes are left empty. Once the user scrolls to the #gallery, JavaScript will loop through the images and replace the empty src with the value inside the data-img

Now the image will load because the src was given a new value, and the 2 images never loaded in the first place. 

Note: this was a rough and incomplete example. I was just demonstrating how lazy loading works. 


Shrinking Images with TinyPNG

Looking for a place to shrink your images? TinyPNG is the place for you! Upload up to 20 .jpg or .png files at a time, with a maximum size of 5mb each, and they'll compress them! 

Need more? Just refresh the page and do it again. 

Need an API? They have API's.

In a lot of scenarios, when you compress an image you'll also be losing a lot of it's quality — TinyPNG does a fantastic job of keeping the quality very high! They say it's fully "lossless", and I can only think of 2 times in my years of using their service that it wasn't fully lossless: and they were both very high quality gradients background images, and the loss was very minimal with a compress rate over 60%. It was still worth it!

TinyPNG for the win!

Shrinking Images with imagemin

If you're using Node to build your website (even if it's just the frontend) there's a beautiful package you can install called imagemin

It basically does what TinyPNG does, but you have to install it. And if you're not using Node, this option isn't available to you. The compression ratios are almost identical, too!

The Ultimate Win: Gzip

At this point I'm assuming you'll be optimizing your images, JavaScript and stylesheet files. But there's one more thing you can do: gzip

Chances are, if you're reading this article, you're unfamiliar with gzip or you've heard of it but haven't used it. 

Gzip (GNU zip) is a free and open source algorithm for file compression

Essentially, you can tell your server which files should be served as a gzipped file. You can enable this through nginx or Apache, and it'll compress the file before it serves it when the user makes an HTTP request to your static asset. 

Gzipping can give you MASSIVE gains: I've seen instances where the gzipping on a basic .css file reduced the file size by another 75%, on top of minification and flattening your CSS.

Here's how it works: A user hits your website and the browser creates an HTTP request for a main.css file. Your server gets this request, looks for the file, finds the file... and instead of returning the contents of the file, it runs it through a gzip compression algorithm to compress the file so as it travels down the wire (through the internet) it's smaller and faster to load. Because gzipping is open source, pretty much every browser supports it.. so once your browser receives this compressed file, it can uncompress it and load it. So now your load times are ultra fast!

This article won't go through the ins and outs of gzipping, but this is the biggest win by far. And you can tell nginx or Apache to automatically compress all *.css, *.js, *.jpg and *.png files. So if a user uploads a large image, it'll automatically recieve the compression treatment, even if you don't run the image through TinyPNG first. 

Google PageSpeed

Lastly, you'll want to check your page speed. Google has a great tool for checking this and giving you a rating it's called Google PageSpeed

Just plug in your website URL and hit Analyze. Git it a minute or so, and it'll give you a score for desktop and mobile. It'll also give you ideas on where to optimize your website, and what you're already doing well.

Did you learn something new and useful?

Consider singing up on Kalob.io for unlimited access to all my courses. But if that's not your thing and still want to support me, I'd love if you could share this page with your friends and coding groups. Just click the social media icon of your choice! 

Sign up for the newsletter!

Sign up for my free newsletter. No spam, all dev talk and only awesome articles. Opt out at any time, no hard feelings.





About the author

Kalob Taulien

Full stack developer. Entrepreneur and dev teacher. Over 100,00 students world wide.

I started making websites long before CSS had rounded corners, before JavaScript was more popular than oxygen and videos could only be played through Macromedia Flash. 

Today I'm a full stack LAMPP (PHP and Python) developer that enjoys teaching web development and working with startups. 

Connect with me: