• Hey guys,

    I’ve been running through and handling some optimization on a few sites, and noticed that the current R+L plugin runs the get_pallet_types request on every admin_init (which also fires on the front-end during ajax calls) which can impact performance for end users. By either caching that call or changing those settings fields to only be registered on the individual settings page, it can speed that up and reduce the number of API calls made using that method. Below is an example (added to line 595 in woocommerce-shipping-rlc.php – at the beginning of the wc_rlc_settings_init function):

    global $pagenow;
    
    if ( ! ( $_GET['page'] == 'wc-rlc-settings' || $pagenow == 'options.php' ) ) {
         return;
    }
    • This topic was modified 6 years, 5 months ago by Logan Graham.
Viewing 7 replies - 1 through 7 (of 7 total)
  • Joe G.

    (@webgmclassics)

    Hi Logan, I’ve been having performance issues across the board with R&L and my other shipping plugins as well. On my end, it seems that woocommerce is attempting to calculate shipping (and therefore load all the R&L stuff) on each and every call. The USPS plugin seems to have some logic to prevent this, but the UPS and RL plugin have no such features. The WP Heartbeat and the /ajax-admin are really draining our resources because of this.

    Do you know a way to disable the Woo shipping logic all together except when it is called from the /cart or /checkout or elsewhere where it is actually necessary?

    Thanks!

    Thread Starter Logan Graham

    (@omac)

    If your WooCommerce installation is up to date, they’ve actually become quite good about caching returned rates and only recalculating that – via the calculate_totals cart function – when the cart or address has changed. Unless there’s a rogue plugin or addon that’s causing it to run that function on every page WC itself shouldn’t be requesting those updated totals.

    As far as fixing it on every AJAX load, the code snippet and instructions I put above should resolve that atleast for the R+L plugin. You would have to see what is calling the UPS update separately – whether that plugin specifically or whatever might be running calculate_totals.

    Joe G.

    (@webgmclassics)

    Interesting to know! I’ll add that snippet to the RL Plugin for sure.

    Also, we had an outside firm write a custom plugin to control some of our shipping logic. It uses the woocommerce_package_rates hook. Do you know if that hook forces calculate_totals ?

    Thanks so much for your help. I’m not a professional WP / Woo developer and have been trying to debug this for a while.

    Thread Starter Logan Graham

    (@omac)

    Using that filter itself would not. WC will check to see if your package has changed vs the cached rates – and if it has – re-run the function that calculates shipping per package. However, if you have Shipping Debug Mode on it will not cache rates. This is toggled via (the dashboard) WooCommerce -> Settings -> Shipping -> Shipping Options -> "Enable Debug Mode".

    Joe G.

    (@webgmclassics)

    That makes sense. One more question for you: when a user adds a new product to the cart, it would seem to bust this cache and recalculate the rates. I’ve witnessed it a few times when ‘add to cart’ is extremely slow because it is getting hung up on an external API lag (i.e. RL). Do you know if it is possible to hold off on recalculating the rates until absolutely necessary on /cart or /checkout, even when there is a change to the cart?

    Thread Starter Logan Graham

    (@omac)

    You can remove the hook that WC uses like so:

    remove_action( 'woocommerce_add_to_cart', [ WC()->cart, 'calculate_totals' ], 20 );

    However, if you have any sort of ‘mini cart’ that’s being displayed in the header, sidebar, etc, then that will likely call the same function before it’s output to make sure the end user is getting the most up-to-date calculation / rates. Otherwise, the user will experience a minor delay while visiting the cart page as it will have to retrieve those rates so they can be shown to the user. I would still advise testing that thoroughly to make sure it works with your system / setup.

    Joe G.

    (@webgmclassics)

    God it. I’ll give it a try! Thanks so much.

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘Plugin running request on every admin load’ is closed to new replies.