• Resolved Guy Chapman

    (@guychapman)


    Several WooCommerce page loading issues

    Page load times in WooCommerce Admin are generally a minimum of 30 seconds and sometimes fail to load.

    I have taken numerous usual steps to identify the root cause that I can explain as required.

    The initial issue that caused me to begin troubleshooting, is that Elementor page builder is slow to load a page when opened for editing, or more often, fails to load completely. On occasions this causes the whole site to become unresponsive for a few minutes before returning. When this happens, an increase in memory use is observed (on the recently upgraded infrastructure).

    After various attempts to identify the cause, I noticed the Elementor issue is significantly worse when WooCommerce is enabled. That is, without Woo, the page loads slowly (eg 30 seconds), with Woo it usually fails (eg page load of 90 seconds or greater or failure to load at all).

    This lead me to further review WooCommerce and related plugins (Payments, Shipping, Square) where the following issues have been observed.

    Theme in use is ‘Bridge’ by Qode Interactive – and yes, I can reproduce the error on twenty twenty-three. I’ve also checked in with them first to make sure there’s nothing obvious from a Theme point of view. They have cart.php page to update soon but say that will not be related to this issue. Issues can also be reproduced on a clean install of WP and minimal suite of plugins.

    I realise there may be some other underlying root cause for the slow performance, and that the various issues mentioned may be unrelated, but I’m starting here with WooCommerce as there are several broken items and the performance is significantly worse with it enabled.

    WooCommerce related issues

    Menu item: WooCommerce / Home
    “There was an error getting your inbox. Please try again.”
    Of course, trying again yields the same result

    Menu item: Customers
    Long page load time around 60-90 seconds, customer table outline renders then page fails with error “There was an error getting your stats. Please try again.”

    Menu item: Payments, Payments Tab, WooPayments, Manage
    Error briefly pops up in black box at lower left of screen
    “Error retrieving settings”
    Page renders but no settings are populated. Re-populating and saving them does not fix the error

    Menu item: Payments, Overview
    Page sometimes does not render or slowly renders with these errors
    Errors briefly pops up in black box at lower left of screen
    “Error retrieving all deposits overviews”
    “Error retrieving all deposits”

    Menu item: Analytics
    All charts fail with error
    “There was an error getting your stats. Please try again.”

    I’ve have a status report available and can load that up if required

    WP version 6.3
    PHP Version 8.1.19

    • This topic was modified 10 months, 4 weeks ago by Guy Chapman.
