Ask Questions and Find Answers

There is not a "mix of frameworks" really.

Metal is the lowest level, AUI sits on top of that and clay essentially refers more to material design than it does a Javascript framework. There is a minimal JQuery (to support Bootstrap).

But all of this script is necessary to support the interactivity built into the UI. You can't have interactive w/o Javascript. And sure, it is more JS than what you would need if you hand-coded the interactivity for a specific page and the necessary widgets that were on it, but Liferay uses its JS frameworks to support the widgets on any portal page.

I still find these kinds of arguments interesting. Yes, the first time load of a page is going to be heavy, there is no arguing about that. But the reality is that the browser is going to cache that and use it for all subsequent requests...  So sure, let's say the first page load does pull down 5.5 mb of data, but what is the measurement for the subsequent requests? I mean, does it drop down to 5k or something?  1.5m, that kind of implies that you have fairly large pages with a lot of portlets on them, possibly without enabling Senna, so it reflects more your own choices instead of a portal default of 1.5m per request...


I mean, I won't argue the first page size, there's no way around it, there is always going to be that hit. Even as the portal's JS changes (from the old Prototype to JQuery to AUI/YUI to Metal/AUI and maybe off to React or whatever other form it takes), the first page hit is going to be heavy.

But in reality no real browser is going to take that hit on every other page request. All browsers will cache those artifacts and reuse them, even mobile browsers.

So for me, the argument about JS download size, well it starts to lose water. It's a one time hit the first time a user hits your site. Ideally you'll have the minified version of the JS and it will serve from a cache appliance like Varnish. But you take that hit and all subsequent requests, including those from future visits from the same browser, they'll use the cache and not pull again. So for the level of interactivity you get, the dynamism that is supported across every portal page, that works without having to code up a React or other JS framework to make all pages so interactive, well that seems to me like a really small price to pay in the end.

Here are my results when loading simple page. There are apparently some optimizations in version 7.2.

+---------+----------+------------+-------------------------------------+
| Version | Requests | First load | Next load (utilizing browser cache) |
+---------+----------+------------+-------------------------------------+
|  6.2.2  |    30    |   0.4 MB   |     60 kB                           |
|  7.1.2  |    55    |   5.0 MB   |  1.300 kB *                         |
|  7.2.0  |    55    |   3.8 MB   |    350 kB                           |
+---------+----------+------------+-------------------------------------+

* High value caused by bug which prevented caching one 1 MB file (fixed in 7.1.3+)
In the era of fast Internet connection these 7.2.0 values seem to be acceptable, but comparing this with 6.2 it is a clear regression.
Seeing the high number of requests it is apparent the performance could be boosted by switching to HTTP/2. In old HTTP 1.1 protocol those 350 kB are fragmented into lot of small chunks which prolong the page load significantly.