B4J Question [BANano] Initial load times slow 10 seconds+

[Chris Lee]

Hi all,

Occasionally I've checked in on progress of the BaNano project.
It's a cool and innovative idea, and is certainly a framework I've considered using.

The thing that has continued to hold me back though, is load times, especially the initial load of the site.
I was doing some testing on the kitchen sink site here:

https://magenta-vacherin-2f7e6b.netlify.app

I have what I consider a reasonable internet connection.
Speedtest indicates 214.37mbps download speed.
I'm testing on my PC with the following:

Windows 11
Chrome Browser
PC has Ryzen 5 3600 with 16GB RAM and is generally fast.

Your milage may vary, but for me over multiple tests, the typical initial load time for the site is around 13 seconds.
On a single occasion it loaded in 9 seconds, but on a number of occasions it would take 17 seconds.

If you look at online articles, such as this one, it estimates that 67% percent of users will abandon a website that takes 12 seconds to load:

https://www.websitebuilderexpert.com/building-websites/website-load-time-statistics/

I was searching on the forum, but couldn't find much discussion on this.
The closest I could get was this:

https://www.b4x.com/android/forum/t...proving-perceived-performance-on-7-29.137742/

However that is simply showing how the wait animation can be implemented.

So my question is, would a typical website be as slow to load as the demo site?
Do any strategies exist (beyond a wait animation) that would reduce the load times?

Obviously I could create a separate static website that would load quickly, with the interactive 'application' taking much longer.
This would definitely help to an extent.

I don't want to be too negative, I think this is a very interesting concept, and I appreciate a lot of work as gone into it.
I'd appreciate any thoughts or ideas that anyone might have on this.

However, if I'm honest, I still think that most users won't be happy with load times of 13+ seconds.

 

[Mashiane]

Hi, if you can please prefix your question title with BANanoVuetifyAD3 as the project in netlify refers to that.

Thanks a lot for your kind words and we welcome the constructive critic.

1. The project in question that runs on that site is a very large project as it demonstrates everything in the BVAD3 kitchen sink, this is 137+ pages. The project alone is 3M+ large, excluding CSS + JS files etc and excluding the library itself, which is also 3MB+ in size, in total we are talking about a 6MB+ js file.

2. This is what we have done so long, during the week we moved most of the CSS + JS content that the library is using to jsDelivr. What this does is help the compilation time of the project as resources are now sitting on jsDeliv and thus not included as part of the final package. Also because you are using cached resources, the project load times are faster. This was published here.

By turning the Online = True when one is building their copy of the library, will mean that jsDelivr is used and not local content, a smaller package and faster speeds.

3. We understand that developers might use only portions of the library and not everything. For this we have also added functionality in the library to use the Core Components of the library. This can be done by setting CoreFunctionality = True, doing this means that the plugins in the library are not used, a smaller package and faster speeds

4. One other tool we have been fine tuning is the Package Manager. What this does is to tree shake your project by removing actual unused component files. What it does is to scan a zip of your project, finds out the components that are used, removes unused ones from the copy of the library that you can use as a final. This package manager and how it works has been discussed here. For example, part of the 3MB file size of the library is made up of more that 120 components, if your project only uses 5 of those and you dont package manage your final app, all those 120 components will be included, whether used or not.

5. Finally, there is functionality with BANano, to remove dead code. Removing dead code helps also in tree-shaking your application.

In conclusion, running the Kitchen Sink project with speed tests WILL fail, because the project has not been optimized. It didnt go through the package manager, dead code removal has not been turned on and as yet to be fully updated with a library that uses the CDN. I think. Perhaps in the near future this can be done.

We do understand the need to make this better as much as we can and even to pass the speed tests. We are sure this will be better as we go along.

Kind Regards

Mashy

PS: Testing Page Speeds with Small Projects

To test page loads with a simple project, in B4J, if you are already setup, select the BVAD3 Blank project. You will note that the load speeds are fairly close to acceptable.

 

[alwaysbusy]

The average first-time loading time for our vanilla BANano WebApps is under 300ms and is often perceived by our users as feeling like a 'native' app. Installed as a PWA with the Service Worker, startup times are similar.

BANano was developed by our company with this kind of speed in mind. This was needed as our research confirmed what you say that at a certain point (and this point is way under 1sec) users do not want to work with it anymore and sales drop drastically.

We only use ultralight vanilla UI components and we avoid using other extra layer frameworks like React, Angular or Vue as we see B4J already as being such a framework in itself. We do not like to wrap yet another additional layer. Those frameworks were developed to make it easier for the developer to write WebApps in other tools. But as said, that is already where B4J comes in here.

We always use the BANanoSkeleton library as our starting point with all our WebApps and write custom components in B4J specific to the clients needs. They are not all bundled in one big library. We do not believe in a 'one-thing-does-it-all'. As those special components are written modular (most of them are each one .bas file with their own .css and .js files), B4J makes it very easy to add those additional specific components to the next project by just copying some files and make some client specific adjustments. We can re-use a lot of code for each new project by writing in such modular way instead of putting it all in one lib.

We also do not over-use the properties available in each component in the Abstract Designer. Many properties are often not used all the time but they result in hefty objects that have to be parsed by the browser at loading time, resulting is a bad first-paint score. We use only the most common ones and the special ones can always be done later in code if needed.

BANano has a build-in system to remove all dead code (up to Sub level). So if the component is written modular, the transpiler will clean out even the methods within it that are not used in your final WebApp. Unneeded .css and .js files are also excluded. All of this keeps the size, debug transpiling time and client - server round trips to an absolute minimum.

As BANano supports B4Js 'hot code swapping', writing such a new component can often be done without having to recompile the whole project and changes can be made on-the-fly until we are satisfied with it. BANanoElement is your friend here.

I completely understand that some people prefer using a Vue wrap like the BDAV3 library for ease-to-use, but this extra layer comes indeed at a price. I don't know all the fine bits of the BDAV3 project as it isn't a good fit for our audience. We mainly focus on mobile users and speed is critical as using the WebApps is only a small part on our clients workfloor. Every millisecond counts there. In the offices they use our ABM based WebApps where we can unleash B4Js full power for e.g. the REST API, reporting etc... For example, we don't want to waste time and resources by trying to make PDF reports on the client side. The server side is a much better fit to do this. One REST API call to jServer, build the pdf there and return a link so the WebApp can present/download it.

We believe doing some effort in understanding the basics of JavaScript and CSS, together with BANanoElement and BANanoObject is well worth the time. If so, you can focus on the 'logic' of the WebApp mainly done in pure B4J code and end up with a speedy vanilla WebApp. BANano, together with B4J itself of course, has dropped development time of PWAs in a big way for us.

Alwaysbusy