Tridion Publishing is at the heart of a solid CMS implementation. When it works well, we don’t notice it. But, when it’s slow or there’s problems, we notice it really quickly. Most importantly, we sometimes don’t know why it’s publishing slow or how to improve it. In this article I explain a few of the common issues and give ideas of how to improve the publish times.

Problem: Pages stuck in the ‘Waiting’ state.
Solution: Restarting the Publisher service solves this most of the time.

Problem: Pages take a long time to publish
Solution: This is an interesting problem and there’s a few thigns we can do to try to improve the situation.

Template execution time
– Is it all pages or only certain types of pages that publish slow? What page and component templates are used on the slow pages? The developers can open those Pages (and templates) in Template Builder and see the preview times. Perhaps there’s a slow TBB or function on the pages? Or, maybe it’s possible to split the Templates into 2 templates and reduce the amount of logic within 1 giant template? Or maybe it’s the breadcrumb trail or navigation that’s taking so much time?

Developers can place timers inside these functions and templates and then in the staging environment writeout the execution time in an HTML comment at the bottom of the page. Years ago we did this for all of our templates to see how fast they were and to make sure new features didn’t slow down our publishing times. This helps identify the slower templates.

– Content Structure – Do you have a Component Link to a Component Link to a Component Link and then another Component Link? I call this ‘Death by Component Linking’. If so, this could be the cause of slower publishing.

While there are different approaches to writing templates, most of the time the Developer will use the API to retrieve the Component object in the Component Link. This is one of the slowest actions to perform in the API. Then, usually there is some logic and another Component is retrieved. It’s possible that through 1 Component on the Page the template is accessing 5+ other Components.

There is no quick fix for this – but with some Schema refactoring fields could be added to the parent Component and replace the Component Link field. This is possible when there are not many Components re-using the linked Component. Normally, if it is only 1 or 2 cases where a Component is re-used, and these are exceptional, then it would be advised to bring those fields into the parent Component.

Schema Design decisions are often made at the beginning of projects before the final content structure is known, and the definitions are usually left there and not refactored later when the actual content structure is known. With some small scripts and creative Content Porter usage the Schemas can be refactored, making Tridion easier to use and faster to publish.

Problem: Publishing large quantities of content is slow.
Solution: Add an additional publisher machine to this environment and enable it only during high load times (or keep it all the time). It can be configured to listen to certain publishing priorities, such as ‘Low’, ‘Medium’, ‘High’, or all. It can also be enabled only for specific publish targets. It’s important to know that the Publisher places a heavy load on the CMS it is installed on and also the DB. So, if you have a tiny DB server in the Dev environment, having lots of publishers could create some performance issues for the DB. But, in well large Production architectures it is often not a problem. The dedicated publisher is just another CMS instance with only the Publisher and Transport services enabled (and the CMS website turned off).

Problem: Pages with lots of images take a long time to publish
Solution: Publishing images transports them from the CM server to the CD server. This takes time, especially with large images. Are you using Tridion 2013? If so, you can consider moving your large images and videos to a Digital Asset Management system, and then move them out of Tridion and out of the Publishing lifecycle. All the time spent moving the images and PDFs will be removed from your publishing cycle. Check out the Tridion StackExchange question here for more info.

Publishing challenges are a side-effect of the distributed content architecture of Tridion, with Content Management and Content Delivery on separate machines and databases. There are many advantages to this architecture, one including the high-performance on your live website and also no worries that if you CMS backend has issues your frontend website is not affected. Another advantage is that your frontend website can run on either Java or .Net and also with the application server of your choice (more or less). However, we need to transport the content to Content Delivery – it’s not just a switch in the database as it is in many other systems. However, I think for large websites it is preferred to use Tridion’s approach of a distributed Content Delivery system even if we sometimes need to worry about improving publish times.

Author: Robert Curlette

Robert organizes the Tridion Developer Summit, likes teaching workshops on SDL Tridion, and helps customers implement solutions with SDL Tridion, DD4T, and Alchemy GUI Extensions. If you would like help, please contact me.