­­­Lately I’ve been working with a client using Tridion in an interesting way. This client manages websites for hundreds of customers, each site being virtually identical. Of course, information such as the customer name, contact info and store hours, along with dozens of other bits has to be customized for each site. One of the ways they manage this unique information led me to a useful discovery on how Template Builder handles large packages. Hopefully by sharing here I can save someone else going on the same wild goose chase I did.

In order to populate the rendered pages of each site, my client places all the pertinent information on the package when publishing a page. This way they can centralize all of the fields that need to be updated for a customer to a single component. Then a Template Building Block (TBB) grabs the information and fills in the blanks on the page, like a robotic Mad Lib.

This leads to the package for each page getting relatively large as it can have hundreds of items, which means hundreds of entries in the XML that makes up the package. When this page is run in Template Builder we see something I didn’t expected:

As you can see, each TBB in “Load Code Snippets” runs quite quickly, much less than a second generally. But when viewed as a whole, “Load Code Snippets” takes much longer. Multiplied across a few compound templates per page, a few dozen pages per customer, and a few hundred customers, this unaccounted for time could become quite a problem when publishing our site, right?

Before answering that question, let me explain what’s causing this gap. As you may have guessed, it’s the large publishing package that’s moving through Template Builder. The larger the package, the longer it takes for Template Builder to pass it around between TBBs. The quickest way to get a huge package (publishing package that is, for other types check your spam folder) is to have many items. This is because each item, even if it’s only a single character adds a few lines of XML to the package. A thousand items, each a single character long is significantly larger than a single item with a thousand characters.

With this in mind and eager to save my client hours and hours of publishing time, I set out to do two things:

1. Reduce the number of TBBs on each Page Template – by cutting down the number of TBBs our large package had to be handed between we’d cut down on tonnes of time
2. Consider adding our items as long, comma-separated strings – even with the extra time it would take to parse our giant string, given the time it was taking to pass around our large package, I figured we’d still come out ahead

After spending some time getting together a proof of concept for these two modifications I ran my page through Template Builder and saw a huge improvement, on the scale of 40% reduction of publishing time!

However, I was in for a surprise when I went to publish my test pages in Tridion. You see, Tridion publishing had always been much faster than in Template Builder, but I still expected a proportional improvement to publishing time. Imagine my disappointment when my changes barely put a measurable dent in publishing time. In fact, the publishing time in Tridion very closely correlated to the sum of each individual TBB’s time measurement in Template Builder, both before and after I made my modifications, meaning no matter what I did, “Load Code Snippets” in my image above took about 8s to publish in Tridion, rather than 24s.

What does this mean? It means that Template Builder’s time estimates start to break down as the size of your publishing package increases and we shouldn’t be too concerned if we see large publishing times in Template Builder until we make sure Tridion is taking the same amount of time. And it means, at least for this case, the size of your package really doesn’t matter.