Skip to main content

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 when did this trend start?  Well, that's unknown; perhaps it started with the advent of Content Delivery Networks (CDNs) like Akamai or Limelight in the 1990s; or, with the dawn of cloud providers like IBM, AWS, GCP, etc. in the late 2000s.  CDNs and cloud providers replaced traditional data centers, and in so doing, lowered the bar for websites that once meticulously manage their in-house resources.  This, in turn, led to poor URL etiquette and the bloat we see today.  If I had to guess, I'd say the trend started about 2-3 years before the HTTP Archive started keeping track of bloated websites; so circa 2008.

Why is this a problem?

Regardless of when it started, the time has come to put a stop to the pernicious problem of exceedingly long URLs.  Why?  You may ask.  It's because long URLs create unnecessary bloat.  For example, here's an image URL for the OnePlus 5T phone from the CNET website:  The image's URL is not only long but cryptic; in fact, the only human-readable part of the image's URL is the string "oneplus-5t-product".  Ironically, that string just so happens to be the most valuable part of the URL -- at least from an SEO perspective.  The directories in which the image lives and/or its dimensions are all irrelevant for SEO purposes.  But let's be honest, solely relying on an image's URL structure for SEO value -- as opposed to adding some descriptive text to its ALT attribute -- is simply inexcusable in this day and age, especially with robust Content Management Systems (CMSs) readily available.  But I digress.

Is there an alternative solution?

The OnePlus 5T's URL length could be easily reduced by hashing the URI portion of the URL using an MD5 or SHA-256 algorithm, thereby turning "img/KMgYILc1hQk7UH5htU8Pc5rsEtY=/618x370/2017/11/13/a8dbc377-bae2-4027-9545-9144ea86aac1/oneplus-5t-product-20" into just "1FAF65D4D8DB4EC69DDEDEC60B9AA29B".  That's a reduction of 78 characters!  And while the new URI is still cryptic, it's much shorter in length; plus, it has the added benefit of forcing content authors to include some descriptive text for their images if they're to get any SEO benefits from it.  To take things one step further, the entire URL of the image (including its ".jpg" extension, which is mostly ignored by browsers anyway since a static resource's file type is set in its headers) could be shortened using a service akin to Google's URL Shortener, i.e.  Given such a shortened URL, the original image's URL length would be reduced by a whopping 122 characters.  (Note that the proposed URL shortening service would simply load the static resource rather than doing a redirect to the old URL).

What do users prefer?

Yet another reason to stop using exceedingly long URLs for static resources is that they don't provide any value to end-users.  In fact, many end-users would prefer shorter URLs; they're easier to remember and type and share on social networks.  Simply put, the benefits are overwhelmingly; the reduction in HTML transfer size alone is worth the effort of shortening long URLs -- not to say anything about the reduction in page weight, especially on mobile devices with slow internet connections like those in the developing world.  Now, I don't want to have to reiterate the disparaging remarks made earlier about relying on a URL's structure for SEO benefits -- though they're worth repeating -- so I'll just close by calling on my fellow developers and designers to put their websites on diet before their byte-size gluttony brings the web to a crawl.


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