Level 4

Solved

SSI for header / footer in AEM - Any issues ?

13 replies
6683 views
Translate

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.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

joerghohAccepted solution

Employee

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

venkatan9774121

Level 2

Hi Rohit,

Whats the apache config which you have updated for this?

Thanks,

Pradeep

Translate

S

Suresh_Ravuru

New Participant

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 -

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

Translate

J

josephabraham

Level 2

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

Translate

joerghoh

Employee

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

Translate

K

Kanwaljit

Level 3

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

Translate

R

rohitspathak123Author

Level 4

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 ?

Translate

joerghohAccepted solution

Employee

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

Translate

Kunal_Gaba_

New Participant

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.

Translate

R

rohitspathak123Author

Level 4

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:

Translate

smacdonald2008

Level 10

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

Translate

Show more replies

Sign up

Login with SSO

Login to the community

Login with SSO