The Plugin is to heavy and slow down the website significantly
-
Hello, the plugin is well tested and its too heavy and slowdown the website page load, speed and overall performance. tested in many WordPress sites and its noticeably heavy
-
Hi @chicsouq
Glad to see you testing out our solution!
Without more information on your exact setup this is going to be difficult for us to troubleshoot. I just had our team generate two different lighthouse reports on some test sites we have, and before installing StellarPay, the the sites scored a 95. After installing, they scored a 94. So we do see some impact, but not enough to justify big moves to mitigate things.
If you have more details about your setup that is seeing issues, we’re happy to dig in and see how the StellarPay codebase might not be playing well with your system.
Are the performance issues you’re seeing primarily on the front end or for logged-out users, or more in the back end for site administrators? Since our solution heavily relies on Stripe itself for much of the data that it displays on the back end, factors like how many products are in your Stripe account as well as phyical distance from the Stripe servers can play a part in sluggishness.Either way, we’re happy to dig in and see what we can do to help.
Hello, Thanks for you fast replay. i have did the exact same thing and run some tests. here is a reports for example: https://www.debugbear.com/test/website-speed/vjZ6TmoI/overview?metric=largestContentfulPaint#request-waterfall
this happen mainly when you navigate to the plugin dashboard. the performance start dropping. i have run an analysis with query monitor and spot and increase activating in the plugin’s dash. i noticed that the appearance page keep in loading mode which may increase this unwanted activity. Plus i have created a simple snippet code that block some plug features and the plugin seems stable nowAfter extensive testing i come to a conclusion that the plugin is conflicting with the caching plugin tested with wprocket, litespeed cache, w3 cache an wp super cache. But its working perfectly fine with WP Fastest Cache. I Have even tried to disactivate all the optimization in the sited plugins but the server slow response persisted. I have also switched to default theme same issue. Your plugin works fluently in non cached envirement
after further investigation is have discovered that the doc in inspect element / network : header request call no cache so the cache is inactive everywhere in the website when your plugin is activated :
Response Header :
alt-svc
h3=":443"; ma=2592000, h3-29=":443"; ma=2592000, h3-Q050=":443"; ma=2592000, h3-Q046=":443"; ma=2592000, h3-Q043=":443"; ma=2592000, quic=":443"; ma=2592000; v="43,46"
cache-control
no-cache, must-revalidate, max-age=0, no-store, private
content-encoding
br
content-security-policy
upgrade-insecure-requests
content-type
text/html; charset=UTF-8
date
Sun, 26 Oct 2025 18:26:21 GMT
expires
Wed, 11 Jan 1984 05:00:00 GMT
link
<https://chicsouq.com/wp-json/>; rel="https://api.w.org/"
link
<https://chicsouq.com/wp-json/wp/v2/pages/30367>; rel="alternate"; title="JSON"; type="application/json"
panel
hpanel
platform
hostinger
server
LiteSpeed
set-cookie
wcboost_wishlist_hash=924ac1585f2831c355e73082b863fdc4-ar%3A%3Acfcd208495d565ef66e7dff9f98764da; path=/; secure
set-cookie
wcboost_wishlist_hash=924ac1585f2831c355e73082b863fdc4-ar%3A%3Acfcd208495d565ef66e7dff9f98764da; path=/; secure
vary
Accept-Encoding
x-litespeed-cache-control
no-cache
x-litespeed-tag
231_front,231_URL.6666cd76f96956469e7be39d750cc7d9,231_F,231_Po.30367,231_PGS,231_,231_MIN.dadf23b3fd22b238d34012605e135968.css
x-powered-by
PHP/8.2.28
request header :
:authority
chicsouq.com
:method
GET
:path
/
:scheme
https
accept
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
accept-encoding
gzip, deflate, br, zstd
accept-language
en-US,en;q=0.9
cache-control
no-cache
cookie
wcboost_wishlist_hash=924ac1585f2831c355e73082b863fdc4-ar%3A%3Acfcd208495d565ef66e7dff9f98764da; sbjs_migrations=1418474375998%3D1; sbjs_current_add=fd%3D2025-10-26%2017%3A11%3A39%7C%7C%7Cep%3Dhttps%3A%2F%2Fchicsouq.com%2F%7C%7C%7Crf%3D%28none%29; sbjs_first_add=fd%3D2025-10-26%2017%3A11%3A39%7C%7C%7Cep%3Dhttps%3A%2F%2Fchicsouq.com%2F%7C%7C%7Crf%3D%28none%29; sbjs_current=typ%3Dtypein%7C%7C%7Csrc%3D%28direct%29%7C%7C%7Cmdm%3D%28none%29%7C%7C%7Ccmp%3D%28none%29%7C%7C%7Ccnt%3D%28none%29%7C%7C%7Ctrm%3D%28none%29%7C%7C%7Cid%3D%28none%29%7C%7C%7Cplt%3D%28none%29%7C%7C%7Cfmt%3D%28none%29%7C%7C%7Ctct%3D%28none%29; sbjs_first=typ%3Dtypein%7C%7C%7Csrc%3D%28direct%29%7C%7C%7Cmdm%3D%28none%29%7C%7C%7Ccmp%3D%28none%29%7C%7C%7Ccnt%3D%28none%29%7C%7C%7Ctrm%3D%28none%29%7C%7C%7Cid%3D%28none%29%7C%7C%7Cplt%3D%28none%29%7C%7C%7Cfmt%3D%28none%29%7C%7C%7Ctct%3D%28none%29; sbjs_udata=vst%3D1%7C%7C%7Cuip%3D%28none%29%7C%7C%7Cuag%3DMozilla%2F5.0%20%28Windows%20NT%2010.0%3B%20Win64%3B%20x64%29%20AppleWebKit%2F537.36%20%28KHTML%2C%20like%20Gecko%29%20Chrome%2F141.0.0.0%20Safari%2F537.36; wp-wpml_current_language=ar; catalog_view=grid-4; woocommerce_recently_viewed=39121%7C39021%7C39457; sbjs_session=pgs%3D57%7C%7C%7Ccpg%3Dhttps%3A%2F%2Fchicsouq.com%2F
pragma
no-cache
priority
u=0, i
sec-ch-ua
"Google Chrome";v="141", "Not?A_Brand";v="8", "Chromium";v="141"
sec-ch-ua-mobile
?0
sec-ch-ua-platform
"Windows"
sec-fetch-dest
document
sec-fetch-mode
navigate
sec-fetch-site
none
sec-fetch-user
?1
upgrade-insecure-requests
1
user-agent
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36Hello there, i would like to say we had the same issue with cache. he is there exact reason why your plugin has conflict with caching. The
Cache‑Controlheader is set tono‑cache, must‑revalidate, max‑age=0, no‑store, privateand thePragmaheader isno‑cache. StallerPay registers aDeletePaymentMethodcontroller on every front‑end page viaHooks::addAction('wp', DeletePaymentMethod::class, '__invoke', 9)in the WooCommerce service provider. When that controller runs, it checks whether thedelete-payment-methodquery variable is present. If it isn’t present, it callswc_nocache_headers()
solution?<?php
// Disable StallerPay’s DeletePaymentMethod hook.
// Note: no leading backslash in the class; double backslashes escape the backslash characters in the string.
add_filter(
‘stellarpay_disable_hook-wp:StellarPay\Integrations\WooCommerce\Stripe\Controllers\DeletePaymentMethod@__invoke’,
‘__return_true’
);// Optional: re‑implement the delete-payment-method logic without sending no‑cache headers
add_action(‘wp’, function () {
// Only handle actual delete‑payment‑method requests
if (!isset($GLOBALS[‘wp’]->query_vars[‘delete-payment-method’])) {
return;
}// Uncomment the next line only if you still want to bypass caching on the delete page: // wc_nocache_headers(); $token_id = (int) get_query_var('delete-payment-method'); $nonce = isset($_REQUEST['_wpnonce']) ? sanitize_text_field(wp_unslash($_REQUEST['_wpnonce'])) : ''; $token = WC_Payment_Tokens::get($token_id); if ( empty($nonce) || !$token || '\\StellarPay\\Integrations\\WooCommerce\\Stripe\\Constants'::GATEWAY_ID !== $token->get_gateway_id('edit') || !wp_verify_nonce($nonce, 'delete-payment-method-' . $token_id) || get_current_user_id() !== $token->get_user_id() ) { return; } try { $service = '\\StellarPay\\PaymentGateways\\Stripe\\Services\\PaymentMethodService'; if (function_exists('StellarPay\\Core\\container')) { $service_instance = StellarPay\Core\container($service); } else { $service_instance = new $service(); } $service_instance->detachPaymentMethod($token->get_token()); } catch (\Exception $e) { wc_add_notice( esc_html__('We are sorry, but we could not delete your payment method at this time. Please try again shortly.', 'stellarpay'), 'error' ); wp_safe_redirect(wc_get_account_endpoint_url('payment-methods')); exit; }}, 9);
You must be logged in to reply to this topic.