El client fa clic al botó de comanda, el filador s’executa i la finestra de la passarel·la apareix uns segons després. Aquesta pausa sol produir-se abans que el client arribi al proveïdor de pagament. És possible que WooCommerce encara estigui validant camps, recalculant totals, creant una comanda o sol·licitant la configuració de la passarel·la.
Mesureu la sol·licitud de pagament per separat de la finestra de pagament. Culpar la passarel·la massa aviat pot portar a canviar de proveïdor mentre es mantingui el mateix coll d’ampolla de WordPress.
Definiu l’interval d’espera exacte
Utilitzeu el sandbox de la passarel·la o el mode de prova autoritzat. Inicieu el rendiment del navegador i la gravació de la xarxa immediatament abans de l’acció final de pagament.
Tingueu en compte quina sol·licitud comença l’espera. Depenent de la integració de la compra, pot ser una trucada a l’API de WooCommerce Store, ?wc-ajax=checkout, una actualització AJAX o un punt final del proveïdor.
Registra el temps de resposta, l’estat i si el navegador espera una resposta del servidor o passa temps executant JavaScript després. No captureu números de targeta, dades personals o fitxes d’autenticació en proves compartides.
Compareu les actualitzacions de pagament amb l’enviament final
WooCommerce pot tornar a calcular el pagament quan canvia l’adreça, el mètode d’enviament o el mètode de pagament. Si aquestes actualitzacions ja són lentes, el clic final només pot exposar un problema de totals més ampli.
Prova:
- càrrega inicial de pagament;
- canvi de codi postal o de país;
- selecció del mètode d’enviament;
- sol·licitud de cupó;
- Presentació final de la comanda.
Una transició lenta pot identificar el ganxo o el servei extern implicat. Desactiveu les regles sense impostos ni d’enviament a la producció només per provar; utilitzar la posada en escena amb una configuració representativa.
Inspeccioneu PHP i temps de la base de dades
Utilitzeu el seguiment d’aplicacions o un perfilador de WordPress controlat per inspeccionar el punt final lent. Busqueu consultes repetides de producte/meta, recàlcul del carretó, regles de subscripció, cerques multilingües i camps de pagament personalitzats.
Relacioneu la marca de temps de la traça amb l’evidència PHP-FPM i MySQL. Una resposta lenta pot incloure la cua dels treballadors abans que comenci WordPress.
No afegiu un índex a partir d’una recomanació genèrica. Captureu la consulta real i proveu els canvis d’esquema en una còpia de la base de dades.
Cerca trucades externes abans del pagament
Les cotitzacions d’enviament, els serveis fiscals, les comprovacions de frau, la validació d’adreces i la configuració del testimoni de passarel·la poden fer sol·licituds remotes abans que s’obri la IU de pagament. Un servei lent o inabastable pot retenir un treballador PHP fins que s’acabi el temps d’espera.
Inspeccioneu les traces de trucades sortints i els registres del proveïdor. Definiu temps d’espera conservadors i comportaments alternatius compatibles. No ometeu un pas de frau o d’autenticació necessari per a la velocitat.
A la memòria cau només les dades de referència estables quan la integració ho permeti. Un pressupost en directe o un testimoni de pagament no és un candidat normal a la memòria cau.
Comproveu JavaScript i optimització de pagament
JavaScript endarrerit o combinat pot provocar actualitzacions repetides de pagament o inicialitzar el component de pagament tard. Reviseu els errors de la consola i la cascada de xarxa per trobar scripts de passarel·la duplicats.
Desactiva temporalment només el retard de JavaScript en la posada en escena. Si la finestra s’obre normalment, exclou la cadena de dependència verificada més petita en lloc de tots els scripts.
La configuració del consentiment també ha de permetre el codi de pagament essencial segons la configuració aprovada. Prova el consentiment opcional acceptat i rebutjat sense reclassificar la funcionalitat de pagament casualment.
Reviseu ganxos i correus electrònics personalitzats
El codi personalitzat adjunt a la creació de comandes pot realitzar trucades CRM remotes, generar PDF o enviar correu electrònic de manera sincrònica. Aquest treball pot passar abans que el navegador rebi el resultat.
Mou el processament posterior a la comanda no essencial a una acció de fons fiable només després d’assegurar-te que és idempotent i supervisat. L’estat del pagament, l’estoc i la confirmació del client han de ser coherents si es torna a provar una feina en segon pla.
No editeu mai un tema principal o un complement de passarel·la directament.
Verifiqueu el resultat comercial
Repetiu les compres de prova autoritzades amb les combinacions habituals d’enviament, impostos, cupó i pagament. Confirmeu que s’ha creat una comanda, que l’estoc canvia una vegada, la passarel·la rep un intent i apareix la pàgina de confirmació.
Mesureu l’interval des del clic fins a la finestra de pagament, no només la càrrega de la pàgina completa. Superviseu els errors de pagament i les comandes completades després del llançament.
Sol·liciteu reparació urgent quan els clients abandonin al spinner, apareguin comandes duplicades o el retard sigui intermitent. Comenceu amb segells de temps, mètode de prova i evidència de sol·licitud desinfectada; utilitzeu un canal segur per accedir-hi posteriorment.