SSI for header / footer in AEM - Any issues ?

[rohitspathak123]

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>

css : http://path/to/css

js : http://path/to/js

}

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.

[Jörg_Hoh]

Hi,

1) When all parts of the page are cached, the performance impact of SSI is nearly zero. Normally negletctable.

2) Yes, there is a way: If the header.json is static (that means, it's not personalized), turn it into a HTML snippet and cache it on the dispatcher as well.

3) Works perfectly well. Especially if you can cache all parts on webserver, but also drastically reduces load if you have a static header/footer  (including navigation) and a more dynamic main part of the page.

Things to validate:

• Your developers need a correctly configured webserver plus dispatcher in fron of their local development systems. Otherwise it causes friction when parts of the site do not work, causing trouble and dirty workarunds, and in the end the whole feature doesn't work properly because of it.
• Do you really change header and footer that often, that it justifies this?

kind regards,
Jörg

[Kanwaljit]

Remember - SSI is different from SDI

In one of the projects, we have relied heally on SSI and it works like a charm -:)

The one thing that will change from traditional approach v/s when you are using SSI is that you will now have a page which will be built using SSI e.g. header.html (or header.json in your case)

You will build a page that will just render data using a component. This component is either cq-include(ed) or dropped from side-kick. The upside is that once this page will be cached in dispatcher and if-required, CDN too (I personally don't have experience in SSI with CDN though). The call will be made from apache who will translate the SSI include and make the page call.

Instead of worrying about it being slow I think look at the USP for this approach is that we don't have to blow the cache for the entire site whenever we change single page. Anyways, the additional call is the first time when the page(header.html) is not there in dispatcher. All following calls to this page will be served from the cache. Note that the page is cached separately

HTH

/KS

[rohitspathak123]

Hi Jorg & all,

Thanks for taking time to reply on this quickly. Reading through all the comments i do not see any issue you guys faced while using SSI. 

I have follow-up question:

We have Akamai configured for our main pages (which will inlcudin this header / footer using SSI). Akamai TTL is for say 24 hrs for the main page.

Following scenario we observed :

1. Delete complete dispatcher cache (completely empty)

2. Now try accessing the main page (which will have SSI for header / footer)

3. We see that header / footer section are BLANK on that page (we can see other sections)

4. And now this main page is cache on Akamai for 24 hrs with header / footer area BLANK. Now this bad page has to sit in Akamai for 24 hr before it can be refresh from dispatcher again

Our Analysis:

1. We observed that if we try hitting the dispatcher directly to load our page then when dispatcher cache is completely clear then on first page hit header / footer section is BLANK . Because in this case header / footer HTML was not present on dispatcher and it went back to Publisher to get it. But the main page did not waited for this activity (header / footer HTML from publisher) to complete and it proceeded to process other part of page. So now we have page without header / footer at first hit. 

2. When we refesh same page 2nd time then now by this time header / footer html is already on dispactcher . So now we see the header / footer on this page

Have you guys observed similar behaviour with SSI include on page ? Is there anything wrong we are doing with they way we are including SSI on page. Will SDI help here ? Is there any way I can wait for first the header html to load before loading other parts of page to make sure that my page has header / footer & body ?

[Jörg_Hoh · Accepted solution]

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

[Kunal_Gaba_]

Sorry to ask you now. As per your use case you created JSON representation for header and footer as it was to be consumed by some other third parties. And in your main site you included this header and footer as JSON.

Why you did not create two views of the header and footer components using sling selectors ?  In your main site you could have used the JSP view and included it on all the pages using iParsys. And in your JSON would just have been invoked by adding a selector in the URL by third parties. This would not require you to clear cache of 10000 pages or use SSI. Just adding my thoughts,  though I don't know the full context of the problem. 

[rohitspathak123]

Hi Jorg / Smacdonald,

Thanks for your reply.

I am facing a small issue now. When I use SSI include on my parent page (which includes SSI for header / footer) on first hit of parent page there is no call made to SSI child pages. So header / footer section is BLANK. I checked in dispatcher.log too and I donot see any calls made to child html. But if I refresh the parent page then header / footer comes fine. Just wondering if you guys have seen this issue before. I think there is some setting on my dispatcher.any or httpd.conf which might be causing this behaviour.

For your reference below is the directive i am using:

<!--#include virtual="/path/to/child/header/footer/html" -->

[smacdonald2008]

Exactly - a Joerg pointed out - there is no advantage to using SSI in AEM. Sling should be able to handle your requirements. 

[Jörg_Hoh]

Hi,

please enable debugging on the mod_include and post the logs for the first request, when the header is not included.

kind regards,
Jörg

[rohitspathak123]

Thanks Jorg for quick reply. Will share the debug logs.

One observation i saw today:

1. Clear complete dispatcher cache & try accesing the parent HTML. In this 1st hit the SSI section (like header / footer) is missing. But if I do view source of parent HTML then I see that <virtual> directive

<!--#include virtual="/content/header.html" -->

2. When when i refresh parent page again then this <virtual> directive is gone and replaced by actual header <div>

Does this gives any clue. What i am thinking is on 1st load of page it just keeps <virtual> directtive as normal html source. And on 2nd refresh then it processess it.

[rohitspathak123]

Hi Jorg,

Thanks for all your input. Wanted to give you update that now the SSI include issue is resolved. We had to update the apache config to make it work. Now on first parent page hit itself SSI child gets included.

[josephabraham]

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

[Suresh_Ravuru]

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]

Hi Rohit,

Whats the apache config which you have updated for this?

 Thanks,

Pradeep