Liferay 6.2 css / js within templates

[9年前 に Traolly Xiong によって更新されました。]

Hello All,
Currently we are coding templates (ftl) to render web content within web content portlets and while using css / js within the templates for quicker coding, testings/ debugging purposes, we're thinking what is the best rule as to when to keep the css / js within the templates vs. moving them out to the theme (main.css / main.js) OR into their own external files? Which method or other methods would be best practice and/or recommended for better site performance?

Any thoughts are fully appreciated.

Thanks.

[9年前 に Ravi Kumar Gupta によって更新されました。]

Usually, a production code should not carry js/css in templates but should be in css/js files. This is done so that browser can cache the files and improve the page load time. Also, sometimes you would want to host your js/css files from a cdn. In that case if you have inline css/js you won't be able to get benefits of using a cdn.

You should be able to find many liferay performance improvement tips blogs. A google search should help you more to understand what exactly you should follow.

[9年前 に Traolly Xiong によって更新されました。]

What you are saying makes perfect sense. I am aware of how CDN works and the benefits of it.
I guess my question is more of do I make the js / css external file(s) requests from within the templates
when a user actually wants to render that web content on a page OR do I request it from the theme on the
initial page load of any page that uses that theme?

There are it's pros and cons of course. For an example, I can see that loading unnecessary js / css files from
the theme could take a performance hit as some web content on a page may never be visited by a user.

Any thoughts?

[9年前 に Ravi Kumar Gupta によって更新されました。]

Sorry.. I misread before.

For the contents, There can be multiple options optimized as per your requirements. You should see and compare what is the best fit.

If there are many web contents which are going to use same javascripts and css, you could put them to theme/cdn since they will be cached once and then it would be faster when viewing a web content.. of course because css/js are preloaded and cached by browser.

The thing is.. using Page level css/js, css/js in the templates must be the last place to look into. I guess.

[9年前 に Traolly Xiong によって更新されました。]

Hello Ravi / others,
Few questions.

1) Should scss / css be included in main css or should some BE requested in the theme separately? Is there a file size limit where we would want to
BREAK them out into their own external file and request them separately? Would the same concept apply to js files too?

2) I've run into some issues with jquery doc ready not waiting for the portlet to fully render before executing. Anyone see this issue and what do you recommend to getting js to execute properly after page has fully rendered including portlets etc?

Thanks.

Traolly Xiong

[9年前 に Ravi Kumar Gupta によって更新されました。]

I don't think size matters there.. css is going to be plain text.. would not exceed KBs, however do try to minify them as they grow.

document.ready should work but if that's not working, give other solutions a try. See if these work for you. https://www.liferay.com/documentation/liferay-portal/6.0/development/-/ai/javascript

-Ravi

[9年前 に Traolly Xiong によって更新されました。]

Hello ,
Thanks for the reference link. What do you guys think about this, if you had a bunch of js / css that is only applied to web content templates, would you still load them on 1st attempt with the main css / js knowing that there's a chance those styles nor js will ever get used if the user never hits those pages (where content renders)?

Let me know your thoughts.

Thanks.

[9年前 に Ravi Kumar Gupta によって更新されました。]

I would load those js/css when the web content page is hit.. not when Liferay is first loaded. Load when demand.

[9年前 に Traolly Xiong によって更新されました。]

So you're saying that it's best to load the external css / js when the page is hit, correct? So if you have web content portlets on a page
with 10 templates triggered, there will be at most 10 css and 10 js files requested. I understanding this correctly?

Thanks.

[9年前 に Ravi Kumar Gupta によって更新されました。]

Recalling your words that.. that is the only page where these js and css are needed. Also, it may also happen that user may not come to the page at all.

So, yes, I would load on demand only. For this one page, I may, however, think to merge all the css in one file and all js in one file and include those two only on that page. Just to make sure that instead of 20 requests (10css+10js), Page makes only 2 request. That will save a good amount of time.

[9年前 に Traolly Xiong によって更新されました。]

Yes that make sense if one knows the exact web portlets on the page. I'm speaking more from a general approach / method.
For example, the content editors will create / updated web portlets of their desire so it only make sense to keep the js / css to the respective
templates. Is there some kind of way to combine the css / js files at compile time with multiple templates (web content portlet) on a page?

What would you do as a general approach if each of your templates uses it's own js / css?

Hope this make sense.

Much thanks.

[9年前 に Olaf Kock によって更新されました。]

My approach is "it depends": For short term changes, templates and content styles are ok. As soon as they're stable and blessed I have a tendency to move them to the theme. This tendency is really strong for the main pages, that constantly get hit. It's weak for a long tail page - especially if it's just one of the long tail pages. And in between it might be one of those temporary solutions that live for years.

Another thing that it depends on is the overlap between your theme-team and the content editor/template editor team: If you're a small team, people most likely care for changing things in "the right" place. If you're getting the theme thrown over the wall from a design company and nobody ever dares to touch it - embedded styles are the only way you get extra styling into your site ever. If you have daily deployments and continuous integration in production, you probably can embed new styles in the theme easily. If you deploy twice a year - don't bother taking care of separating out CSS from your content.

[9年前 に Traolly Xiong によって更新されました。]

Hello Olaf,
Thanks for the response. What you said about styles, would you agree the same applies to js as well?

In respect to performance, we would want to load all css / js in the theme so it can be minfied / combined and cached on 1 load, but it may cost a possible performance impact if there are lot unneeded css / js in the theme on that 1st page hit / download.

I know we get the minify / combine feature if it's in the theme vs. the template (inline, embedded / separate downloads), but for the sake of loading on ondemand (only when needed), should we consider moving some styles / js to the template with the premise that we currently have weekly deployments.

Thoughts?

Much thanks!

[9年前 に Olaf Kock によって更新されました。]

Hi Traolly,

indeed - "it depends" applies to JS as well ;)

I'd use the same criteria: Quickfixes and Long Tail pages get different treatment than highly utilized Landing Pages. Sometimes, solutions are really local. Let me give you an example: Look at the Radio Liferay homepage. You'll find some inline script and css on that page: There's an audio player which just exists on that page (JS) and not in the theme. Also, one of my old hacks has survived - the second AssetPublisher on that page (under "Older Episodes") shows "the latest 20 episodes without the very latest" - which isn't an out-of-the-box option. The surviving hack is a simple CSS rule:

#portlet_101_INSTANCE_Q7Ic .asset-abstract:first-child{ display:none }

Nobody bothers to add this to the theme, because it's only relevant to that page. It's a hack, not even 100% correct any more, but it's there. And it's just embedded on the page - a technique that I actively discourage unless it makes sense. In this case, the options were: Patching Assetpublisher or this CSS line. Guess what my chances are to deploy a modified AssetPublisher on www.liferay.com. I didn't even try it - they're probably zero.

In general: As soon as the audio player would also be used on different other pages, it probably should be moved to the theme (either the JS or the CSS or both). In this case there's probably not much value in promoting it up a level.