Hey @Louis,
Now that I’ve had some time to play around more with the design library, I’ve noticed that it can take some time to render all the sections if there are more than a couple on the page:
I’m curious, is this just how Gutenberg renders things, or is it something that can be improved in Cwicly?
I just added a few sections from the library, but if you want to test the sample page in particular, here’s the library key: kmFiroOTyjPV7AR3hD9s
Thanks!
Hi @sunny,
Thanks for bringing this up.
Definitely something that we’re addressing currently, which is in part linked to how Gutenberg manages things, but also some improvement can come from our side.
The next few updates should fix things quite significantly 
Ah, that’s great to know.
Thanks as always 
In case anyone is curious, I decided to do a similar test with GenerateBlocks:
I mostly wanted to see if Gutenberg was capable of rendering pages as quick as a page builder.
The initial page load took an extra second, but all the blocks were instantly available afterwards. So I’m curious to see what optimizations Cwicly can come up with in future updates 
That’s very insightful, thanks for that @sunny.
Had in mind to do the same for quite a time, just out of curiosity, because Cwicly is my first point of contact with Gutenberg and there wasn’t a real reference for me.
I think Cwicly does a solid job right now and I have the feeling it already improved in that regard over the last months.
Still, good to see some refinements are on its way.
Mainly because I have some concerns in terms of scalability, like you demonstrated in your video.
Fortunately, we do have the privilege to work with high-end devices.
I can’t tell if that even matters and is related, but if this is the case, some tweaks will be even more welcome to make it more accessible to everyone.
Again, thanks for addressing this and as well to @Louis for the effort making Cwicly better every single day.
Yeah, exact same here. I was really worried that the slow rendering was an inherent flaw with Gutenberg, but I’m really glad that’s not the case.
I’ve had to deal with some really slow sites with Oxygen 3.x in the past (4.0 improved things drastically), and I wanted to make sure Gutenberg isn’t just another path down that road.
Yep! It’s totally acceptable for most pages in its current state. It’s only longer landing pages that I’d start having any concern about.
Great point. I’m sure it is related, because that page on local seemed to be overwhelming the browser - and I rarely see the browser get stuck on this device. It would’ve probably taken my old laptop out for 5 minutes.
I also noticed the slow down. I think it is due to all blocks being php/dynamic compared to static blocks. I think Cwicly does not rely on js static blocks as the block recovery mechanism of Gutenberg is poor.
Pinegrow is going to work on hybrid blocks after their WP plugin is released. Dev says “JS in the editor and PHP on the frontend. That would make sure that blocks are always displayed up to date and avoid the recovery completely.” Though it might slow down the front-end a bit?
I will look forward to the upcoming updates Louis have planned for this issue.
Did you already test things out?
If so, what’s your impressions so far?
Not yet. I am yet to update. I’ll update later today and check.
I think it loads faster, just a bit nastier. (it loads the stylesheets at the end and till everything loads the page looks broken)
Also there seems to be some issues as sometimes, some blocks, remain with “We could not verify your website, you might have to check your license activation.” notice. (even after everything is loaded)
It looks to be significantly better now. The page does take an extra couple seconds to load (similar to GenerateBlocks), but is available to edit much quicker after page load.
I did a second test with a page twice as long, and I did run into the license verification issue @alex mentioned above.
Here’s the screen recording: Loom | Free Screen & Video Recording Software | Loom
Can confirm that some blocks do not get rendered after full page load on larger pages.
License verification placeholder will display instead.
Can also confirm the same on my end.
Quick feedback after the patch.
Issue is fixed and I was able to run some challenging tests.
This is what I experienced as well, bravo 
If there is more space or improvements, please keep them coming 
Maybe also in terms of the page loading process experience itself?
Thanks for this QoL improvement and of course also for the instant fix.
When a page(build) gets a bit longer load times are usually around 20 sec. It feels long. Is there room for more improvement or is Cwicly on its limit in that regard?
Also, when working on such a page. Things get stuck (long wait or need to refresh) very often. That’s something that definitely needs to be improved. I can share a login for my build if you want Louis.
Working on PHP 8.1 Digital Ocean Droplet. all memory/server settings optimized for speed development.
Hi,
What I personnally find very slow is the stylesheet loading, which for instance leaves content unstyled for 2 seconds even with very simple posts, no queries or heavy content.
This looks especially unprofessionnal for client editing
Hi @webmaat,
That’s either a very dynamic page or something’s up.
Would appreciate giving this a look if you can send the details to support@cwicly.com.
Cheers,
Yeah, it became unworkable. imagine working on the responsive side and switching between desktop, tablet and mobiel all the time with 20 sec load every time.
Pages are not that huge or dynamic: Maatwerk websites voor bewuste ondernemers – Webmaat
I send a temporary login to you right now. thanks in advanced
I saw your remark on speed on the other topic just now. To be precise: when I open a already build page it takes around 50 sec. When That page is open and I want to switch to tablet of mobile it takes around 15 sec. When I want to open a new page it take 3 sec for editor to load. I mail you a screencast now