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

Black Lives Matter: I CAN'T BREATHE

Black Lives Matter (BLM) is a political and social movement that protests against police brutality and violence towards black people.  In July 2013, the movement began with the use of the hashtag #BlackLivesMatter on social media after the acquittal of George Zimmerman in the shooting death of African-American teen Trayvon Martin 17 months earlier in February 2012.  The movement became nationally recognized for street demonstrations following the 2014 deaths of two African Americans, that of Michael Brown—resulting in protests and unrest in Ferguson, Missouri, a city near St. Louis—and Eric Garner in New York City.  Since the Ferguson protests, participants in the movement have demonstrated against the deaths of numerous other African Americans by police actions or while in police custody. Listed below is a shortlist of black men -- grandfathers, fathers, husbands, sons, and nephews -- that have died at the hands of the police and white supremacists in America. Patrick Lynn Warren Sr.,

Reduce the transfer size of HTML responses

According to the HTTPArchive , the average transfer size of all HTML responses for a single website is 50kB.  That's not much -- especially when compared to the size of JS, CSS, image, or even font resources -- but those 50kB nonetheless add to the ever increasing bloat of webpages.  Bloated webpages   make websites dreadfully slow, and even a minor increase in load time can cause a significant decrease in sales, according to both  Google and Amazon .  So HTML transfer size matters; it's an important metric to pay attention to and to reduce.  That's why I'll be focusing on several ways in which to reduce that 50kb number in this article. To begin, let's take a look at a few websites. A cursory check of the top 500 websites  shows that they contain dozens of useless tags that neither add value to end-users nor to browsers tasked with rendering them.  A case in point is the  Engadget  website, which can be inspected by right-clicking on the site's homepage and s

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