SERVER SIDE

I attended the Saxotech Conference in 2012 and went to a workshop called Effective Template Design. My goal for attending this conference was to find a way to speed up my client’s sites. Their code had been written by another developer and my goal at the time was to take this code and find a way to rework it so that the site loaded faster. When I went to the Effective Template Design workshop, I learned several tips that I am going to share with you here, along with tips I have learned along the way. You can find that presentation here.

 

Use macros instead of .inc files

There are several reasons to use macros instead of .inc files:

  • An include file is rendered every time the page is called, having to process that code, while a macro has the ability to set cache times which will control how often the code is rendered. Information on caching provided by Saxo docs.
  • Using a macro gives you access to variables that you wouldn’t be able to use in an include file. For example, system variables like <%currentrequest%>,<%currentdate%>, or global variables that you have created. See complete list of available system variables here.
  • You can use variables between macros by adding “before” to one macro, and “after” to the other so that you are able use the variable set in the first macro in the second macro.

I would like to note, that even though it is recommended to use macros instead of .inc files, it doesn’t mean that you shouldn’t use .inc files in some cases. If for some reason it makes more sense for you to organize a bunch of macros in an include file, then do so. Macros are recommended as the better practice. I will say that I have successfully built a site consisting of all macros and have had no issues.

 

Turn on fast cache

Fast or static caching creates a cache file for an entire page, instead of individual sections of a page. Be sure that you have static or fast caching turned on. If you are unsure, I recommend speaking with your Saxo CSR and finding out. If you have access to your publicus.ini file, you can check for settings such as FastFrontpageCacheTime, FastSectionCacheTime, or FastArticleCacheTime. If you see these values, it is a good indication that fast cache is turned on. You can view the publicus.ini cache settings and descriptions here.
Please note, that just because you see a setting on your sitecode publicus.ini does not mean that there isn’t a setting server side (that you don’t have access to) overriding it. Turning fast cache on is something that Saxotech would have to do for you because they add settings to the server side publicus.ini file.
I also highly recommend having fast cache turned on in the staging environment first and thoroughly testing it. I have been told that adding fast cache to a site would not have any impact, but I did have issues with certain items caching though they weren’t supposed to. The fix involved adding cache qualifiers to the SectionActionCacheQualifier setting on our publicus.ini file.

 

Switch from file caching to database caching

With database caching it is much quicker to recache a site because the system is able to pull up cached content faster.

 

Don’t use macros more than 1 level deep

This is the Saxotech recommendation. I have found it nearly impossible to have a site with macros at only 1 level. I usually limit myself to macros that are 2 levels deep because I have seen strange behaviors and caching issues when I try and add a third level. A common problem I have run into with macros and caching (even at 2 levels), is that my tags might not generate. Meaning, my content isn’t appearing and if I view the source code I can actually see the tag in the HTML. This is usually caused by creating a first macro and running it uncached, for example <pbs:!macro name=”macro1″ cachetime=”1440″> and having a nested macro within that macro1.pbo file, <pbs:!macro name=”macro2″ cachetime=”1440″>. There is a rule that you are not supposed to have one uncached macro called from another uncached macro. If I eliminate the ! from the macro2 call, the macro works as expected.

 

Limit info requested in a tag

If you change an article tag from
to something like
you are eliminating the byline, text and image items from being called. This will shorten the time it takes to call, return and output the data. Keep the days searched as low as possible. For example, if you have a newslist that is displaying 5 of the most recent articles, and that section is updated daily, you can set days=7 and only return 7 days worth of content that would fill up the section. I add 2 extra days in case someone takes a day off. If you set days=30, then you are needlessly calling extra data that won’t be displayed since the 5 spots will be full after the 7 days.

 

Limit script use

While there will be instances where writing a php or vb script will be necessary, be sure to use pbs tags, macros and object files if possible. A common mistake that developers new to Saxotech make, is to write a script to solve a problem in a language that they are more familiar with instead of using the Saxo templating format. Doing this will create a strain on the database and you will get better performance if you use the templating system as it was built to be used.

 

FRONT END

CSS and JS

To ease load times, combine and add all .js to the bottom of the page, combine and add all .css into one file. When page loads only 2 files get loaded at a time, except for .js, which loads one file at a time and not until the file is processed does it move on. You can also look into finding a way to load your .js files asynchronously, with a tool like http://labjs.com/ or http://requirejs.org/. Minifying your files will also help reduce the time it takes to download the file because it is smaller in size. This blog post lists several tools to help with minification.

 

Google hosted libraries

Use Google hosted libraries when possible. Since this is a CDN (Content Delivery Network), it is much faster for a user to access these libraries instead of going directly to your one server that holds the file to download it. This also eliminates a request to your site to access the file, allowing room for other files to be downloaded in its place. Also, chances are a user might already have this file downloaded from visiting another site. If they do, the browser will use the cached version and not take the time to download a file that already exists.

 

IN CONCLUSION

I have made significant improvements with Saxotech site speeds implementing most if not all of the recommendations above. The goal is to keep users coming back to our sites and long load times will be a deterrent. What do you do to improve your site speeds?