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: https://cnet2.cbsistatic.com/img/KMgYILc1hQk7UH5htU8Pc5rsEtY=/618x370/2017/11/13/a8dbc377-bae2-4027-9545-9144ea86aac1/oneplus-5t-product-20.jpg.  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. https://goo.gl/V3ehfd.  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.

Comments

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

Happy Father's, Mother's, Sister's, Brother's, Son's, and Daughter's Day

Today is Father's Day in the US. And to celebrate it, my wife and kids got me 6 pairs of socks, 2 shirts, several packs of sour candies, a $25 Domino's Pizza gift card, and a mug emblazoned with the phrase "Good Man, Great Dad". I'll probably never use any of those things; they're all crappy IMHO. (Well, maybe I'll use the gift card and eat the candies; I love sour candies.) But this post isn't a Father's Day rant about the crappy gifts that men receive in comparison to women on Mother's Day; rather, it's about a conversation that I had with my son Kyle about why there isn't a Brother's or Sister's Day too. To quote him: "The world should really have a Brother's Day and a Sister's Day. If not, they should get rid of Mother's Day and Father's Day. I know it's traditional but It's really not fair."  Clearly, he felt left out! Not wanting to let a good opportunity to have an in depth conversation w

A case for WordPress; or, not your own CMS

I've worked at several major companies thus far in my career; and, at each of those companies, I've had to use an in-house Content Management System (CMS)  to create and modify digital content.  For a long time, I couldn't understand why those companies would choose to allocate time, resources, and ultimately money to create a customized CMS in spite of having functionally equivalent, open source solutions readily available in the marketplace.  What was their rationale for doing so, I often wondered?  Was their businesses so unique that an off-the-shelf CMS simply wouldn't cut it; were the security risks associated with an open source CMS too great of a burden to bear; or, was it because the software engineer(s) in charge at the time simply wanted to showcase their PHP, Java, Python, etc. programming skills by building yet another CMS from scratch.  Well, in the years since I first pondered that question, I've come to realize that the answer is often the latter rea