Imagini, PHP și alte câștiguri de viteză

Modulul 6: Viteză · Timp de citire: 9 minute

Obiectiv de învățare: După această lecție veți putea aplica cele mai importante câștiguri de viteză rămase și veți putea măsura efectul acestora.

Concepte-cheie: optimizarea imaginilor, WebP și AVIF, lazy loading, imaginea LCP, fetchpriority, versiunea PHP, curățarea bazei de date (revizii, transients, autoload), WP-Cron, cron real, DISABLE_WP_CRON, fonturi externe, Heartbeat

Lucrați în ordinea corectă

După un cache de pagină (lecția 6.2), acestea sunt câștigurile cu cel mai mare randament, cam în ordinea efortului comparativ cu efectul:

1. imagini puse la punct;
2. o versiune PHP actuală;
3. mai puține componente externe și module (pluginuri) grele;
4. o bază de date curățată;
5. sarcini programate pe un cron real.

Măsurați înainte și după fiecare pas (lecția 6.1), altfel nu știți ce a ajutat. Și faceți un singur lucru pe rând.

Imaginile: cel mai mare câștig în browser

Pe majoritatea paginilor, imaginile reprezintă cea mai mare parte din ceea ce descarcă un vizitator. Ceea ce ați învățat în lecția 4.4 dă roade aici:

• Dimensiunea corectă: nu încărcați imagini mai mari decât este necesar și lăsați WordPress să ofere formate mai mici prin srcset.
• Compresie și format: WebP este de obicei considerabil mai mic decât JPEG la aceeași calitate; AVIF este adesea și mai mic. Un modul (plugin) poate converti imaginile existente și poate oferi versiunea mai mică browserelor care o suportă. Verificați dacă conversia se face pe serverul dumneavoastră sau la un serviciu extern.
• Lazy loading, dar nu pentru tot. WordPress adaugă automat loading="lazy" imaginilor, cu excepția primei imagini mari din partea de sus. Acea imagine este adesea elementul LCP (lecția 6.1): cea mai mare bucată de conținut pe care vizitatorul o vede primul. Dacă aceasta este încărcată cu lazy loading, browserul tocmai atunci va aștepta cu ea, iar LCP-ul dumneavoastră se înrăutățește. De aceea WordPress oferă adesea candidatului LCP atributul fetchpriority="high", astfel încât browserul să îl preia primul.

<img src="hero-1536x864.webp" width="1536" height="864"
     fetchpriority="high" alt="Atelier cu biciclete aliniate">
<img src="team-768x512.webp" width="768" height="512"
     loading="lazy" alt="Echipa în fața magazinului">

O capcană: unele teme, constructoare de pagini și module (pluginuri) de optimizare aplică lazy loading și pe prima imagine, sau încarcă imaginea mare ca fundal prin CSS (aceasta este descoperită mai târziu). În PageSpeed Insights vedeți la secțiunea LCP care este elementul respectiv și dacă este încărcat cu lazy loading.

PHP: viteză gratuită

Fiecare versiune mare nouă de PHP este mai rapidă decât cea anterioară, iar site-urile WordPress beneficiază direct de acest lucru, fără să schimbați nimic la site-ul dumneavoastră. În plus, versiunile vechi nu mai primesc actualizări de securitate (lecția 8.4). Dacă treceți la o versiune nouă, verificați dacă modulele (pluginurile) și tema dumneavoastră o suportă și faceți acest lucru de preferință mai întâi într-un mediu de testare (staging).

La setările PHP, aruncați o privire și la:

• OPcache: este activat implicit la majoritatea furnizorilor de găzduire. O consecință: un fișier PHP modificat poate dura puțin până când PHP folosește noua versiune.
• memory_limit: prea mic produce erori la pagini grele; foarte mare nu face site-ul dumneavoastră mai rapid.

Componente externe și module (pluginuri) grele

Fiecare componentă de la o altă parte reprezintă o conexiune suplimentară și un timp de așteptare suplimentar: fonturi de la un serviciu extern, un videoclip încorporat, un widget de chat, coduri de măsurare, butoane de social media, o hartă. Întrebări pentru fiecare componentă:

• Este necesar? Un videoclip pe care aproape nimeni nu îl redă poate fi înlocuit și cu o imagine cu un link.
• Poate fi local? Fonturile pot fi de obicei puse pe propriul dumneavoastră server (cu un modul sau prin theme.json la o temă cu blocuri). Aceasta economisește o conexiune și este mai bine pentru confidențialitatea dumneavoastră (lecția 9.3).
• Poate fi mai târziu? Un widget de chat sau un videoclip poate fi încărcat abia după un clic.

La module (pluginuri), măsurarea ajută cu X-Ray (la găzduire cu CloudLinux) sau cu un modul precum Query Monitor (activați-l temporar, vizibil doar pentru administratori). Acestea arată ce modul costă cele mai multe interogări în baza de date sau cel mai mult timp.

Curățarea bazei de date

O bază de date crește cu lucruri pe care nu le vedeți:

