Any web layout designer, web designer, web developer, or even someone who just enjoys “building websites” knows that their work is a constant and challenging battle. Usually, knowing markup, stylesheets, and some server-side basics isn’t enough to build a site that can truly compete in the market of services and offerings. Yet that's exactly why websites are built — to compete. At the same time, each of us is capable of creating a beautiful site with lots of modern technologies and impressive functionality across most browsers. Aaaand... it can be very slow. It might take a long time to load. Images might render, text may appear, but the functionality (scripts and other related assets) will still be loading and loading. Even with high-speed internet. That's why optimization is something that must not be overlooked when working on a site.

In simple terms, the goal of optimization is to reduce page load time. Some steps may reduce that time by several seconds, improving the overall user experience. Others may only shave off a few milliseconds. Still, every step matters.

A fair question: "Why should I care about milliseconds?" It's about more than just speed. We'll explain the importance of each step further below, but here's a quick example: one of the goals of webpage optimization is to reduce the number of HTTP requests made by the page. Each request takes about 50 milliseconds just to establish a connection with the server — not counting the time it takes to download the file. Fifty milliseconds may not seem like much, but the goal of reducing requests is to lighten the server load and improve server performance.

Specifically, we’ll talk about reducing file sizes (of an individual page). This not only improves load times for users but also saves server bandwidth. It can be done in a few simple steps.

Let’s start with something basic and familiar, but always important.

Don’t Resize Images in HTML

Don’t change the size of an image in the browser. Some web developers, wanting to display a small image (a thumbnail), use height and width attributes (via HTML or CSS) to resize a larger image. Yes, it saves time and disk space since you don’t have to create or store multiple versions of the image (large and small). Sounds great, right? Not at all. This approach comes with two major downsides you should consider.

For example, think of wallpaper sites where each page features multiple thumbnails of high-resolution images. There are plenty of such sites (e.g., bigpicture.ru, zastavok.net). You can find resized images on many different types of websites.

Load Time

A full-size image may not be shown (a thumbnail may be displayed instead), but the user still has to wait for the full-size image to load. For one image, it could take 10–13 seconds over mobile or even fast internet. If you resize multiple full-size images on one page, the total load time increases dramatically. A gallery of 10 wallpapers using pre-made thumbnails might weigh only 50 KB — resulting in nearly instant loading for average connections. In contrast, if thumbnails are just resized full images, the page might require 2 MB to load! That’s a major difference.

Parsing Time

Parsing time (reading and processing code) is also affected by resizing. Using width and height attributes means the browser must calculate and resize large images to thumbnail size. These are precious milliseconds wasted per image for every user! Not to mention the added strain on the server and bandwidth.

But... the hassle. As the developer, you'd have to open every image in your favorite editor, resize it, upload it, relink it — and so on. Luckily, modern server-side scripts can automate this. No need for manual graphic editing, uploads, or manual linking. Still, keep in mind the "cost" of in-browser resizing — for both servers and users — and train yourself to avoid it.

Minify JavaScript

A quick and easy way to save server bandwidth and reduce load time is to reduce the size of your JavaScript and CSS files. JavaScript, in particular, is often bloated with overly long variable names. Why refer to myFavoriteVariable 500 times when you could just use X and save 17 bytes each time? Why include dozens of tabs and line breaks when they serve no functional purpose? Now, we’re not advocating for ugly code — clean, readable code is always a best practice. Use yourFavoriteVariableName and indent your code properly while developing. Readability is important for humans. For browsers, it’s irrelevant. So how can you write readable code but deliver a minified file to the user? The answer: use a minifier!

Like with image thumbnails, you can automate minification. For example, Google provides a tool called Closure Compiler. This service filters your nicely formatted and commented code and outputs a compact version that you can copy into a separate file for use on your site. Naturally, the resulting file will be much smaller. You can choose from three optimization levels: whitespace-only, simple, and advanced.

The whitespace-only option is self-explanatory and easy.

Simple is usually what you want. It doesn’t rename public variables that may be called from outside the script. For example, if you have a JavaScript file containing a function named expandCollapse, and that function is called via external links or other scripts, Simple mode won't rename it — preserving functionality.

On the other hand, Advanced treats your script as a self-contained program. It renames all variables and removes unused code, which often breaks external calls to the script.

Here are a few compression examples from GitHub:

Uncompressed — 301 bytes

Whitespace Only — 212 bytes

Simple — 186 bytes

It renamed all internal variables but preserved the function name for external access.

Advanced — 139 bytes

The function i_heart_you and variable my_custom_code were completely removed, as they were only used once. Oddly enough, it didn’t merge both document.write calls.

Still, there’s always room for improvement. The shortcomings of the Advanced mode — and minifiers in general — lead to one important point:

After minifying your code, test it. And that’s not enough. Don’t blindly trust that the compiler did everything correctly. If Simple or Advanced mode breaks your functionality, at least be able to rely on the Whitespace-only method to preserve your code's integrity.

Minify CSS

While JavaScript minification can drastically reduce file sizes, don’t forget CSS! There’s no single "best" CSS minifier, so each developer uses the tool they prefer.

But...

The problem with CSS minification is that there’s no universal method. It’s often a matter of trial and error. One way to reduce CSS file size is grouping by element:

Grouping by attribute:

Grouping by multiple shared attributes:

It’s impossible to predict which minification method will yield the best results until you test them — file sizes differ with each method.

Due to countless combinations of minification settings, you may need to experiment with different tools to find the most efficient approach. And unlike JavaScript, CSS minification rarely provides dramatic reductions and often takes more time.

Conclusion

Of course, there are many other ways to speed up your website: gzip compression, PHP optimization, caching, tiny favicons, and various CSS/JS tweaks. Even the methods discussed above can be modified or disputed — we’ve simply shared one path.

But even just paying attention to JavaScript and CSS minification, and avoiding image resizing in HTML, already makes you a more efficient and resource-conscious developer. Plus, in the era of high-speed internet, it seems like you can load anything onto a page and users will see and like it — and everything will work. But here’s the catch: not all websites are the same. Some load fast. Others... not so much.

So yes, optimization is still necessary. Imagine skipping it. Build a site without any optimization — not even for code. Forget image sizes, and throw in every tag, widget, and plugin you can find. And by the way, questions like “Why should I code manually when there’s a CMS?” or “How can I optimize CMS-generated code?” also come into play here. One last basic example: on WordPress, you can install a pile of plugins, even lightweight ones. But once the site goes live, it may load painfully slowly. So yes — optimization matters.