Skip to main content

A newbie's guide to website optimization

Okay, you're here; welcome.  Let's get started right away.  First, you should always minify and compress your website's static resources using Gzip, Brotli, Lossless, etc.  (To be clear, by static resources, I mean HTML, CSS, JS, images, videos, fonts, etc.)  Next, you should use a Content Delivery Network to host said static resources, i.e. Cloudflare, Cloudinary, Fastly, etc.

You shouldn't, however, bundle your static resources together; in particular, your CSS and JS files.  There was once a time, long ago, when it was considered a good strategy to bundle and shard your static resources, but that time's long since past.  Nowadays, with the ubiquity of HTTP/2, you're actually doing your users a huge disservice by bundling.  In case you're unfamiliar with it, HTTP/2 reduces "latency by enabling full request and response multiplexing, minimizes protocol overhead via efficient compression of HTTP header fields, and adds support for request prioritization and server pushes" (Ilya Grigorik, Google).  There's just one catch: your website must use SSL.  In truth, all websites today should be using SSL by default; it's not just good for performance -- and obviously security -- but it's also good for SEO, so says Google.  But I digress.

Another thing that you shouldn't do is version your static resources with every build; doing so will unnecessarily invalidate your cache.  Rather, you should use ETags to indicate that a file's contents have changed, instead of actually changing the file's path or name.  Even better, you should strive to limit your use of static resources altogether.  I mean, do you really need another CSS, JS, image, video, font, etc. file on your website?  IMHO, YAGNI.  Now, if you follow all of these recommendations, your website's performance will improve -- probably to within 80% of your industry's standard.  However, if you want to eek out the remaining 20% of gains, you'll need to do a few more things!

First, cache everything!  Cache your static resources, database queries, application logic... everything!  At every turn of your website's development process, you should be asking yourself "How can I build this thing in such a way that it can be cached for at least a year?"  Now, I realize that's a lofty goal -- for which you'll likely fall short -- but you should strive for it nonetheless.  Note that by "cache everything" I don't necessarily mean serving everyone the same cached object (though that would be ideal); it's totally okay to cache a user-specific object that takes a long time to retrieve from your backend.  Also, be sure to cache your objects as close to your edge servers as possible.

Second, install, configure, and enable Google's PageSpeed module on your Apache or Nginx servers.  PageSpeed has a bunch of safe, low-risk optimizations out-of-the-box that it performs on websites; they include collapsing whitespace, eliding attributes, trimming urlslazy loading images, and removing comments -- just to name a few.  I'm honestly at a loss as to why more websites don't use this module by default; it's a no-brainer.

Third, you should avoid embedding any third-party scripts into your website like the plague (be they for advertising, re-marketing, analytics, or even development purposes, i.e. NPM modules).  Many third-party scripts seem to exist only to defeat your efforts in achieving your performance goals.  You should fight against their use at every turn, i.e. force your marketing department and fellow developers to justify the use of yet another script on your website.  And, should lose the fight (most developers do), at least insist on your marketers using a tag management solution like GTM, which will allow you to asynchronously load the scripts after the webpage has been rendered.

Taken together, the aforementioned best practices are guaranteed to improve the performance of any website, i.e. bring it to within 100% of its industry standards, as measured by tools like GTmetrix, WebPageTest, SpeedCurve, etc.  Now, you might not achieve 100% right away -- after all, website performance optimization is more art than science, so don't get discouraged when a particular optimization doesn't produce the desired results -- but if you keep iterating on your performance goals you'll eventually achieve them.


Post a Comment

Popular posts from this blog

A better UI/UX for Cookie consent banners

I'm sure you've seen them before; those pesky, inescapable  Cookie consent banners !  They typically appear at the top or bottom of websites -- often obscuring important content.  For example, if you were to visit  CNN ,  Zara , or  Unicef  today; or, any other news, e-commerce, or charitable website for that matter -- especially those with an international presence -- you'd likely see one; a UI / UX eyesore.  Such Cookie consent banners, ubiquitous and omnipresent, have become the defacto solution for complying with an important part of the European Union's (EU) ePrivacy Directive  (ePD). If you're unfamiliar with the ePD, it basically mandates that websites first obtain a user's consent before storing and/or retrieving any Personally Identifiable Information  (PII) about them in and/or from HTTP cookies.  ( HTTP Cookies are small pieces of data stored by websites in a user's web browser for easier retrieval later.)  The Cookie Law, as the ePD has becom

The Crucial Role of Service Level Agreements (SLAs) and Service Level Objectives (SLOs) in Software Applications

In today's digital era, software applications are at the heart of business operations and customer experiences. From e-commerce platforms to enterprise solutions, the performance and reliability of software applications can make or break an organization's success. To ensure seamless operations and meet customer expectations, having robust Service Level Agreements (SLAs) and Service Level Objectives (SLOs) in place has become paramount. In this blog post, we will explore the importance of SLAs and SLOs and how they contribute to the success of software applications. Defining SLAs and SLOs A Service Level Agreement (SLA) is a contractual agreement between a service provider and a customer that defines the level of service expected. It outlines the metrics and targets the service provider commits to achieving, such as uptime, response times, and resolution times. SLAs establish a mutual understanding between the parties involved and provide a framework for measuring and managing s

Using HTML tables for website layout

I first became a front-end web developer in the year of our Lord, 1998.  Back then, the HTML specification had just reached version 4.0; Internet Explorer 7 was the dominant browser; and, the mantra of separation-of-concerns  was still being preached to web developers.  (Back then merely uttering the phrase CSS-in-JS  would've gotten you killed, professionally speaking.)  What's more, back then, HTML tables were still de rigueur; in fact, many websites used them for layout purposes ( DIV-itis hadn't caught on with the masses as yet; that would happen several years later.) Yes, it was the stone ages of the web -- in comparison to today.  Today, there's a wealth of newer technologies for developers to choose from when building websites, i.e. HTML5 , CSS4 , ES9 , etc.  Long gone is the mantra of separation-of-concerns and in its place sits CSS-in-JS, mockingly.  And, long gone are table-based layouts too; they gave way to the aforementioned DIV-itis phenomenon and t