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.
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.
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.
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