Viewing 14 replies - 31 through 44 (of 44 total)
  • Plugin Support B C. a11n

    (@battouly)

    Hey @guychapman ,

    In the hosted test environment that is vanilla WP with only WC plugin installed, I updated WC to 8.1.0 that was just released and I get the same errors

    This is odd, but since the local instance is all good (which is what is expected), this suggests something may be wrong with the hosting side of the site.

    Well done on the process reducing the delays, but the ideal scenario would be a perfectly working site without delay in load time. Personally, I am unable to replicate this behavior on my test site.

    Hey @swaswaswa are you able to test this locally too? It would be great if you could try this with a different host and share your findings.

    I will leave this thread open in case someone has a clue or the possibility to test further.

    Thread Starter Guy Chapman

    (@guychapman)

    Thanks for that @battouly,

    Just to add some additional info, in the vanilla install, with just WC plugin and upgraded infra, when repeatedly reloading the WC Home page each time errors come up in the browser console, just occasionally, perhaps 1 in 15 times, the page will load correctly with no errors (the errors are usually from the items in the In box). So it’s not a permanent blockage somewhere that never works, hopefully there is someone who understands the WooC interactions end to end who can chime in on this.

    Cheers

    • This reply was modified 9 months, 3 weeks ago by Guy Chapman.
    Thread Starter Guy Chapman

    (@guychapman)

    Clearly this has stalled with no solution apparent so just for the record, these are some examples of the failed links that show up in the browser console (as also shown in the images attached throughout this ticket that may disappear over time). The domain in the path is replaced with ‘~’

    Home
    ~/wp-json/wc/v3/products?status=publish&_fields%5B0%5D=id&page=1&per_page=1&_locale=user
    ~/wp-json/wc-admin/onboarding/profile?_locale=user
    
    ~/wp-json/wc-analytics/admin/notes?page=1&per_page=5&status=unactioned&type%5B0%5D=info&type%5B1%5D=marketing&type%5B2%5D=survey&type%5B3%5D=warning&
    orderby=date&order=desc&_fields%5B0%5D=id&_fields%5B1%5D=name&_fields%5B2%5D=title&_fields%5B3%5D=content&_fields%5B4%5D=type&_fields%5B5%5D=status&_fields%5B6%5D=actions&
    _fields%5B7%5D=date_created&_fields%5B8%5D=date_created_gmt&_fields%5B9%5D=layout&_fields%5B10%5D=image&_fields%5B11%5D=is_deleted&_fields%5B12%5D=is_read&_fields%5B13%5D=locale&_locale=user
    
    ~/wp-json/wc-analytics/reports/performance-indicators?after=2023-10-06T00%3A00%3A00&before=2023-10-06T09%3A07%3A55&stats=revenue%2Ftotal_sales%2Corders%2Forders_count&_locale=user
    
    Customers
    ~/wp-json/wc-analytics/products/low-in-stock?page=1&per_page=1&low_in_stock=true&status=publish&_fields%5B0%5D=id&_locale=user
    ~/wp-json/wc-admin/options?options=woocommerce_ces_tracks_queue&_locale=user
    ~/wp-json/wc-admin/options?options=woocommerce_admin_transient_notices_queue%2Cwoocommerce_admin_install_timestamp&_locale=user
    ~/wp-json/wc-analytics/admin/notes?page=1&per_page=25&type=error%2Cupdate&status=unactioned&_locale=user
    ~/wp-json/wc-analytics/data/countries?_locale=user
    ~/wp-json/wc-analytics/reports/customers?orderby=date_last_active&order=desc&page=1&per_page=25&_locale=user
    ~/wp-json/wc-analytics/reports/customers/stats?fields%5B0%5D=customers_count&fields%5B1%5D=avg_orders_count&fields%5B2%5D=avg_total_spend&fields%5B3%5D=avg_avg_order_value&_locale=user
    
    Analytics
    ~/wp-json/wc-admin/plugins/installed?_locale=user
    ~/wp-json/wc-admin/options?options=woocommerce_ces_tracks_queue&_locale=user
    ~/wp-json/wc-admin/options?options=woocommerce_admin_transient_notices_queue%2Cwoocommerce_admin_install_timestamp&_locale=user
    ~/wp-json/wc-analytics/admin/notes?page=1&per_page=25&type=error%2Cupdate&status=unactioned&_locale=user
    ~/wp-json/wc-analytics/reports/performance-indicators?after=2022-10-01T00%3A00%3A00&before=2022-10-06T23%3A59%3A59&stats=revenue%2Ftotal_sales%2Crevenue%2Fnet_revenue%2Corders%2Forders_count%2Cproducts%2Fitems_sold%2Cvariations%2Fitems_sold&_locale=user
    ~/wp-json/wc-analytics/reports/performance-indicators?after=2023-10-01T00%3A00%3A00&before=2023-10-06T09%3A26%3A37&stats=revenue%2Ftotal_sales%2Crevenue%2Fnet_revenue%2Corders%2Forders_count%2Cproducts%2Fitems_sold%2Cvariations%2Fitems_sold&_locale=user
    ~/wp-json/wc-analytics/reports/revenue/stats?order=asc&interval=day&per_page=100&after=2023-10-01T00%3A00%3A00&before=2023-10-06T23%3A59%3A59&fields%5B0%5D=total_sales&fields%5B1%5D=net_revenue&fields%5B2%5D=refunds&fields%5B3%5D=shipping&_locale=user
    ~/wp-json/wc-analytics/reports/revenue/stats?order=asc&interval=day&per_page=100&after=2022-10-01T00%3A00%3A00&before=2022-10-06T23%3A59%3A59&fields%5B0%5D=total_sales&fields%5B1%5D=net_revenue&fields%5B2%5D=refunds&fields%5B3%5D=shipping&_locale=user
    ~/wp-json/wc-analytics/reports/orders/stats?order=asc&interval=day&per_page=100&after=2023-10-01T00%3A00%3A00&before=2023-10-06T23%3A59%3A59&fields%5B0%5D=orders_count&fields%5B1%5D=avg_order_value&_locale=user
    ~/wp-json/wc-analytics/reports/performance-indicators?after=2023-10-01T00%3A00%3A00&before=2023-10-06T23%3A59%3A59&stats=revenue%2Ftotal_sales%2Crevenue%2Fnet_revenue%2Corders%2Forders_count%2Cproducts%2Fitems_sold%2Cvariations%2Fitems_sold&_locale=user
    ~/wp-json/wc-analytics/reports/orders/stats?order=asc&interval=day&per_page=100&after=2022-10-01T00%3A00%3A00&before=2022-10-06T23%3A59%3A59&fields%5B0%5D=orders_count&fields%5B1%5D=avg_order_value&_locale=user
    ~/wp-json/wc-analytics/leaderboards?after=2023-10-01T00%3A00%3A00&before=2023-10-06T23%3A59%3A59&per_page=5&persisted_query=%7B%7D&_locale=user

    • This reply was modified 9 months, 1 week ago by Guy Chapman.
    Plugin Support B C. a11n

    (@battouly)

    Hi @guychapman,

    I understand this support thread has been going on for ages now, so I reached out to the developers to see if they can suggest anything. But there’s not a lot of info for them to suggest anything right now.

    We’ve requested to see the PHP/server error logs, but it seems you don’t have access to those logs ? The errors 503 makes us think that something must’ve been logged somewhere and that would’ve been really helpful.

    Also, at least from the our understanding of this issue, most problems seem to be related to either Elementor or AJAX/REST requests, not the backend or frontend itself. I’m not sure how Elementor works, so maybe the slowness in Elementor is also related to AJAX/REST requests, but this is a bit weird since the rest of the site apparently works ok. We wouldn’t rule out something in the host producing the problem (not necessarily that it is underpowered, but maybe some DB or request limits that are being hit?).

    Thread Starter Guy Chapman

    (@guychapman)

    Hi @battouly,

    Thanks so much for checking in with the dev team.

    Regarding the logging, I do have pretty good access to the host and have checked server logs and have enabled php debug.

    On occasions when the whole system used to freeze when opening a WooCommerce page (this is not happening now after the hosting capacity increase) there were server errors in the logs like the ones below, but that was because the whole system was dying so no surprises there. Now that loading a WooCommerce page no longer brings down the host nothing is written to the server logs when the json errors are displayed in the browser console.

    mod_fcgid: can't apply process slot
    [error] mod_fcgid: ap_pass_brigade failed in handle_request_ipc function

    For php logging, I have tried two methods to see if anything is written out about the browser console json errors. One is to enable php logging via the php.ini that I have access to modify via the host, the other by disabling that (as they conflict) and using this in wp-config.php

    define( 'WP_DEBUG', true );
    define( 'WP_DEBUG_LOG', true );

    Neither method writes out any log files when repeatedly loading the WooComerce pages with the errors.

    Also, nothing new is reported at WooCommerce > Status > Logs

    I agree, you would think the 503 error reported in the browser console would also be in the server log, but there is nothing there. If there are any other tricks to getting logging happening I’m happy to give them a go.

    I’ve had a couple of tickets open with the hosting company where they have checked logs and have raised limits on the host but report that nothing looks out of place for them.

    I mentioned the Elementor slowness previously as it was vastly worse as soon as WooCommerce plugin is enabled. Perhaps this is just because Elementor is bloated / heavy and shows up the issue easily. The console errors displayed are with WooCommerce json/ajax/rest links.

    Database issues could be worth exploring further. The error is repeatable on a test vanilla install of WP with a new db. Any tips on where to look for logging there are more than welcome.

    Cheers,
    Guy

    Plugin Support Sean O))) a11n

    (@seanomattic)

    Hi @guychapman,

    Thanks for getting back to us.

    I agree, you would think the 503 error reported in the browser console would also be in the server log, but there is nothing there. If there are any other tricks to getting logging happening I’m happy to give them a go.

    I’ve had a couple of tickets open with the hosting company where they have checked logs and have raised limits on the host but report that nothing looks out of place for them.

    Yes, that’s peculiar. Just to make sure I’m up to date here, have you tested this both on a vanilla staging site as well as locally? This behaviour does point towards hosting issues, so it’s strange there aren’t any server errors. It would be interesting if this also happens locally.

    I mentioned the Elementor slowness previously as it was vastly worse as soon as WooCommerce plugin is enabled. Perhaps this is just because Elementor is bloated / heavy and shows up the issue easily. The console errors displayed are with WooCommerce json/ajax/rest links.

    This is quite possible, any performance issues will be amplified by a resource heavy third-party page builder.

    Database issues could be worth exploring further. The error is repeatable on a test vanilla install of WP with a new db. Any tips on where to look for logging there are more than welcome.

    It sounds like you’ve got the important bases covered. Please check this link to enable logging for DOM parsing and Scripts as well: https://woocommerce.com/document/woocommerce-product-search/api/debugging/

    Let us know if this reveals any new information!

    Thread Starter Guy Chapman

    (@guychapman)

    Hi @seanomattic,

    Thanks for your comments. Yes, I tested it on vanilla, staging and production instances on the host and all displayed the error – even the absolutely minimal vanilla installation. Testing on a local dev did not have the issue.

    I went back to my hosting company and asked them to have a further look as I couldn’t see anything in any logs. I also gave them access to WP/WC admin so they could reproduce the error using the WooCommerce Home and Analytics pages. Following that they made the configuration changes listed below to Apache and this seems to have resolved the issue.

    According to them, the Analytics page is considerably heavy and makes 230+ requests and increases the load of the VPS.

    The admins have increased the following VPS limits:
    ServerLimit 4 => 30
    FcgidMaxProcesses 1000 => 1500
    FcgidSpawnScoreUpLimit 10 => 40
    FcgidMaxProcessesPerClass 5 => 15

    So it’s been an epic journey, I’ve optimised a ton of things in the site along the way (that needed to be done anyway so no regrets there).

    It sure looks like there are some optimisation opportunities in the app but at least we found a way out the other end of this, hope all the text in here is of some use to others with similar issues.

    Cheers
    Guy

    Plugin Support Sean O))) a11n

    (@seanomattic)

    Hi @guychapman,

    Thanks for the reply. It’s certainly been a journey to get to this point, we really appreciate your diligence in seeing this through!

    According to them, the Analytics page is considerably heavy and makes 230+ requests and increases the load of the VPS.

    The admins have increased the following VPS limits:
    ServerLimit 4 => 30
    FcgidMaxProcesses 1000 => 1500
    FcgidSpawnScoreUpLimit 10 => 40
    FcgidMaxProcessesPerClass 5 => 15

    That’s interesting, thanks for sharing these details. I’ll bounce this off our developers to see if there are any opportunities for optimization here.

    Much appreciated!

    Thread Starter Guy Chapman

    (@guychapman)

    Thanks @seanomattic,

    I’d be interested in what the Dev team have to say. Even if it’s that these Apache settings always have to be adjusted like this it would be good to know. I searched for a WooCommerce page for any detailed recommendations on this but couldn’t find anything, may have missed it, but it would be great to see a definitive page on recommended settings – even if they are just a minimum starting point.

    Cheers
    Guy

    Plugin Support Thu P. a11n

    (@thup90)

    Hi @guychapman,

    Thanks for your patience while we looked into this issue.

    I’ve filed a request with our developers, you can subscribe to the GH issue for its progress: https://github.com/woocommerce/woocommerce/issues/41131

    I don’t have an ETA of when this will be resolved at this time, however, the report will be the go-to place for any updates from our developers.

    Feel free to get back to us in case you have any additional questions!

    Thread Starter Guy Chapman

    (@guychapman)

    Thanks @thup90, appreciate you logging that. I’ve got a working solution now so all good from this end but it will be good to see if there are any optimisations that come from that GGH issue.

    Cheers,
    Guy

    Having the same issue on multiple websites. Any resolution to this yet?

    Plugin Support ckadenge (woo-hc)

    (@ckadenge)

    Hey @oliverrealize,

    Please start a new thread with your case, so that we don’t mix several troubleshooting sessions in one thread.

    Cheers.

    Thread Starter Guy Chapman

    (@guychapman)

    Hey there @oliverrealize, despite this being marked as resolved and the github request being created, the underlying resource demands of WooCommerce were never resolved. As noted throughout this thread, I just threw more resources at my site, turned off everything I could and moved to less resource hungry components wherever I could.

    Good luck!

Viewing 14 replies - 31 through 44 (of 44 total)
  • You must be logged in to reply to this topic.