Remove Barebones.jsp

[Timothy Bassett, geändert vor 9 Jahren.]

We recently relaunched our website onto the Liferay framework. The issue that I am having is with this barebones.jsp file. It's causing render-blocking blocking issues in every browser (ie: the website waits until it has loaded). Its a very slow framework. We don't use this library on the front-end and I would like it removed but our developers are saying that it cant be removed.

How can it be removed?

[Pier Paolo Ramon, geändert vor 9 Jahren.]

Your engineers are not wrong at all. Removing it would cause a lot of issues. Barebone-ing is the process of compressing a concatenation of JS files. Usually it doesn't pose a real performance drawback. The files it loads have to be loaded anyway.

Sent from my iPhone with Liferay.com Forums

[Timothy Bassett, geändert vor 9 Jahren.]

Actually, it has a big impact on load time. When I run Google insights on our new site, it identify that script as a render blocking script. Which does cause issue because at time our website will load the just the header part and nothing else and eventually it will load. However, if I hit the ESC key, it will instantly show the page.

[David H Nebinger, geändert vor 9 Jahren.]

Barebones is responsible for loading the portal core in the browser. In as such it pulls in all of the js libs, etc.

It cannot be removed.

That said, it is possible your developers did something inadvertently which is delaying the loading of this file.

[Timothy Bassett, geändert vor 9 Jahren.]

Why does Liferay require assets to be included in the HTML output when we are not using them? It seems a little odd that a framework would force the usage of certain assets on the front-end output when the website loads. I have never known a framework to have such a limitation.

[David H Nebinger, geändert vor 9 Jahren.]

Because there's a price to be paid when you move things from the theme to the portlet (a performance penalty because at render time the portal has to aggregate all CSS and JS resources used by the portlets on a page, etc.). Of course they could strip out portlet-specific JS/CSS but then the performance of the whole portal suffers.

Right now it is tuned to minimize the amount of time it takes to render an average page of OOTB Liferay portlets, as that's probably the 80% usage point; the 20%, those that don't or won't use the OOTB portlets (I've done some sites like this), well they have all of the extra JS/CSS to feed back, but after that the penalty is paid in the browser, not necessarily on the server.

Liferay's whole system of dropping portlets on a page and they just work, well that's because the JS/CSS that manages the look and feel have already been loaded by the surrounding theme. Removing them from the theme breaks the live dropping of portlet concept; between the two, they lean more towards that functionality than trying to minimize barebones.

All of that said, it is possible to whittle down the included JS/CSS once you know what you're doing with your portal. You can create your own theme that removes all classes for portlets that you're not using, you can get into barebones and strip out the JS for pieces that you're not using, ... The problem is that this must be approached with a surgeons' care; whacking at it with a machete will result in a broken portal.

[Timothy Bassett, geändert vor 9 Jahren.]

Not having control of the final output is a major flaw in any framework. Personally, I am speaking as the Product Manager and not as a developer. I have never worked on a project before were I was being so heavily restricted on the final output.

Since launching the new website, our conversion rate has taken a hit and we are getting inconsistent results with our conversions when historically we have very consistent conversions especially during this time of the year which is historically higher than normal performance.

The items mentioned in this thread regarding the benefits of Liferay are support by our Business Systems Manager (who selected this framework for us before I joined) appear to be a limitation on our website.

One of the key issues that we are having is on the front-end load which is being impacted by the barebones.jsp script. We recently applied the async attribute on this script which appears to resolve the issue but in Chrome we are getting a double loading issues where the website will load, disappear and reappear. It only happens in Chrome and no other browser.

[Traolly Xiong, geändert vor 9 Jahren.]

Hello David,
From reading online, I found that we can override the barebone.jsp bundle in the properties-ext file. It would seem to be a global change, but can you confirm if that is true or can this be done for a specific site / theme?

Sounds like you do NOT recommend going down this route as it could break portal. Any tips on how we can filter out some of the js files within the barebonse bundle to make it lighter and optimized for the first page hit? My understanding that we can cache the "barebone.jsp" file and so the first hit is really the only concern we have as it will block / other requests / slow down the page load.

On the live site as a guest, I don't think there is any dropping portlet use cases, so with that said, can we remove those needed js and also the %20 percent that don't / wont' be used for OOTB portlets via the method you may recommend?

NOTE: Can you provide an example of what classes you are referring to when you previously stated "You can create your own theme that removes all classes for portlets that you're not using....."?

Thanks in advance. Any help if fully appreciated.

Traolly Xiong

[David H Nebinger, geändert vor 9 Jahren.]

Traolly Xiong:

From reading online, I found that we can override the barebone.jsp bundle in the properties-ext file. It would seem to be a global change, but can you confirm if that is true or can this be done for a specific site / theme?

It is all or nothing and is a portal-wide change.

