How to speed up publish time

This comes up from time to time, and unfortunately, at least for large and complicated stores, this is a recurring theme: how can you speed up the publish time of a Turbify?

For starters, a plain, "normal" store can average about 0.1 to 0.2 seconds per page (that's page generation during publish.) For highly optimized stores, you can get down to about 0.07 to 0.04 seconds per page. What does this mean? It means that during publishing, if you have a store with, say, 10,000 pages, that store should publish in 15 - 30 minutes, or if it's highly optimized, somewhere around 6 - 10 minutes.

So let's say your store's publish takes several hours or worse, what can you do?

Clean out unused files from the Lib

This is a relatively easy thing to do, although granted, this probably doesn't have a huge impact on your publish time - unless you have gigabytes of stuff stored in your LIB (the "Files" area in the editor.) When your store publishes, after all the content has been generated and everything is being pushed to the servers, so are all the files in your library. Since that storage is practically unlimited, we are used to just dumping files in there never to delete them. If you do this, then maybe it's time to look at that list and get rid of old and unused stuff. Simply click on "Files" and look through the list of files there. Delete old ones and those that you are sure you don't need.

As a side note, files in the LIB only affect publish time if your store is on the legacy LIB (and not on the CDN.) You can read more about this here: Turbify CDN

Eliminate unused global variables

This is another relatively easy thing to do (although not always!) Go through the variables page and delete those variables you are absolutely sure you don't need.

A word of caution: in case you delete some variable your custom templates depend on, you can go to the "Controls" page in the editor, and restore the entire store to the last snapshot listed on that page.

Go with a responsive design rather than adaptive

The fact that if you have a legacy (not responsive) store and with a click of a button you can make your site be mobile-friendly is huge (and if this is news to you, you can go to the Store Manager and enable "Mobile Storefront".) Google has been very open about their focus on mobile and the fact that non-mobile friendly sites will suffer on the SERPs. (The mobile storefront templates out of the box are really only meant for cookie-cutter, not custom stores. If you need to get those mobile templates in shape, we can help.)

But, if you have mobile storefront enabled, it means that for every publish, each page has to be published essentially twice: once with the desktop (regular) templates, and once with the mobile templates. While this probably doesn't actually double your publish time, at the least it adds quite a bit to it. So if you have a large store and you find that your publish time is very long, AND you have mobile storefront enabled, consider switching to a responsive design instead.

Reduce the use of WITH-OBJECT and FOR-EACH-OBJECT

Ok, now we are getting into the nerdy stuff.... In RTML, the ability to switch context to pages other than the current page is huge. This basically allows you (or your developer) to query any property of any page and make decisions or display things based on those properties. Essentially you can alter the hard-coded HTML structure of a page based on properties of other pages. For example, if a category page has any item on sale, you could display a banner announcing sale items within that category. Very easy in Yahoo, not so much with other competing platforms. But, this great functionality comes at a price: when we look at other objects (pages) from RTML, the publish process needs to do a disk lookup to find the referenced object and get the referenced information. Done once or twice it doesn't much matter, but if you do this many times for each page, the times add up. So try to limit this in your code as much as possible.

Try to use ONCE :publish as much as possible

If you do have to reference other pages (for example in the case of a global navigation menu), there is another great tool you can use in RTML: the ONCE operator. With this operator, you can have certain things be evaluated only once per page or once per publish. Once per page has its uses too, for example if you want to display breadcrumbs at the top of the page and at the bottom, you could "calculate" the breadcrumbs once and display it at the top and bottom without having to re-process it. But the big thing is ONCE :publish, which evaluates something only once during publish. This is now getting into pretty "heavy duty" RTML coding, but you could do something like the following to optimize your site's navigation structure:

TEXT ONCE :publish
          CALL :navigation    <- this would be the template that generates your global navigation bar.

Reduce the use of OBJID-FROM-STRING

One very frequently used operator is OBJID-FROM-STRING which takes a string, and then finds an object (page) whose id is that string. Because of how the RTML code interpreter is programmed, this operation is very "expensive": it takes the string you give it, then it starts to look up all of the objects (pages) in the store from storage, and compares each page's Id to the string provided. If a match is found, it immediately returns the matching object, otherwise it continues until it is done checking all the objects. You can probably tell already how slow this can potentially get: doing this on every single page, especially if there is no match, and if part of a look (like related items whose ids are stored in a text field), this can bring a publish to its knees.

The best thing to do is for any variable or property that holds ids of pages (for example best sellers, or cross sells), to use a field of type "references" rather than "text". With a "references" type field every Id in that field can be directly referenced to the corresponding page without any time delay, as opposed to trying to match a text ID to the actual ID of a page.

Limit the use of deep recursions

With RTML, you can relatively easily create category pages that would list not just the category's contents , but the contents of those categories, possibly going as deep as you want to. This, however, not only makes heavy use of WITH-OBJECT and FOR-EACH-OBJECT but can also "confuse" the publisher process in that it will always tell you that a full publish is required whenever you try to publish changes only.

"Utility" or "feed" templates

Finally, if your store relies on utility or feed templates - templates that tabulate data for outside processes, such as shopping feeds or similar, those can potentially take a long time to process, especially if your store has thousands of pages. If you have such templates, re-evaluate them to see if you still need them all, and get together with your developers to see if they can perhaps be combined (if you have multiple such templates.)

Clean out old, unused pages (products)

You can optimize the templates, data, files, etc., but the bottom line is, if you have a huge store (tens of thousands of pages) then it will take time to publish no matter what. However, carrying around "dead wood" is not advised even by Google. Back in the days, conventional wisdom was to never delete pages because they "add content" to the site. This is no longer the case, as today relevant content is king. After all, what's the use of having a product page around if it was a product added to the store 2 years ago and you never sold any of it? Or an item that is no longer in production. So look at your stats, and eliminate all the pages that don't generate revenue or quality traffic.

If you do have a publish problem and would rather have a professional look into it, let us optimize the publish time of your Turbify.