Queued, Concatenated, and Gzipped Assets with the Zend Framework

Linking assets to your templates and layouts is always a mine field. Every person has a different way of doing it and if it is done poorly, it can adversely affect the load time of your website, particularly if you have lots of websites. It’s helpful to understand how the http protocol fetches things like stylesheets and javascript files while it’s loading your page. In order to alleviate traffic for any individual server, a browser is limited to only so many concurrent requests to the same host. I do not recall what that limit is on each browser but I’m sure google does but in any case, if your site is of significant scope, chances are, you are going to need more assets than your browser can pull in at once. If you don’t believe me, install the yslow extension for firefox and run it on a page with many assets and you will see what i’m talking about.

Essentially you start with something like this

Pretty nasty but not uncommon and fairly minimal for a site that uses alot of jquery plugins. When the page loads, the browser must make an entire http request for each asset with all the overhead that entails. Don’t panic, there’s a solution to this mess that allows you to bundle all these assets withouth compromising in performance.

The solution is a two step approach, the first is a common php trick that concatenates javascript files and gzips them. It is well known that it is much cheaper to download one larger file than it is to download multiple smaller files. In your javascript folder create a php file called js.php:

This script takes a single parameter ‘include’ which is set to a comma separated list of javascript file names sans the .js extension. The assumption is that the script files are in the same folder as js.php. The script will load the contents of all of the javascript files specified and stream them as one long gzipped string. We use it as follows:

Now we have optimized the assets so the browser makes only one request to the server for all javascript assets. It’s only a minor edit to the script to do the same trick for css files. We create another file called css.php:

The only major difference is the Content-Type header. This allows us to include css files in the same way:

Great. So now we need a way to leverage this method using the view helpers included with the Zend Framework when using Zend_View and Zend_Layout. Initially, I used Zend_View_HeadScript and Zend_View_HeadLink to do this which works fine however these helpers do not intelligently manage redundant includes. What do I mean by this? Well let’s say we have a global layout that includes a number of stylesheets and javascript files that are shared across a web application. Something like this:

This will cover the common cases. We don’t want to throw in everything but the kitchen sink in the layout as it imposes performance penalties on many pages that may not need access to certains scripts or stylesheets, so we instead invoke the view helpers in the action templates themselves to inject additional asset dependencies. For example:

This works great for the most part but occasionally there is some overlap either because of a developer mistake or maybe the layout is dynamically chosen for whatever purpose resulting in redundant script or stylesheet includes. Also we are making two distinct requests instead of one.

It’s not the end of the world but it bloats up the size of the assets download. So what we need is some additional view helpers which extend functionality of Zend_View_HeadScript and Zend_View_HeadLink to more intelligently queue requests for assets and eliminate redundant calls. I have created a view helper called AppendJs which does just this:

This view helper stores an array in the Zend_Registry to keep track of all the javascript includes that have been requested in the current request. This way it is able to remember what has already been requested and ignore redundant requests. Similar to the way Zend_View_HeadScript and similar view helpers work, if no parameters are passed to the view helper, it instead outputs a script tag with a automatically constructed csv string. Additionally, if you separate out your assets for each application module, you may want to indicate which module you wish to include assets for. You may need to adjust the view helper to accomodate your asset folder structure.

Let’s take our original layout (minus the stylesheet examples) and modify it to use our new view helper:

We are now using our appendJs view helper. We will keep the framework view helpers for special cases where templates need to use them.

We do the same with our action template. The final output will look like:

Using this approach we now have a single script tag with everything concatenated and gzipped. The same thing can be done with stylesheets by defining a similar view helper called AppendStylesheet. I won’t show it here, I think you get the idea.

Have your cake and eat it too.