Posts

Showing posts with the label Site Performance

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...

Five common mistakes that websites make with Google Tag Manager

Google Tag Manager  (GTM) is one of Google's best products - second only to its ubiquitous and feature-rich Google Analytics product.  GTM, as its name implies, is a tag manager that's used to embed JavaScript, HTML, and/or CSS code into websites.  Such code can include, but is not limited to, analytics scripts like Google Analytics, tracking beacons from online advertisers, and proprietary content from websites themselves.  There's no denying that GTM is a powerful tool; one that represents a major shift forward from the bad old days of self-hosted, spaghetti-code.  But like most technology, if it's not used correctly, GTM could end up causing more problems for a website than it solves.  Problems having to do with slow performance, mostly; but also tag misfires, data corruption, and quota limitations.  In this article, we'll be discussing solutions to such problems by exploring the five (5) common mistakes that websites make when setting up GTM. M...

Stop transferring metadata to end-users

If you were given a dollar by every website that transferred unnecessary metadata to you, you'd be richer than Bill Gates!  Well, not really; but you'd at least be well off.  You see, very few people realize that the websites they visit on a daily basis are transferring useless metadata to them -- including seasoned website developers, designers, and marketers.  And, even when people do realize it, they often assume that it's a best practice.  It's not!  In fact, it's one of the reasons why the web has become such a bloated medium.  Well, that and images, stylesheets, javascript, fonts, etc. -- all of which are even bigger culprits than metadata.  Still, that's no reason to ignore metadata -- it's been ignored for far too long!  Thus, in this article, I'll shed some light on the problem of transferring unnecessary metadata on the web as well as discuss several solutions for dealing with it. What is metadata? According to Wikipedia , metadata r...

Shorten the URLs of static resources

You've seen them before... those exceedingly long URLs of static resources on websites.  No?  Well, just view-source on your favorite website or copy & paste the address of a static resource from Google to see the problem for yourself.  Done?  You've probably noticed that the most ubiquitous examples by far are those of images -- many of which have cryptic URLs like " /images/G/01/gno/sprites/nav-sprite-global_bluebeacon-V3-1x_optimized._CB516556901_.png " and " /v/c/assets/navigation/image/drawer-sunwear/21/edee9f4c82.jpg " or even " assets/images/homepage/top/navigation/cart-icon.jpg ".  But the problem isn't limited to just images; there are other media types with exceedingly long URLs too, i.e. video, audio, CSS, JS, etc. When did this trend start? Over the past few years, it seems, the web has Gone Wild with exceedingly long URLs; or, perhaps it's website developers and designers who've gotten lax about their craft.  But wh...

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-cl...