Pentru site-urile de trafic mare, un sistem de caching este cea mai buna solutie pentru functionarea corecta a site-ului, apelurile efective pe serverul de baze de date si construirea paginilor fiind mult mai rare.
Dar problema apare datorita duratei de viata limitate a cache-ului, astfel ca la un moment un numar de pagini nu mai au versiune de cache si ca urmare apelul utilizatorilor catre aceste duc la construirea lor de la zero, pe baza datelor aflate in baza de date.
Mai multe astfel de apeluri concurente duc la o solicitare mai mare pe resursele serverului. Daca paginile nu sunt optime din punctul de vedere al interogarilor MySQL (de exemplu) ca numar si ca eficienta, serverul de baze de date poate fi depasit de solicitari si chiar poate duce la blocarea bazei de date si la functionarea paginilor respective
E intuitiv ca numarul de interogari trebuie reduse pe fiecare pagina si interogarile optimizate. Nu toate temele de WordPress sunt optimizate. Desi unele site-uri de stiri utilizeaza WordPress si teme de WordPress constuite dedicat pentru site-uri cu trafic mare, nu intotdeauna se optimizeaza toate resursele.
Imaginati-va un site de stiri cu versiune de desk cu 360 de interogari pe pagina de articol! Este calea sigura spre blocarea paginilor respective.
Dupa optimizare, pagina face doar 55 de intergoari MySQL!
Astfel ca munca de reducere a optimizarilor incepe cu identificarea locurilor in care interogarile se pot elimina, reduce, optimiza.
Ca exemplu, meniul in WordPress poate fi extrem de costisitor din punctul de vedere al resurselor solicitate, mai ales daca avem un mega meniu cu articole sub fiecare categorie principala din meniu.
Am identificat la un site de stiri 180 de interogari doar pentru construirea acestui meniu.
Si inca vreo 20 pentru construirea unui widget de stiri recente in bara laterala.
S-au pastrat dupa optimizare cu totul doar vreo 4 interogari, incarcatura mutandu-se in admin la editarea/publicarea unui articol.
O alta cale de a elimina interogari este de a dezactiva in front-end anumite pluginuri pe anumite pagini in care nu este nevoie de ele sau global. Se pot castiga zeci de interogari mai putin pe baza de date.
Imaginati-va ca in procesul de optimizare s-a renuntat la pluginurile sau functionalitatile temei care faceau insert in baza de date in front-end (contorizarea afisarilor, pluginuri “ciudate” pentru feed-uri, etc). Acest tip de interogari blocau activitatea de editare articole di admin a jurnalistilor.
Am mai invatat o lectie: anume ca un plugin, oricat de bun este, totusi poate fi restrans ca activitate. Iar altele despre care nu stim nimic pot cauza mari probleme.
Un alt plugin construit custom cu principiul optimizarii in primplan este widgetul de articole externe preluate printr-un feed: preluarea se face printr-un cron job la intervale regulate si articolele, preluate se pastreaza in baza de date intr-un tabel custom. Imaginile se genereaza local. O varianta extrem de light ar fi cea in care datele articlelor preluate se pastreaza intr-un fisier pe web server si se include in pagina la generarea ei, pur si simplu. Un truc pentru actualizarea unor astfel de wudget-uri chiar si pe pagini din cache este preluarea prin ajax la incarcarea paginii in browser a versiunii actualizate a fisierului generat de cron job. Aceasta tehnica poate fi folosita pentru orice tip de widget, iar pastrarea datelor in fisiere pregenerate in admin sau la rularea unor cron job-uri este poate fi facuta in baza de date sau pe fisiere html, json, etc
Temel de WordPress si/sau pluginuril emai pot fi optimizate daca se construiesc template-uri custom in care nu se mai fac interogari pe server pentru optiunile temei ci se insereaza efectiv datele articolelor intr-un template static. Se pot castiga zeci de interogari mai putin…
Ziarulunirea.ro este unul dintre site-urile la care am optimizat functionarea cu rezultatele pe care le gasiti in pagina de portofoliu. Vezi optimizare site web.
Află detalii privind realizarea site-urilor pe WordPress
Creare site WordPress
Sau ia legatura cu noi aici
