SSI for header / footer in AEM - Any issues ? | Community
Skip to main content
Level 4
October 16, 2015
Solved

SSI for header / footer in AEM - Any issues ?

  • October 16, 2015
  • 13 replies
  • 6660 views

Hi,

 
We have developed separate component for managing header / footer. This component / template generate JSON which has header / footer markup. We have some other parties which needs this header / footer so created JSON for easy consumption.
 
For example:
 
{
 
headerDiv : <div> header div here </div>
footerDiv : <div> footer div here </div>
 
}
 
We read this JSON back and add the headerDiv / footerDiv / css / js to the AEM page. So now if we have 10K pages each time there is change in header / footer - then cache clear of all these 10K page needs to be done. This is because headerDiv & footerDiv are part of each page.
 
So thinking to implement SSI for header / footer includes so that if header / footer changes it will start automatically reflecting on all pages.
 
So wanted to check advantages and disavantages of SSI with this group:
 
1) Will there be any performance hit in page load time using SSI ? (now there will be 2 additional SSI calls)
 
2) Is it the case that if header SSI is slow then body will load and page will be without header. Now same page without header is cached in Akamai for sometime. Is there any way to resolve this ?
 
3) Has anyone followed this approach before ? Any other thing which i should consider.
This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by joerghoh

Hi,

I understand your scenario. When you want to have your header and footer files included, you should have them also reachable by the dispatcher.

Internally mod_include does not access files directly, but starts sub-requests. The dispatcher is hooked into these requests as well (they are normal requests) and is able to fetch the requested files from publish. Only when these files are available, the mod_include can continue and insert the files into the "main" file. So I don't understand how you encountered this scenario. Can you reproduce it without Akmai? If it's a conceptual problem you should see it even with a regular browser directly hitting the dispatcher.

That's the way how I have seen it implemented at least once and it worked very well.

kind regards,
Jörg

13 replies

Level 2
November 29, 2016

Hi Rohit

The entire thread was an interesting read till it ran into a bummer without a technical closure or reasoning. 

Would you care to share your findings  as well ?

Regards

Joseph

December 8, 2016

Hello,

I have recently implemented SDI based header and footer in my project. And everything looks good. But I wonder is there any way I can avoid hitting AEM publish/author to construct the HTML markup for header/footer. As per the documentation and per the great minds thoughts in this thread, I understand that there won't be much impact on the performance, But I still feel if there is way to avoid hitting AEM. Please note, I am referring to the synthetic resources.

[Updated - ]

I have followed this route - <sly data-sly-resource="/content/appname/en/jcr:content/heaedernavbar.html"></sly>

And I can see the following tag in cached file in webserver doc root - <!--#include virtual="/content/appname/en/_jcr_content/heaedernavbar.cache.html" --> 

I can see heaedernavbar.cache.html getting created at docroot/html/content/wegmans/en/_jcr_content location. 

Hope this way, I can have the cached file at a central location and using the ACS commons dispatcher flush rules in the OSGI configs I can flush the cache when needed without having to worry about entire content of the site. Please suggest if there is any other better solution. 

Thanks,

Suresh

venkatan9774121
Level 2
March 20, 2017

Hi Rohit,

Whats the apache config which you have updated for this?

 Thanks,

Pradeep