3 dolog, amit ellenőrizz a webáruházadban, mielőtt elindul a szezon

Van néhány nap az évben, amikor a webáruházad vagy hoz pénzt, vagy nem: a szezon első hétvégéje. Fekete péntek, a karácsony előtti két hét, a síszezon nyitása, a ballagási időszak: mindegy, melyik a tiéd. A közös bennük az, hogy az a nap nem alkalmas a hibakeresésre.

Ez a cikk a webshop ellenőrzés szezon előtt három legfontosabb pontjáról szól, amit érdemes négy-hat héttel korábban megnézni. Egyik sem "optimalizálás", egyik sem tesz szebbé vagy gyorsabbá semmit. Mindhárom ugyanarra a kérdésre válaszol: mi történik, ha holnap tényleg jönnek.

1. Kibírja-e a tárhely, ha egyszerre sokan vannak bent

A leggyakoribb félreértés, amivel találkozom: "nálam minden rendben, a PageSpeed 95 pont". A PageSpeed egyetlen látogató egyetlen oldalletöltését méri, gyorsítótárból kiszolgálva. Ez egy fontos szám, de semmit nem mond arról, mi lesz száz egyidejű kosárnál.

Azért nem, mert a webáruházban pont az a három oldal nem gyorsítótárazható, ami a pénzt hozza: a kosár, a pénztár és a fiókom. Ezek látogatónként mások, tehát minden egyes megnyitásuk valódi PHP-futást és adatbázis-lekérdezést jelent. Amíg valaki a termékeket nézegeti, a szerver alig dolgozik. Amikor viszont ötvenen egyszerre fizetnének, minden egyes kattintás a szerver nyers erejéből él.

Amit érdemes megnézned:

• Hány párhuzamos PHP-folyamatot ad a csomagod. Ez az a szám, ami a valódi korlát, és a legritkábban szerepel a marketinganyagban. Kérdezd meg a tárhelyszolgáltatót egyenesen. Megosztott tárhelyen ez gyakran 2-10 között van.
• Van-e objektum-gyorsítótár (Redis vagy Memcached). Webáruháznál ez többet ér, mint az oldal-gyorsítótár, mert az ismétlődő adatbázis-lekérdezéseket veszi le a szerverről, pont azokat, amiket a pénztár termel.
• A tavalyi hibanapló. Ha volt már szezonod, a szerver hibanaplójában ott van a válasz: "resource limit reached", 508-as hibák, memóriakifutás. Ha tavaly volt, idén is lesz, csak több.
• Terhelésteszt a kosárra, ne a főoldalra. A főoldalt a gyorsítótár szolgálja ki, azon minden teszt szép eredményt ad. Az igazi mérés az, amikor a kosár URL-jét terheled.

Ha a mérés azt mutatja, hogy szűk a keret, annak két megoldása van: nagyobb csomag, vagy kevesebb felesleges munka a szerveren. A második gyakran olcsóbb. Egy webáruházban sokszor tíz-tizenöt olyan bővítmény fut, amiből kettőre van szükség.

2. Ma is működik-e a fizetés, a futár és a levél

Ez a pont unalmasan hangzik, és pont ezért marad ki. Ha a boltod két éve él, akkor két éve senki nem nézte meg, hogy a fizetési átjáró kulcsai érvényesek-e még.

Amit én végigcsinálok egy szezon előtt:

• Egy valódi tesztrendelés, valódi kártyával. Nem a szolgáltató homokozójában, hanem élesben, egy elrejtett, 1 lejes termékkel, amit utána visszautalok magamnak. A homokozó azt teszteli, hogy a kód jó-e. Az éles rendelés azt teszteli, hogy a beállításaid jók-e, és a kettő nem ugyanaz.
• A fizetési szolgáltató felülete. Barion, SimplePay, euplatesc, BT iPay: a kulcsok, tanúsítványok és webhook-címek lejárnak vagy elévülnek. A szolgáltató kiküldi róla az értesítőt, csak épp arra az e-mail-címre, amit a bolt indulásakor adtál meg.
• A futárszolgálat-integráció. Fan Courier, Sameday, GLS, Packeta: generálj egy valódi fuvarlevelet. Az API-k verziót váltanak, a régi integráció pedig sokszor némán hal meg: nincs hibaüzenet, egyszerűen nem keletkezik fuvarlevél.
• A rendelés-visszaigazoló levél. Ez a leggyakoribb néma hiba, amivel találkozom. A WordPress alapból a szerver mail() függvényével küld, hitelesítés nélkül. A Gmail és az Outlook pedig az ilyen levelet ma már spam-be teszi vagy egyszerűen eldobja. A saját oldalamon ezt végigcsináltam: hitelesített SMTP, SPF, DKIM, DMARC, és a végén egy mail-tester mérés 10/10-re. Amíg ez nincs meg, a rendelés-visszaigazolás lutri. A vásárló ilyenkor nem arra gondol, hogy a leveled akadt el, hanem arra, hogy a rendelése nem ment át.
• Az űrlapok elfogadás-jelölői. A saját kapcsolati űrlapomon találtam meg, hogy egy rosszul beállított adatvédelmi jelölőnégyzet letiltja a küldés gombot. Nincs hibaüzenet, egyszerűen nem történik semmi. A pénztárnál ugyanez a kockázat áll fenn az ÁSZF-elfogadásnál.
• A készlet. Állítsd egy termék készletét 1-re, rendeld meg, és nézd meg, mi történik a másodiknál. A szezon közepén derül ki a legrosszabbkor, hogy a bolt elad olyat, ami nincs.

3. Ami a szezon közepén magától megváltozik

A WordPress és a bővítmények alapértelmezés szerint maguktól frissülnek. Ez tizenegy hónapban jó dolog: a biztonsági javítások időben megérkeznek. A szezon két hetében viszont épp ellenkezőleg: egy csütörtök éjjeli automatikus frissítés péntek reggelre megbonthatja a pénztárat, és te akkor találkozol vele először, amikor az első vásárló ír.

Amit ilyenkor csinálok:

• Tudatos frissítési kör a szezon előtt négy héttel. Előbb másolaton, nem élesben. Utána egy teljes tesztrendelés.
• Fagyasztási időszak. A szezont megelőző két héttől a végéig kikapcsolom az automatikus frissítést azoknál a bővítményeknél, amik a pénztárhoz, a fizetéshez vagy a szállításhoz nyúlnak. A biztonsági frissítés kivétel, azt kézzel telepítem, ellenőrzés után.
• Visszaállítási próba. A mentés addig nem mentés, amíg egyszer vissza nem állt. Egy másolaton fél óra kipróbálni, és ez az egyetlen módja annak, hogy megtudd: a mentésed tényleg tartalmazza-e az adatbázist is, nem csak a fájlokat.
• Legyen kit hívni. A szezon előtt tisztázd, ki az, aki egy szombat délutáni hibánál elérhető, és hogyan. Ha ez nincs kimondva, akkor nincs.

Amit viszont NE csinálj a szezon előtt

Ez legalább annyira fontos, mint a lista eleje. A szezon előtti négy-hat hét nem a jó időpont arra, hogy:

• új dizájnt vagy témát tegyél az oldalra,
• tárhelyet vagy domaint költöztess,
• fizetési szolgáltatót válts,
• nagy bővítményeket cserélj le (sablonkezelő, készlet-szinkron, számlázó).

Mindegyik jó ötlet lehet – februárban. A szezon előtt minden változtatás kockázat, aminek a hozama a szezon után jelentkezik, a kockázata viszont a szezon alatt.

Webshop ellenőrzés szezon előtt: a háromsoros változat

Ha most nincs időd a részletekre, ennyi is elég egy kezdésnek:

• Kérdezd meg a tárhelyszolgáltatót, hány párhuzamos PHP-folyamatot kapsz, és nézd meg a tavalyi hibanaplót.
• Adj le egy valódi, 1 lejes tesztrendelést valódi kártyával, és nézd meg, megérkezik-e a visszaigazoló levél. Nézd meg a spam mappát is.
• A szezon előtt két héttel állítsd le az automatikus frissítéseket, és próbáld ki egyszer, hogy a mentés tényleg visszaáll-e.

Ha ezt a hármat végigcsinálod, a szezon legvalószínűbb hibái közül a legtöbbet már kiszűrted. A többiről szól a havidíjas üzemeltetés, vagyis arról, hogy ezt ne szezononként egyszer, kapkodva kelljen megcsinálni. Ha kíváncsi vagy, miért nem elég egy oldalt egyszer elkészíteni, arról külön írtam: miért kell WordPress karbantartás.

Ha webáruházat indítanál vagy átveszel egy meglévőt, az árak itt vannak. Vagy írj néhány mondatot arról, hol tartasz, és megmondom, mit néznék meg először.