Sounds like you do NOT recommend going down this route as it could break portal. Any tips on how we can filter out some of the js files within the barebonse bundle to make it lighter and optimized for the first page hit? My understanding that we can cache the "barebone.jsp" file and so the first hit is really the only concern we have as it will block / other requests / slow down the page load.

Barebones has all of the JS used by the portal. Chopping away pieces ends up chopping away functionality from the portal. Much of the functionality that you would keep has dependencies upon some of the JS that you might want to ditch.

So most of the time the issue w/ Liferay serving up these resources is that it is expensive for Liferay to do. And the reason is not just because you're using a java-based application container or that barebone.jsp takes a long time to render, there's just a lot of server filters, etc., that Liferay injects in every incoming request, some of which isn't necessary for a mostly static resource request.

Rather than trying to figure out how to trim down barebone.jsp, I would encourage you to look at a caching appliance such as Varnish. Varnish is a caching proxy which can cache resources but one that is dynamic in what it caches. You don't have to specify patterns, you don't even have to specify lifespan, it's really just a matter of dropping it in and it will handle these kinds of resources. This kind of thing will greatly impact your Liferay system performance because it offloads much of that content serving from the app container to the caching appliance.

On the live site as a guest, I don't think there is any dropping portlet use cases, so with that said, can we remove those needed js and also the %20 percent that don't / wont' be used for OOTB portlets via the method you may recommend?

Well, you can certainly try, but like I said there will be a lot of dependencies in there that may make it difficult to slim down. Liferay did call it barebones because they feel it's the minimum amount necessary for a working portal. Like I said, though, Varnish or some other caching proxy will serve you much more than trying to slim that further.

NOTE: Can you provide an example of what classes you are referring to when you previously stated "You can create your own theme that removes all classes for portlets that you're not using....."?

Well, you can't really remove the classes, but you can remove the styling. Liferay typically does a good job of reusing classes in the portal, though, so the portlet-specific stuff is not as big and verbose that you might think. To find the styling though, look for the css wrapper classes defined in liferay-portlet.xml from ROOT.

For example, the portlet name 20 is for the doc lib and it uses a specific class, "portlet-document-library" for it's css wrapper. So you can do a search for that class from your constructed theme and, if you weren't using doc lib portlets, could whack styles bound to that class (you'll probably find most of the references in extras.css). But I think you'll find in this search that the actual reduction in size of the returned css is really going to be counted in bytes, not KB or MB or anything like that.

But again, a caching proxy like Varnish would serve you better for these than trimming the CSS files to remove a few bytes here or there.

[Traolly Xiong, geändert vor 9 Jahren.]

Thank you for your prompt and useful response. I'm sure others will find your post useful as they come across the performance phase of their projects.
We currently have a CDN, so we'll definitely want to cache the "barebone.jsp" and "everything.jsp" on the regional servers (help optimize 1st page hits) and locally (subsequent requests).

Couple of follow up questions if you don't mind.

1) Aside from caching the "jsp" file, what are you thoughts about making the "barebone.jsp" / "everything.jsp" files asynchronous like what Timothy Basset did by adding the "async" attribute to the script tag within the "top.jspf" file? I tried that but I am getting some errors. Before I debug further, I would like to know your thoughts.

2) I assume allowing caching for the "/combo/?" servlet bundle js files will be okay to do as well, correct?

2) What are you thoughts on if we wanted disable the notifications portlet css / js (maybe the "portlet/journal_content" also) from guest users? Or is that not a good idea to do.

Much thanks.

[David H Nebinger, geändert vor 9 Jahren.]

Traolly Xiong:

1) Aside from caching the "jsp" file, what are you thoughts about making the "barebone.jsp" / "everything.jsp" files asynchronous like what Timothy Basset did by adding the "async" attribute to the script tag within the "top.jspf" file? I tried that but I am getting some errors. Before I debug further, I would like to know your thoughts.

Well, as a developer/architect, you typically build that into your plan and therefore when you're coding JS dependencies you take it into account, wrapping all of your JS to protect against an async resource not being ready.

However, the errors that you're running into basically expose how the portal core was not architected to support the async delivery of barebones and everything. Not knowing what version you and Timothy were working with, well it's hard to say why he might have been successful while you're facing these errors. I'd tend to believe he was on a different version and that's the source of his success. But it could be any number of things such as different portlets used on the pages, custom theme differences that affect behavior, ...

2) I assume allowing caching for the "/combo/?" servlet bundle js files will be okay to do as well, correct?

Well, not sure. I use (and recommend) varnish for caching so that you don't have to worry so much about individual pieces are doing.

3) What are you thoughts on if we wanted disable the notifications portlet css / js (maybe the "portlet/journal_content" also) from guest users? Or is that not a good idea to do.

Well, notifications are probably not going to guests anyway. But journal content is the web content and those are most likely used to show content on the page.

[Timothy Bassett, geändert vor 9 Jahren.]

