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.
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
Post a Comment