Hi,
The only builder which does this right now is Zion Builder. It will not load any javascript by default unless you use some feature related to it. For example a blank installation of Zion have zero js loading on the frontend. Then it will load function specific js per page as you use the functionality. So all the js there are split into bundles.
What are your experiences with Cwicly?
How can they improve?
Hi Marius,
There are only few builders in the whole wp community with focus on performance inspite of so many competent developers and large teams. Very sad unfortunately. Pinegrow, Zion, Bricks, Cwicly & Greenshift are top tier in terms of Performance imo. It was Oxygen who started the trend and set example for the WP community. Oxygen is a legacy product so I won’t talk about it.
Cwicly is doing all the right thing. It’s coded with performance in mind, follow the best practices, it’s based on Gutenberg which itself will keep improving with time in terms of performance, it does not have extra wrappers anywhere except the section block. It is also going to introduce dynamic id and class. So only id & style will be generated when you need it. DOM depth is perfect. There is no over css or js used. No css duplication. Filters block cache the query into transient I think? I am yet to test the filters. Will do later.
I feel only thing left for Cwicly to improve the performance in terms of front-end output is break the js into bundles for dynamic loading and remove the extra wrapper for the section block. After that all the user need to do is to add caching - page & object caching depending on their visitor load on the site.
I have noticed that a file called ccers.min.js is loaded on the fresh installation. It’s 44KB in size before gzipped. I am yet to check the file in through but it seems to be loading animations and scroll animations. I feel the contents of the file can be split and should be loaded only if we are using those animations. I did not test the css files as the sandbox runs an older version and I know that the newer versions remove many cwicly default css. So will test once the sandbox gets updated. I had a license before but I took refund and went to Bricks. Now I am reconsidering Cwicly after the recent developments and due to Louis insanely fast update cycle. Some times it feel unreal.
Thanks for your feedback @dranzer.
You are right, optimization becomes more and more important nowadays and people are explicitly looking for tools which can meet this basic requirement.
You mentioned the Section Block “extra wrapper”.
This wrapper is required and can’t be removed.
You could build it by yourself, but you’d require 2 Div Blocks, so the HTML structure is identical.
If you think there is an unnecessary wrapper involved, just grab a single Div Block and go that way.
Cwicly, in general, does not add extra or unneeded stuff, as you already mentioned.
This is how Cwicly works as well.
Just add a block which requires JS, for instance the Modal Block and check which files are loaded before you place the block and after you place it.
It’s all separated.
This file contains minor stuff like Tab and Accordion code or headroom.js
Can this be improved? Sure, it could.
Should it be seperated into individual files?
At least, there is room for improvements and fine tuning but one should also have in mind that this will lead to more requests on page load.
I’d take rather the current way than 5-8 more requests.
It’s 10kb, I don’t see an actual problem, unless more stuff gets added.
1) Section Block: I think the Bricks approach can be followed for the Section Block. It inserts a container with the section block. This way you get full control over the outer and inner container. Yes. The empty div block can be used nested and a class can be applied to limit the width.
2) Splitting the js: Multiple file requests is not a problem with HTTP/2. It was a problem with the older version of the protocol. Now browsers can handle multiple files simulatenously. Instead it is recommended not to combine the js files with HTTP/2 and load them seperately. 10kb gzipped or 44KB uncompressed - still mobile devices have to load & process the js. Older and weak devices crumble with a lot of js. I think only what js used should load and Zion get it right. That means code related to Tab & Accordion should only load when I use Tab & Accordion and only on the pages where used. Else there is no business for that code to load.
This has been discussed before a couple of times.
The team is aware of the situation but there won’t be any changes in the near future.
I agree that block specific code could only load when needed.
Everything that is included in that particular file is very minor in size, not sure if it’s a big deal.
Larger libraries gets separated already from it, like I mentioned before.
There could be a discussion, I’m neutral to it.
I can see benefits and I can see downsides.
Your suggestion is not the only right solution but I can see your point of course.
Thanks to Louis for introducing per page css styles and dynamic id & class usage. I am hoping this request also get some attention. Let’s aim for 100/100 in performance.
@dranzer, thanks, it’s an important point.
I have to be honest here, I still have trouble accepting multiple requests are better performance wise 
But this is definitely something we have to address one way or another.
We can easily separate the code for block specifics, no problem there. In fact, the solution may be giving the user the choice between a bundle (as it is now) or block specific loading.
Excellent idea @Louis.
This is the exact approach how it was handled by my previous go-to WP solution.
There was an option to load all scripts separately, instead of the bundle.
However, everything was still loaded - no matter what’s actually required.
At least it opened the opportunity to deregister scripts manually and loading only when needed (which always ended in a mess in larger projects).
Today, there are tools for this of course, or you just use Cwicly to avoid headaches (and save another dozen of plugins).
Nothing against some additional fine-tuning here, so the user can decide on its own 
Again, thanks for not forcing changes on users and giving options in cases it makes sense.
Seems like soon, some overview improvements inside the advanced options area will be necessary 
This is amazing to know @Louis I look forward to it. I guess a toggle as you said will keep all camps happy.
@Louis Not sure when you completed this request. I just realize today when looking at the source. I see the ccers.min.js is now just 6KB before gzip and 2KB gzipped. That’s great! I am closing this request. Thanks!
I think it’s this one:
