Script overload (bloat)

Sorry for that, in the last release i forgot to compress the plugin files, that is why the size is so much bigger than what it should be.

The plugin do many things to improve its performance like loading only the code of the fields that are used in your form and splitting all the logic that the fields designer use in its own scripts so it doesn’t affect the live forms.

I know there are a lot more things i can do to improve its performance, and i plan to do them but the plugin is pretty new so i am very busy working in other areas like adding more fields or more type of conditional logics and since this issue wasn’t brought to my attention by anyone (since the plugin is new and its user base is pretty low) i didn’t take actions to improve it until now.

The plugin like i said is new and bad reviews can totally destroy it at this stage, it is so sad that, like you said, you are fed up of the work of all other authors(including myself) and decided to 1 start review my plugin without ever contacting me, i would have love to talk with your and work to make the plugin great for you as well.

Anyway thanks for bring this issue to my attention, i will release the compressed version and will also prioritize the performance of it.

Regards!

• This reply was modified 5 years, 4 months ago by EDGARROJAS.

Hello @mofnones

Probably you already uninstalled the plugin but just in case i just wanted to let you know that i just uploaded the compressed version along a few improvements that i did =), i did some testing and a form with a lot of fields now weight less than 300kb (the size can vary from form to form since the code of each field is loaded only if needed). I know 300kb is still not optimal but i think it is a huge improvement from what you experienced. I will keep working on improving the size of the plugin.

Regards!

Thank you for updating the plugin and improving the script sizes. Going from 2MB+ to 300kb is indeed a huge improvement.

However, it is still way too much. This probably also excludes the external React library which is another 100kb+ ?

As you are probably aware, there are already a lot of plugins in this genre. I’ve tried 7 of them. And yours is by far the one loading the most scripts on the frontend. It’s even worse than the one from Yith, in terms of scripts.

You know that WooCommerce already ads some scripts and the average store has multiple plugins, each adding more scripts. Therefore, it is unacceptable to me that one plugin would load 300kb or more worth of scripts (unless that plugin is a powerhouse like a full-on product configurator or something).

I also think building your frontend with React is a bad idea. Most themes include jQuery so now your users will load jQuery and React. The latter is just for your plugin.

The average store owner doesn’t know about this and only finds out when they do a gtmetrix test a couple of weeks later. By then, their whole store is already live and it’s too expensive/time consuming to change plugins.

I really believe that plugin authors such as yourself have to protect the store owner from this. Simply creating a plugin and stuffing it with a ton of features/scripts just so you can maximize profit, does not benefit the majority of store owners.

WordPress sites generally have a problem with speed and as plugin authors, you can do something about that. This plugin is sadly doing the opposite.

Also, if you’re a premium plugin seller, I would argue that you should hold yourself to higher standards as your customers deserve better. Simply “not looking into this because nobody has brought it up yet” is not good enough. As developer, your deploy process should include cleaning up script size. Your development process should also include thinking about a user’s store in general, not just within the confines of your plugin.

I do hope you understand my point of view.

I don’t share but I do understand (and respect) your point of view. However comments like “a ton of features/scripts just so you can maximize profit” and “you can do something about that. This plugin is sadly doing the opposite” make me want to reply again and express my point of view (and I apologize for my long comment).

Regarding: However, it is still way too much. This probably also excludes the external React library which is another 100kb

You are right I was not including the react library, I was just commenting about the size of the libraries inside the filesystem. If we want to see the real size once the form is loaded in a page, we need to consider react as well but it is also fair to include gzip compression which I didn’t include and it is used, according to w3techs, by 79% of all the sites, and is also added by default by most hosting companies (or at least all the hosting companies that I know). In this case the file size is less than 90kb, including react.

Regarding:And yours is by far the one loading the most scripts on the frontend
Yes the plugin loads more scripts that many other similar plugins and that is done on purpose to improve the performance of the site. The plugin, like I said, loads only the scripts that are needed for the form instead of loading one single file that contains everything. And that is a good thing.

For example, if there is a form that only has a checkbox and textbox would it be better to load two scripts (one for the checkbox and one for the textbox) or load one single script that contains them all (including the code of the other 15 fields that you are not using)? I think loading two scripts would be better and that is what the plugin does (and actually is also a recommendation of google page speed, https://developers.google.com/web/fundamentals/performance/optimizing-javascript/code-splitting).

Not to mention that Code splitting is a hard thing to do and is something that plugins like auto optimize or wp total cache can’t do for you but the plugin is already developed to support it.

Regarding: I also think building your frontend with React is a bad idea
In my opinion is a good thing, and is something that other developers/companies are doing, for example, caldera forms (a form builder which does basically the same thing that this plugin does) use react as well, even WordPress uses react now. There are also many themes that uses it, yes there are many more themes using jquery only. JQuery was the most used framework in the world until a few years ago, now there are other technologies like react, vue or angular and the plugin is just using one of them.

Not to mention that in the worst case scenario the site will need to load jquery and react. React weights only 40kbs(gziped), is that all site breaking? In my opinion is not.

As a Prof here is an image of one of the demos that I have of the plugin reaching 93% score in page speed https://ibb.co/PW5ffts.

It didn’t reach 100% due other issues not related to the plugin but as you see in the image the rendering time (which is the one that the plugin affects the most) is in green. I have to admit that I did some tweaking (in the site and in my server, not in the plugin) to reach this 93% but that is because i had never taken the time to optimize my website (i prefer to use that time to improve my plugins) but it took me less than 30 minutes (basically I just added autoptimize and changed a few settings in my server configuration). I am sure that if I invest a little more time I can reach 100% easily.

Regarding:Simply creating a plugin and stuffing it with a ton of features/scripts just so you can maximize profit

I don’t add tons of features to “maximize profit” (if that would be the case all the new features would be only done for paid users but I am constantly adding features to the free version as well) I add tons of features because I think they would be useful to the users and the best thing is that I can add tons of features without affecting the performance of the plugin/site because the plugin only loads the scripts that are really needed by the form. So if I later add a very big field (for example a signature or carousel field) that weighs 20kb (just inventing sizes here) I can do it without affecting users that are not interested in it.

You can argue that it will affect the performance because now the site needs to load many files instead of only one. I offer two counter arguments for that:
1.- It is better to load splitted js files instead of one single (big) one, not only because you can load only what you need but because the browsers can load different files in different threads. Which btw, if you have a big script probably google page speed will also complains: https://web.dev/mainthread-work-breakdown/

2.- If you want to load one file you can still do it, using a plugin like autoptimize, the plugin can check the page and bundle all the scripts together into one single script. This is a great advantage that the plugin can provide since it was built thinking in code splitting since the beginning.

Can the other way be done as well? If for example one plugin loads a big file can i use autoptimize (or any optimize plugin) to split it? The answer is no, it is impossible since autoptimize (or any optimization plugin) can NOT evaluate which part of the scrip is used and which one is not, this is something that has to be done in the design of the plugin and is something that this plugin is doing.

Lastly, Regarding: sites generally have a problem with speed and as plugin authors, you can do something about that. This plugin is sadly doing the opposite

I strongly disagree on this one (for the reasons that I already provided) code splitting is not an easy thing to do and it was included in this plugin exactly for that, to improve the performance of the site and the plugin.
I added it because I do everything I can and will continue doing everything I can to improve the plugin in both its performance and its features.

Regards!

Yes i guess we have different options, honestly i don’t like the 1 star review (no plugin author like it i guess?) but this has been the best 1 start review i have had. It was a pleasure talking to you about this topic and i wish you the best.

Regards!