October 5, 2019

Tuning Sitecore's media handler

During some debugging session, I dug into the inner workings of the way, media requests are handled inside Sitecore, and one thing I did not give much thought into - before this - was that all media requests are evaluated if they should trigger a goal or do other stuff related to Sitecore's tracking and personalization features.

Think of it for a moment. Every media request.

In my experience, there are a lot of media stored in the media library that customers care very little for, such as svg icons, header images, logos even.

Why should they be tracked at all?

This PoC gave some ideas to where there really is some performance to gain from doing very little. The mantra was to inspect the media request's tracking field and see if there is anything specifically set, otherwise we do not care about tracking.

For the impatient, the code is available on Github, right here: https://github.com/larserhardsen/CacheableMediaRequest

The PoC consists of two entry points;

  • an http handler which overrides and replaces Sitecore's built-in MediaRequestHandler by inheriting from it and adding cache code,
  • an http module, which inspects the request before letting Sitecore's own modules process the request.

The MediaRequestHandler was extended to check if the media item has any tracking set, and if that is the case, no caching is done.

The http module checks for the obvious existence of ~/media/ or -/media/ in the URL, and ultimately if the URL exists in the cache. If it does exist, the request never reaches Sitecore!

The speedup is pretty clear.