-
I concur with much. We see extreme slow load times especially on pages with many blocks. However, if you have web design skills, you can optimize the php files to resolve the page loading times. Fortunately the Studio dashboard provides a Google site speed test that identifies for you the coding errors. If you deploy as an off the shelf solution, you will experience these inadequate user load times. We are taking it upon ourselves in September to fix the php code as we are committed to an October beta release.
-
Not debating one's preference. Just offering a point of view for those the flaws that you have highlighted that they are correctable if someone has the skills. Another reason for slow load times is the number of objects a page layout calls. On pages with fewer blocks calling fewer objects the pages load relative quickly. On pages with many blocks, calling many objects the load time is slow. A developer with strong skills is capable of reducing the load times considerably by editing and restructuring how UNA loads the pages. For the cost of the license UNA is an incredible value. And their support is mostly excellent, especially @LeonidS My biggest critique is they put the horse in front of the cart by announcing big advancements and then we wait a year or two. A great example outside of NEO is the stories module. They announce it is done and then never deploy. They are not perfect but I am thankful for their product.
-
The users have a limit on data transfer for their gadgets
I dont think this is the root cause. Different devices will have different layout for rendering, but usually the same content. Even on a high capacity endpoint with fast internet, it still struggles. My belief is that v14.x contains inherrent architectural flaws.
I've shown for example already the same query being executed multiple times. The proposed solution was to use query cache as a way of mitigating that problem. But as I pointed out, thats contrary to the advice of the MariaDB dev team. There is absolutely no reason to have thousands of database queries to render a single page.
The total database query time is low, but the number of queries is high. Even if the queries are cached, the application layer is still processing thousands of queries. Thats where the inefficiency lives. All of those loops that are doing repetative redundant queries. No amount of tuning will make up for architectural flaws.
Async block handling helps from a pure "visual" perspective, but it still does not reduce page load time. It just helps get the top bit visible sooner. No real solutions without a bigger architectural review.
-
When is NEO coming out?
Comment to 'The need for speed'
Comment to The need for speed
