EAGLE SOLUTIONS
Pe scurt: Înainte de sezonul aglomerat al unui magazin online verifică, cu patru-șase săptămâni înainte, trei lucruri: dacă găzduirea rezistă la coș sub încărcare, dacă plata, curierul și e-mailul de confirmare chiar funcționează cu o comandă de test reală, și dacă actualizările automate sunt oprite temporar.
O verificare magazin online cu patru-șase săptămâni înainte de sezon previne exact asta. Sunt câteva zile în an în care magazinul tău online ori aduce bani, ori nu: primul weekend al sezonului. Black Friday, cele două săptămâni dinaintea Crăciunului, deschiderea sezonului de schi, perioada banchetelor. Nu contează care este al tău. Ce au în comun este că ziua aceea nu este potrivită pentru depanare.
Articolul acesta este despre trei lucruri pe care merită să le verifici cu patru-șase săptămâni înainte de sezon. Niciunul nu este "optimizare" și niciunul nu face nimic mai frumos sau mai rapid. Toate trei răspund la aceeași întrebare: ce se întâmplă dacă mâine chiar vin.
1. Verificare magazin online: rezistă găzduirea dacă sunt mulți deodată pe site
Cea mai frecventă neînțelegere pe care o întâlnesc: "la mine e totul în regulă, PageSpeed-ul e 95". PageSpeed măsoară o singură încărcare de pagină a unui singur vizitator, servită din cache. Este un număr important, dar nu spune nimic despre ce se întâmplă la o sută de coșuri simultane.
Nu spune, pentru că în magazinul online tocmai cele trei pagini care aduc banii nu pot fi puse în cache: coșul, finalizarea comenzii și contul meu. Acestea diferă de la vizitator la vizitator, deci fiecare deschidere a lor înseamnă execuție PHP reală și interogări în baza de date. Cât timp cineva se uită la produse, serverul abia lucrează. Când însă cincizeci de oameni vor să plătească deodată, fiecare clic trăiește din forța brută a serverului.
Ce merită să verifici:
- Câte procese PHP paralele îți dă pachetul. Acesta este numărul care reprezintă limita reală și cel mai rar apare în materialele de marketing. Întreabă direct furnizorul de găzduire. Pe găzduire partajată este deseori între 2 și 10.
- Dacă există cache de obiecte (Redis sau Memcached). La un magazin online valorează mai mult decât cache-ul de pagină, pentru că ia de pe server interogările repetate din baza de date, adică exact cele produse de finalizarea comenzii.
- Jurnalul de erori de anul trecut. Dacă ai avut deja un sezon, răspunsul este acolo, în jurnalul de erori al serverului: "resource limit reached", erori 508, depășiri de memorie. Dacă a fost anul trecut, va fi și anul acesta, doar mai mult.
- Test de încărcare pe coș, nu pe prima pagină. Prima pagină este servită din cache, acolo orice test dă un rezultat frumos. Măsurătoarea adevărată este atunci când încarci URL-ul coșului.
Dacă măsurătoarea arată că limita este strâmtă, există două soluții: un pachet mai mare, sau mai puțină muncă inutilă pe server. A doua este deseori mai ieftină. Într-un magazin online rulează de multe ori zece-cincisprezece plugin-uri din care ai nevoie de două.
2. Funcționează și astăzi plata, curierul și e-mailul
Punctul acesta sună plictisitor și tocmai de aceea rămâne pe dinafară. Dacă magazinul tău trăiește de doi ani, atunci de doi ani nimeni nu a verificat dacă cheile procesatorului de plăți mai sunt valabile.
Ce fac eu înainte de un sezon:
- O comandă de test reală, cu card real. Nu în sandbox-ul furnizorului, ci în producție, cu un produs ascuns de 1 leu, pe care apoi mi-l returnez. Sandbox-ul testează dacă este bun codul. Comanda reală testează dacă sunt bune setările tale, iar cele două nu sunt același lucru.
- Interfața procesatorului de plăți. Barion, SimplePay, euplatesc, BT iPay: cheile, certificatele și adresele webhook expiră sau se învechesc. Furnizorul trimite notificare despre asta, doar că pe adresa de e-mail pe care ai dat-o la lansarea magazinului.
- Integrarea cu curierul. Fan Courier, Sameday, GLS, Packeta: generează un AWB real. API-urile schimbă versiunea, iar integrarea veche moare deseori în tăcere: fără mesaj de eroare, pur și simplu nu se mai generează AWB.
- E-mailul de confirmare a comenzii. Aceasta este cea mai frecventă eroare tăcută pe care o întâlnesc. WordPress trimite implicit cu funcția
mail()a serverului, fără autentificare, iar Gmail și Outlook pun astăzi un asemenea e-mail în spam sau pur și simplu îl aruncă. Pe propriul site am dus asta până la capăt: SMTP autentificat, SPF, DKIM, DMARC, iar la final o măsurătoare mail-tester de 10/10. Până nu ai asta, confirmarea comenzii este loterie. Clientul nu se gândește că e-mailul tău s-a blocat, crede că nu i-a intrat comanda. - Bifele de acceptare din formulare. Pe propriul formular de contact am descoperit că o casetă de acceptare GDPR setată greșit dezactivează butonul de trimitere. Nimic nu dă eroare, nimic nu semnalează, pur și simplu nu se întâmplă nimic. La finalizarea comenzii același risc există la acceptarea termenilor.
- Stocul. Pune stocul unui produs pe 1, comandă-l, și uită-te ce se întâmplă la al doilea. În mijlocul sezonului se descoperă în cel mai prost moment că magazinul vinde ceva ce nu există.
3. Ce se schimbă singur în mijlocul sezonului
WordPress și plugin-urile se actualizează singure în mod implicit. În unsprezece luni din an este un lucru bun: corecțiile de securitate ajung la timp. În cele două săptămâni de sezon însă este exact invers: o actualizare automată de joi noaptea poate strica finalizarea comenzii până vineri dimineață, iar tu te întâlnești cu ea prima dată când îți scrie primul client.
Ce fac în astfel de cazuri:
- O rundă conștientă de actualizări cu patru săptămâni înainte de sezon. Întâi pe o copie, nu în producție. Apoi o comandă de test completă.
- Perioadă de înghețare. Din cele două săptămâni dinaintea sezonului până la final opresc actualizarea automată la plugin-urile care ating finalizarea comenzii, plata sau livrarea. Actualizarea de securitate este excepție, pe aceea o fac manual, după verificare.
- Test de restaurare. Backupul nu este backup până nu a fost restaurat o dată. Pe o copie durează o jumătate de oră și este singurul mod prin care afli dacă backupul chiar conține și baza de date, nu doar fișierele.
- Să ai pe cine suna. Înainte de sezon clarifică cine este disponibil la o problemă de sâmbătă după-amiaza și cum. Dacă asta nu este spusă, atunci nu există.
Ce să NU faci înainte de sezon
Este cel puțin la fel de important ca începutul listei. Cele patru-șase săptămâni dinaintea sezonului nu sunt momentul potrivit ca:
- să pui un design sau o temă nouă pe site,
- să muți găzduirea sau domeniul,
- să schimbi procesatorul de plăți,
- să înlocuiești plugin-uri mari (page builder, sincronizare de stoc, facturare).
Fiecare poate fi o idee bună în februarie. Înainte de sezon orice modificare este un risc al cărui câștig apare după sezon, dar al cărui risc apare în timpul lui.
Varianta în trei rânduri
Dacă acum nu ai timp de detalii, și atât este suficient pentru un început:
- Întreabă furnizorul de găzduire câte procese PHP paralele primești și uită-te în jurnalul de erori de anul trecut.
- Plasează o comandă de test reală de 1 leu cu card real și verifică dacă ajunge e-mailul de confirmare, inclusiv în folderul spam.
- Cu două săptămâni înainte de sezon oprește actualizările automate și încearcă o dată dacă backupul chiar se restaurează.
Dacă faci aceste trei lucruri, ai filtrat deja cele mai probabile erori de sezon. Restul ține de mentenanța lunară, ca să nu fie nevoie să faci asta o dată pe sezon, în grabă. Dacă vrei să știi de ce nu este suficient să faci un site o singură dată, am scris separat despre asta: de ce e nevoie de mentenanță WordPress.
Dacă ai lansa un magazin online sau ai prelua unul existent, prețurile sunt aici. Sau scrie-mi câteva rânduri despre unde ești acum, și îți spun ce aș verifica primul.
