feat: improving page load time

[rithikb24]

Description

Moving autoloader only when the plugin is initialized - improving memory usage and plugin performance

Type of change

• Fix (non-breaking change which fixes an issue)

Checklist

• [yes] I have commented my code, particularly in hard-to-understand areas, if any.
• [yes] I have confirmed that my changes do not introduce any new PHPCS warnings or errors.
• [yes] I have checked plugin debug logs that my changes do not introduce any new PHP warnings or FATAL errors.
• [yes] I followed general Pull Request best practices. Meta employees to follow this wiki.
• [yes] I have added tests (if necessary) and all the new and existing unit tests pass locally with my changes.
• [] I have completed dogfooding and QA testing, or I have conducted thorough due diligence to ensure that it does not break existing functionality.
• [] I have updated or requested update to plugin documentations (if necessary). Meta employees to follow this wiki.

Changelog entry

Moving autoloader only when the plugin is initialized - improving memory usage and plugin performance

Test Plan

Screenshots

Please provide screenshots or snapshots of the system/state both before and after implementing the changes, if appropriate

Before

After

[facebook-github-bot]

@rithikb24 has imported this pull request. If you are a Meta employee, you can view this in D82455607.

[ukilla]

Hi @rithikb24,

I am providing you with the results I got from testing this feature.
Query Monitor plugin was used for getting the metrics, and the testing was done on our staging website.
The results are:

• Home Page Loading times: On average 0.127 s faster without the fix

• Home Page memory usage: On average 193 KB less memory without the fix

• Shop Page Loading times: On average 0.010 s faster with the fix

• Shop Page memory usage: On average 253 KB less memory without the fix

• Product Page Loading times: On average 0.036 s faster with the fix

• Product Page memory usage: On average 118 KB less memory without the fix

Based on these results, the observed differences are negligible and fall within the range of normal variation between requests.

I am also attaching a document containing the full set of logged requests along with the computed averages for both scenarios.
Autoloader loading fix Facebook for WooCommerce test results.txt

[rithikb24]

Hi @ukilla - could you share how you used query monitor plugin to get these metrics?

[ukilla]

Hi @ukilla - could you share how you used query monitor plugin to get these metrics?

Hi @rithikb24 - I have used Query Monitor to write down the performance metrics of Home, Shop and Product pages.
We will also test out the checkout flow to see if there are any notable differences in that scenario. I am attaching a sample screenshot. The metrics are marked on the screenshot.

[rithikb24]

Thanks for sharing - One more thing, I noticed a consistent 100ms+ improvement using Code Profiler plugin to check plugin execution time.

This issue suggested this improvement - #2878
Other plugins in the above threads reported improvement when delaying composer autoloader.
Could it be the difference of how it's being measured by code profiler plugin?

https://wordpress.org/plugins/code-profiler/

[rithikb24]

@ukilla I think the 100ms+ performance gain from composer autoloader happens before query monitor even starts measuring page load time.

[ukilla]

@rithikb24 After reviewing the implementations of Code Profiler and Query Monitor, I confirmed that Query Monitor initializes on the plugins_loaded hook. In contrast, Code Profiler runs as a must-use (MU) plugin, which is loaded earlier in the request lifecycle. The MU-plugin load step fires before the plugins_loaded hook (see the muplugins_loaded documentation).

Because of this difference in load order, Query Monitor will not capture performance gains that occur during the bootstrap phase (such as improvements from delaying the Composer autoloader), while Code Profiler does.

[rithikb24]

@ukilla Yep! I came to the exact same conclusion - thank you for confirming!

[ukilla]

@rithikb24 - Could you share how you used Code Profiler to test the execution times? On our tests it seems like the execution time increased with the plugin version that has this fix. We tested the Home, Shop, Cart and Product pages.

[ukilla]

Hi @rithikb24,

We were able to simulate a fatal error using a MU plugin that preloads the Checker class. This confirmed that the previous approach of delaying Composer loading based solely on class_exists('Checker') was not reliable, since other Composer classes might still be missing, which could lead to fatal errors.

In the issue you mentioned, the developers of other plugins solved the problem by requiring the Composer autoloader inside the functions that actually need Composer classes. Since we need the Composer classes in init_plugin(), your original approach of including the autoloader there is appropriate. I added a define('WC_FACEBOOK_AUTOLOADER_LOADED', true); after loading the composer autoloader so we make sure that it only loads once per request.

[rithikb24]

Hi @ukilla - really appreciate the detailed input here - thanks for adding the changes. I will take a look!