WordPress is often incorrectly accused of being slow or bloated. Of course this isn’t actually true is we’re talking about WP core as in “Just WP with a core theme and no plugins”. In real world practice of course nearly every WP site in production has at least a few plugins running, and most also run a custom theme. It’s debatable where performance issues occur most often, but it is almost always in the 3rd party codebase that is added to a WP site. Because let’s face it, WP out of the box is blazing fast. It’s a highly optimized and minimalistic loading system. At SaberWP we aim to keep it that way when you install Saber Commerce.
Saber Commerce has a modular approach to it’s loading that we call the SACOM Component system. Essentially the plugin itself loads nothing. The plugin outside of the components only exists to handle install and activation, deactivation and to provide a handful of base PHP classes, and optional loaded scripts. In other words the plugin provides some global support for it’s components, beyond that every component is a modular and distinct unit of code that self-initiates.
This component approach within the plugin is of course very similar to what WordPress itself is providing by having the ability to activate and deactivate plugins. Modular approaches are so important at every level of software development, not just at the framework level but inside of WP plugins and inside of the codebase as well.
Saber Commerce components such as the timesheet component, only load when they are needed. They are self-aware of the “context” of the application, in simpler terms they know what page the visitor is loading. So they load scripts when needed, and only when needed. The separation of concerns from front-end to back-end ensure anything designed for the WP Admin only initializes when the user in in the WP Admin and never on the front-end.
If we compare this to WooCommerce (and in fairness they may eventually change it?) a site running WC tends to have WC scripts loading on every single page. This is particularly a problem if most of the website isn’t even using WC because it might for instance be an elearning site with a checkout for student purchases. So the cart and the checkout is where the WC scripts are actually needed, but these same scripts load on course pages and marketing pages (for some reason?). A common optimization technique for WC sites is actually to dequeue the scripts that are not required from pages that don’t need them. The same process can be used for other plugins that use “script load everywhere” approaches.