Every two weeks I send out a newsletter containing lots of interesting stuff for the modern PHP developer. You can expect quick tips, links to interesting tutorials, opinions and packages. Want to learn the cool stuff? Then sign up now!

Speed up a Laravel app by caching the entire response

A typical request on an dynamic PHP site can do a lot of things. It’s highly likely that a bunch database queries are performed.  On complex pages executing those queries and hydrating them can slow a site down.

The response time can be improved by caching the entire response. The idea is that when a user visits a certain page the app stores the rendered page. When a second request to the page is made, the app shouldn’t bother with rendering the page from scratch but just serve the saved response.

I’ve made a Laravel package named “laravel-responsecache” that does just that. Installing it is very easy: just add the service provider and facade to the app’s configuration. And step two is… there is no step two. In most cases you’re done.  All successful responses (that is a response with a statuscode in the 200 or 300 range) to a GET-requests will now be cached for a week. If the response of a specific route or controller should never be cached middleware can be added that prevents caching. Furthermore each logged in user will have have it’s own separate cache. Cached responses can be stored in any configured repository in Laravel. You could easily share a cache between servers  by using memcached.

I think that behaviour will suit a lot of use cases. If you need some other caching behaviour (eg. cache error responses, exempting redirects, using a common cache for users with the same role,  changing the expiration time of the cache) you can easily write a custom caching profile.

The package isn’t supposed to sweep performance troubles under the rug. All apps should be optimized so that they’ll respond in an acceptable timeframe without using response caching. My rule of thumb is that typical pages in a cms should be able to render within a second (and preferably much less). Anything above that is unacceptable. That number is by no means scientific. Make up your own mind what an acceptable responsetime should be. Of course all of this depends on the type of site and the amount of visitors it has to handle. Also keep in mind that that there are a lot of other aspects that need to be considered when trying to deliver a speedy experience.

There are some great alternatives to cache responses. Two well known solutions are Varnish and Nginx caching. They take response caching one step further by not even invoking php when serving a cached request. Both options are very robust and can work on any scale.   The benefits the Laravel package has over Varnish-like solutions is that it is easier to set up and that application logic can be used to determine what needs to be cached.

If you’re interested in speeding up your Laravel app using the package, go take a look at it on GitHub:


Freek Van der Herten is a partner and developer at Spatie, an Antwerp based company that specializes in creating web apps with Laravel. After hours he writes about modern PHP and Laravel on this blog. When not coding he’s probably rehearsing with his kraut rock band.