Skip to main content

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 refers to "data that provides information about other data".  That is to say, metadata can describe a resource for purposes such as discovery and identification; it can indicate how compound objects are put together; and, it can provide information to help manage a resource (Wikipedia).  If we apply this definition to websites, metadata can be classified as any data in the HTML markup of a webpage that's not shown directly to end-users; or, used by the website itself to properly function.  For example, elements such as a webpage's "description" and "keywords" are neither shown to users nor required for the website to function.  Now, that's not to say that metadata is useless; it's generally useful for something or to someone -- just not necessarily end-users.  For example, the aforementioned "description" and "keywords" tags are useful to search engines, comments are useful to developers for debugging, and conditional comments are useful to Internet Explorer browsers less than version 10.

No harm, no foul! Right?

Wrong!  Unnecessary metadata bloats websites and harms end-users.  How do you ask?  Well, first and foremost, it costs websites real money to transfer unnecessary metadata downstream.  Just think about the number of servers, processes, memory, etc. that could be reduced by sending fewer data to users -- not to mention the potential performance improvements that could come about as a result.  Then there's the cost to end-users' internet bandwidth, computer resources, time and attention in having to download, parse, and render unnecessary content.  Shouldn't that be avoided, if at all possible?  After all, not everyone lives in countries where broadband is ubiquitous and relatively inexpensive.  Rather, over half of Internet users live in third-world or developing countries where broadband is notoriously slow and costly; and, many of them don't own speedy iPhones or Android devices.  Thus, it's vitally important that every website -- specifically their developers, designers, and/or marketers -- respect each end-users time and money by putting more thought into what's sent downstream.

So, what do you propose?

Given that most metadata is either intended for use by search engines, user agents, or developers, I proposed only sending metadata when it's requested by a specific audience.  Take, for example, the "description", "keywords", and "canonical" tags on most websites; they're only required by search engines such as Google, Bing, and/or Yahoo for SEO purposes.  Therefore; those tags should only be rendered when a website can detect the requesting UserAgent string such as Googlebot, Bingbot, and/or Yahoo Slurp!  The same can be said for the "apple-touch-icon", "msapplication", and IE conditional comment tags; they should only be rendered when a browser like Safari or Internet Explorer is being used.  Yet another example is social media tags from the likes of Facebook, Twitter, Instagram, etc.  Such tags should again only be rendered when a UserAgent Twitterbot and/or Facebot is being used.  Lastly, developer-specific information could be hidden behind a feature flag that's based on a parameter in the URL.  This is by no means an exhaustive list of solutions; I encourage you can come up with your own.

In closing, I hope I've convinced you to audit your own website(s) and remove any and all unnecessary metadata that you may be inadvertently transferring downstream to your end-users.  I'm of the belief that more can be done on Production websites to stop spamming end-users with unactionable metadata.

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

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