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

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