I understand DD4T setups add Experience Manager (XPM) markup (page bootstrap, Component Presentation markers, and field details) in the MVC Web Application. JSP views might reference an <xpm:> tag that is converted to XPM markup.

My architect on a client project (DD4T Java) is asking if we could improve rendering performance by not having rendering this markup in XPM.

The idea would be adding these details on Publish (Tridion template) rather than during rendering (in Content Delivery), similar to the SiteEdit Template Building Block, which detects the publishing environment and renders XPM markup accordingly.

But with Tridion publishing JSON independent of the HTML layout, I'm not sure this would fit within DD4T.

Any suggestions? How do you improve performance for DD4T rendering with XPM tags?

2 Answers 2


We are thinking about something similar with our implementation where we do not want the SiteEdit calls in the razor views in the non-staging environments. We also use DD4T. There is not an easy way to achieve the same AFAIK. Couple of ideas, I am considering:

  1. Have different set of razor views for staging vs non-staging environment altogether. This one is costly to maintain/manage since there will be updates that will need to be done at 2 places for any change to the razor views. But, it is very clean in terms of segregation and the changes can be automated via source control for the views to flow from one to the other.
  2. If the razors views are being published through Tridion, then strip out the SiteEdit calls. One way to achieve this is by adding a custom tag like <abc> around the sitedit calls in the views and during publish, figure out to which target it is going, if staging keep those calls, if not remove it. This way your views will be completely clean depending upon which environment it is going. It is not as straight forward as I described since the developers need to be diligent in doing that

If you find better ways of handling it, please share :)

  • The automation via source control makes the first option a bit better--we didn't want two separate sets of views. For the second option, how would you handle the views in Tridion? Would they be Components, pages (with Components on them), or published as binaries? Commented Jul 24, 2015 at 3:29
  • 1
    They are DCPs in Tridion. Commented Jul 24, 2015 at 16:43
  • Our architect was interested in the source control-to-generated views approach. +1 from earlier and accepted, thanks Vipin. I'll update if I'm around when they update the approach. Commented Jul 24, 2015 at 17:59

DD4T java example site uses the siteeditsettings bean (defined in siteeditsettings.xml), which is wired using a spring context. If you set its enabled flag to false, the dd4t support code stops outputting XPM markings (it always returns an empty string). You only need to make sure you have a different xml file (or property injected) between your environments to hide the JSON markings on live then.

Performancewise, all these do is write in-memory object properties out to the response stream. You won't save much actual performance, only output size of the HTML.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.