• Revizii (lecția 4.1): fiecare versiune salvată a fiecărei pagini. Limitați-le cu WP_POST_REVISIONS și curățați-le pe cele vechi.
• Comentarii spam și din coșul de gunoi, și articole din coșul de gunoi.
• Transients: date temporare ale modulelor (pluginurilor) în wp_options, care uneori nu sunt curățate.
• Autoload: opțiunile din wp_options cu autoload activat sunt încărcate dintr-o dată la fiecare cerere. Modulele pe care le-ați eliminat deja de mult timp lasă uneori cantități mari de date acolo. Sănătate site (lecția 5.4) avertizează dacă datele autoload sunt foarte mari.
• Tabele de jurnal (log) ale modulelor (pluginurilor) (statistici, jurnale de securitate, jurnale de e-mail) care nu sunt niciodată golite.

Curățarea se poate face cu un modul de curățare, cu WP-CLI (wp transient delete --expired, wp post delete $(wp post list --post_type=revision --format=ids) --force), sau cu funcția de optimizare din phpMyAdmin pentru tabelele propriu-zise. Întotdeauna faceți mai întâi o copie de siguranță. Nu eliminați nimic despre care nu știți ce este.

Sarcini programate: WP-Cron

WordPress are sarcini care trebuie să ruleze la un anumit moment: publicarea unui articol programat, verificarea actualizărilor, funcționarea unui modul de backup. Acesta se numește WP-Cron. Implicit, WP-Cron nu rulează la un anumit ceas, ci la o vizită: la fiecare cerere de pagină, WordPress verifică dacă există o sarcină pregătită. Două dezavantaje:

• La puțini vizitatori, sarcinile rulează prea târziu (un articol programat apare abia la prima vizită ulterioară).
• La mulți vizitatori, se verifică foarte des, iar o sarcină grea poate încetini tocmai pagina unui vizitator.

Mai bine: dezactivați WP-Cron la vizite și lăsați un cronjob real al serverului să îl ruleze la fiecare cinci sau zece minute. În wp-config.php (deasupra liniei „stop editarea”):

define( 'DISABLE_WP_CRON', true );

Și în ecranul de cron al panoului dumneavoastră de găzduire, o sarcină, la fiecare 10 minute:

*/10 * * * *  /usr/local/bin/php /home/gebruiker/domains/example.com/public_html/wp-cron.php >/dev/null 2>&1

Calea către PHP și către site-ul dumneavoastră diferă în funcție de furnizorul de găzduire; consultați manualul panoului dumneavoastră. Sau folosiți WP-CLI: wp cron event run --due-now. Verificați ulterior în Sănătate site că nu există sarcini programate întârziate.

Heartbeat și panoul de administrare

Panoul de administrare al WordPress comunică, atât timp cât este deschis, cu serverul la fiecare 15 până la 60 de secunde (Heartbeat): pentru salvarea automată, pentru a semnala că altcineva editează același articol și pentru notificări. Dacă lăsați zece file deschise cu panoul de administrare toată ziua, acestea reprezintă mii de cereri. Închideți filele pe care nu le folosiți. Unele module (pluginuri) de cache pot încetini Heartbeat; dezactivarea completă nu este necesară și strică salvarea automată.

Rezumat

• După cache-ul de pagină: imagini, versiune PHP, componente externe și module (pluginuri), bază de date, cron. Măsurați înainte și după, un pas pe rând.
• Lazy loading pentru tot, cu excepția imaginii mari din partea de sus; aceasta primește de preferință fetchpriority="high".
• O versiune PHP mai nouă este viteză gratuită, cu condiția ca modulele (pluginurile) dumneavoastră să poată ține pasul.
• Curățați reviziile, transients, spam-ul și datele autoload mari, întotdeauna cu o copie de siguranță.
• Puneți WP-Cron pe un cronjob real cu DISABLE_WP_CRON și o sarcină în panoul dumneavoastră.

Test (quiz)

Exercițiu

Exercițiu A6.3: Lazy loading și formate pe pagina dumneavoastră principală. Introduceți adresa site-ului dumneavoastră. Programul citește pagina principală și analizează imaginile: prima imagine mare nu are loading="lazy" (și de preferință are fetchpriority="high"), imaginile de mai jos au lazy loading și ce parte dintre imagini este WebP sau AVIF?

Exercițiu D6.3: Înainte și după. Măsurați o pagină a site-ului dumneavoastră de trei ori în PageSpeed Insights (mobil) și notați valoarea medie a LCP, INP (sau valoarea de laborator Total Blocking Time dacă nu există date de teren), CLS și TTFB din exercițiul A6.1. Apoi efectuați o îmbunătățire din această lecție (imagini, versiune PHP, eliminarea unei componente externe, curățarea bazei de date sau un cron real). Măsurați din nou de trei ori și notați noile valori. Descrieți ce ați făcut și dacă diferența este mai mare decât fluctuația normală dintre măsurători.

Lecturi suplimentare

Aceste articole descriu pașii în panourile WebOké; în alte panouri funcționează similar.

• Manual DirectAdmin 14.1: Alegerea versiunii de PHP (Select PHP version)
• Manual DirectAdmin 12.7: Verificarea, repararea și optimizarea unei baze de date
• Manual DirectAdmin 15.1: Cron Jobs: rularea automată a sarcinilor
• Crearea unui cronjob sau a unei sarcini programate (și ce să faceți dacă nu se execută)
• Manual DirectAdmin 17.4: X-Ray: depistarea paginilor lente
• Conectarea WP-Cron la cron-ul de sistem (developer.wordpress.org, Engleză): https://developer.wordpress.org/plugins/cron/hooking-wp-cron-into-the-system-task-scheduler/
• Lazy loading și LCP (web.dev, Engleză): https://web.dev/articles/lcp-lazy-loading