I understand the need for barbones as a server side tool to call the portlet. I dont understand the need to have it run on the client-side since it creates a huge bottleneck when rendering the page.

We tried the async attribute on the script but it caused issues with other Scripts used to render the website especially with IE.

In the end, we leveraged browser cache and cached the barebones.jsp in htaccess. While this didn't help new users, it did improve the performance for our returning users and overall, we saw an decrease in page load overall.

The page load for new users is still much higher on the new Liferay website but we are experiencing an increase in avg. number of page views and the additional load time is only on the first page of the session.

One of the items that I don't like with Liferay is how we have little control over what is being outputted to the client. Our front-end should be bottlenecked for libraries to load which are not actually used on the client side.

[David H Nebinger, geändert vor 9 Jahren.]

Timothy Bassett:

I understand the need for barbones as a server side tool to call the portlet. I dont understand the need to have it run on the client-side since it creates a huge bottleneck when rendering the page.

Well, the whole interaction of the portal is totally based upon javascript - it is truly a live dynamic thing. It enables the web content to handle things such as carousels, handles the presentation of dialogs (should a page need it for guests), handles the navigation (drop down) menu, etc.

That said, I know it is going to be heavier than what most folks actually want on an unauthenticated side.

The issue is really Liferay's support for the entire audience, the many, not just for the few. So you can imagine the struggle that they must face for every decision - do we add support for notifications or not for unauthenticated users? While you might answer "no", others might answer "definitely". Then it comes down to (I think) a question of simplicity - if they leave it in, it works for both groups (the "no" folks just have to pay the price of including it in downloads). Over time, I think dependencies start to sneak in so even if there is no direct usage of a piece of JS there may be a dependency that requires it to be included.

So sure, there does tend to be stuff in the portal (CSS, JS, portlets, etc.) that you don't need, but they didn't build the portal for you alone, they built it for everyone, including the folks that need those things.

I know it's not what you want to hear, I'm just explaining why it is what it is (and note this is not an official Liferay statement, it's really more of my opinion and interpretation of why things are in there that even I don't ever use).

We tried the async attribute on the script but it caused issues with other Scripts used to render the website especially with IE.

I was surprised when I read that in the thread, I didn't think it would work.

In the end, we leveraged browser cache and cached the barebones.jsp in htaccess. While this didn't help new users, it did improve the performance for our returning users and overall, we saw an decrease in page load overall.

It's why I also suggest using a tool like Varnish. Liferay can still render the JSP (so it is still dynamic), but it is later cached in a layer that would not require passing back to Liferay for reevaluation. The .htaccess works too, I'm just not sure if it has the same kind of controls over expiring content like Varnish has.

The page load for new users is still much higher on the new Liferay website but we are experiencing an increase in avg. number of page views and the additional load time is only on the first page of the session.

The fact that you are still building for each session would still seem a little disturbing.

One of the items that I don't like with Liferay is how we have little control over what is being outputted to the client. Our front-end should be bottlenecked for libraries to load which are not actually used on the client side.

Well, that's been a gripe for a long time. A lot of the OOTB portlets no one uses (dictionary? amazon rankings? currency converter?), but there was really no way to safely trim this stuff down. 6.1 and 6.2 have been better in that many of the extras for Liferay were packaged as separate plugins and put into the marketplace so your portal would not have the plugins unless you wanted them, but it still ends up being fatter than what many folks want or need.

The good news is that 7.0 is on the horizon, and it will truly change everything. 7 is based upon OSGi and will allow for the removal of components which you don't need, effectively trimming the portal down to just those parts you do need. This is how it will work on the portlet level, but I'm not sure yet how that will impact the CSS and JS the portal uses to wrap everything (I haven't explored it enough to know if dropping the currency converter portlet would also remove any JS/CSS that it needs from the output from the portal or whether it just removes the code and leaves the removal of CSS/JS to the theme.

[Traolly Xiong, geändert vor 9 Jahren.]

Thanks for commenting the 3 questions. We may just have to live with the "barebones.jsp" and "everything.jsp" not being filtered and first page load hit, and leverage the caching for subsequent page hits

On #3, even though the notifications js / css are not needed for guest users, they are still being downloaded in which affects the 1st page hit. It get's tricky if we have to go into the include jsp files within Liferay to add logic to load certain js / css only when needed (via hook).

Let me know if you think that is worth doing.

Thanks.

[Juan Gonzalez, geändert vor 9 Jahren.]

Timothy Bassett:

Actually, it has a big impact on load time. When I run Google insights on our new site, it identify that script as a render blocking script. Which does cause issue because at time our website will load the just the header part and nothing else and eventually it will load. However, if I hit the ESC key, it will instantly show the page.

What header is only being rendered? Your page? The script?

Can you check through Firebug or Chrome developer toolbar if all resources for your page are being obtained properly (http code 200)?