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

No-Code or Low-Code Platforms: Building and Deploying Your Tech Business Idea in No Time

In today's rapidly evolving digital landscape, entrepreneurs and innovators constantly look for ways to turn their tech business ideas into reality as quickly and efficiently as possible. Traditionally, developing and deploying a software application requires a significant amount of time, resources, and technical expertise. However, with the emergence of no-code and low-code platforms, the barrier to entry has been significantly lowered, allowing individuals with limited coding knowledge to build and deploy their tech business ideas in no time. No-Code vs. Low-Code: Understanding the Difference Before diving deeper, it's essential to understand the distinction between no-code and low-code platforms. While they share the goal of enabling non-technical individuals to create applications, their approach has some critical differences. No-Code Platforms : No-code platforms are designed to empower users with little to no coding experience to create functional applications using visua