Performance concerns on the front-end

[yabdali]

Hi, I noticed that the plugin related files for the front-end part is considerably large compared to other plugins (CSS/JS) and are impacting the over all performance of the website. Would it be possible to consider the following? Thanks

• Providing some mechanism on the admin section to toggle (on/off) plugin related features on some of the pages (e.g: home page, shop, product, post etc...)
• Minifying the files or splitting them to reduce the impact
• Providing an option for cloud code CDN as the source such as https://cdnout.com/cdn/fullcalendar/
• Worst case: providing some guideline on what can be disabled using 3rd party plugins

[yoancutillas]

Hello, performance issues are mostly related to your server and whether you use a caching plugin or not. Your connection speed is also an important factor. With a caching plugin, js and css assets are loaded only once. On my side, the demo website pages are loaded instantly. I am using a Siteground hosting, with the SiteGround Optimizer plugin for caching.

The js and css files are already minified. Wordpress doesn't allow to call external js (guidelines), but you can set up a CDN for your site.

You can use the code provided in #12 and adapt it to your needs, to load Booking Activities' css and js only on the desired pages. Becareful because this may cause malfunctioning if you forget a page. Alternately, you can find third party plugins that disable certain plugins on certain pages. You can try this solution, but the gain will probably be minimal compare to the use of a caching plugin and a fast hosting.

[yabdali]

Hello, performance issues are mostly related to your server and whether you use a caching plugin or not. Your connection speed is also an important factor. With a caching plugin, js and css assets are loaded only once. On my side, the demo website pages are loaded instantly. I am using a Siteground hosting, with the SiteGround Optimizer plugin for caching.

The js and css files are already minified. Wordpress doesn't allow to call external js (guidelines), but you can set up a CDN for your site.

You can use the code provided in #12 and adapt it to your needs, to load Booking Activities' css and js only on the desired pages. Becareful because this may cause malfunctioning if you forget a page. Alternately, you can find third party plugins that disable certain plugins on certain pages. You can try this solution, but the gain will probably be minimal compare to the use of a caching plugin and a fast hosting.

Thanks for your quick response and continuous support. Yes, I agree about the server response time. However, this is a common requirement for every website. I can specifically pinpoint to two areas that I had in mind when I referred to the performance impact. The first, is the size of the files, this is compared to average file size of other plugins. The second is the number of files and their use. As for your plugin, I am not sure which of those files are specific to the back-end (admin) which could be eliminated (removed) from the front-end pages. I have identified some of the files that could be removed individually for certain pages, prior to receiving your response. wp-content/plugins/booking-activities/js/booking-system-dialogs.min.js wp-content/plugins/booking-activities/js/booking-system-functions.min.js wp-content/plugins/booking-activities/js/booking-system.min.js wp-content/plugins/booking-activities/js/bookings-dialogs.min.js wp-content/plugins/booking-activities/js/bookings-functions.min.js wp-content/plugins/booking-activities/lib/fullcalendar/fullcalendar.min.js wp-content/plugins/booking-activities/lib/fullcalendar/locale-all.js

Correct me if I am wrong, its safe to assume that we can use the enqueue script to only load BA in a product detail page only if the calendar will be used to list and book the event for a specific product?

[yoancutillas]

The js and css files are already split between the backend and the frontend: some files are loaded only on the backend, others only on the frontend, and others on both. I agree that they could be even more targeted to gain few ko (it would mean more files). Booking Activities cannot know whether a booking form or a booking list will be displayed at the time when the scripts should be included (wp_enqueue_scripts), since they can be displayed with a shortcode that are processed later on. So the files used on the frontend are loaded on every page of the frontend (like any plugins do), on wp_enqueue_scripts.

I understand your concerns, but with the browser cache, a caching plugin, and an optimized host, we are talking about few milliseconds for the very first page loaded by a customer. The files are loaded only once. That's why I was offering you to try the code in #12, so you can test the loading time with, and without Booking Activities files.

My point is not that it doesn't necessarily worth it, it is that you can set up a lot of systems aside that would drastically improve your performances compare to the few ko and milliseconds you can gain by loading or not the files on the first page load or on the second. That's why I was offering you to try the demo website, where Booking Activities and all its add-ons are loaded on the frontend.

I have made a test on the demo website, here is the loading time of the home page:

• With Booking Activities files: 01:18
• Without Booking Activities files: 01:12

Here is the real-time capture:

https://user-images.githubusercontent.com/9415030/132840665-d3826d03-fd27-470d-aee0-43d00401445d.mp4

(click here if the video doesn't load) The video is 30fps, 01:18 means 1 second and 18 frames, not 18 milliseconds. That is to say 1 second and 600 milliseconds.

Finally, you cannot compare Booking Activities files to another plugin, there is no useless code, all the code loaded is used. Other plugins do things differently, and may not need as much js. But they are not offering what Booking Activities offers. So the question is, does Booking Activities features worth its loading time in regards to your needs, or would a more lightweight plugin be preferable for your needs? (which is perfectly fine, without any judgement or criticism)

[yabdali]

Thanks again for your engagement with the users and your support... I agree with you overall though I have some different views about what could be the alternative approach. Just to reiterate, I am not saying that BA is the main reason for performance impact, for me as an end user I would seek optimization opportunities across all the components of the website. As for the enqueue_scripts, I haven't yet tested it since I have used another plugin to remove most of the unwanted parts from different plugins but I will be testing it for sure. My main objective is not only to minimize the load time but also make the pages lean by cutting the unnecessary code loaded into each page (fat) which helps in many ways including SEO related aspect.

[yoancutillas]

No problem, thank you! Ok, I understand the theoretical benefits, but how will you measure them?