Device aware content caching in Nginx

Device aware content caching in Nginx

It’s known to all that performance of applications and web sites is a crucial factor in a product’s success. However, improving the performance of your web site or application involves so many important steps which are not clear most of the time. The quality of code and content, making site responsive is conventional way of quality and performance of website or app.

However, we can further improve the end user experience by delivering device specific contents. This delivery technique involves serving desktop layout only for desktops and mobile layout only for mobiles. Which reduces payload size, contents are reached to devices much faster and we can apply the best possible device specific optimization.

This blog post covers techniques of how we can detect end user device type from request and then generate contents according to end user’s device type and finally cache the contents separately so that we can save resources. At the end of the post, we will also look at how we can purge cache.

Our tutorial is divided into 2 steps.

  • Explanation of the main application server setup.
  • Explanation of the reverse proxy which happens to have the caching setup.

Application Server:

Our application server is a simple PHP laravel application, which is running on port 8080. The nginx configuration is also simple which looks like below

We can now access the application by simply hitting the IP address and port we set in the configuration. However, the content is not cached and this is not great where the contents are not dynamic.

Setting up reverse proxy server:

This is another nginx server which is served on port 80 and sits between the User and application server. Our goal with this server is to intercept a request and give response from cache if we already have a cache set up for the particular request. Thus we can save a lot of processing power and dispatch response much faster.

Simple reverse proxy server without caching, which simply forwards all requests to application server:

Adding caching capability to proxy server:

Now that we have an intermediary server set up in between user and our application server, we can now configure this server to cache contents. So every time, if a user requests a content , it comes to the proxy server, if the content for the requested URL is found in the cache it will be served straight from the cache instead of forwarding the request to the application server.

For this, we have to define the cache configuration in the http block of nginx and then we can use it in the server block.

We named the configuration for the cache edge-cache, which we will use in the server configurations. If we notice the configuration, we’d see that the cache_path is set to /var/www/cache, This is the place where nginx will store the cache data.

Finally we can use the below code in the location block, so that nginx stores right contents for right platform

The $uri in the above cache_key, different for desktop and mobile requests. Thus, the cache storage also becomes different depending on user’s device type.

The final configuration for reverse proxy:

Finally, we have setup the cache with nginx in our expected way. Now the application can serve right contents for right platform and that is even can be cached. Following, this method not only help us send the most optimized contents for all the platforms, it also improves load time.


Purging content:

We will not cache a content for ever in the reverse proxy. We will need to clear cache for a specific URL when contents for that URL is updated. For that there is an open source project we can use to purge the cache of that content. The project can be found in this URL :

After cloning it in one of the server directory, we can run the purging commands while being in the projects directory. For example if we want to clear all the caches of a project we can simply do,

A lot of other type of commands available in the repository’s readme sections.

Leave a Reply

Your email address will not be published.