De cate ori nu v-ati lovit de situatii in care veneau anumiti clienti si plecau de la voi in scurt timp pentru ca “nu merge site-ul”? Mai mult de atat, va spuneau ca “dincolo mergea, dar m-am mutat in Romania sa mearga mai repede”, neluand in calcul faptul ca ei plecasera de pe un grid sau VPS si au venit la shared hosting.
In cele mai multe cazuri “nu merge” dintr-un motiv foarte simplu: cod neoptimizat. Site-urile care folosesc un query de tipul SELECT * FROM <baza de date> de 10 GB ca sa afiseze un singur rezultat sunt reteta ideala pentru moartea unui server, mai ales uniserver shared.
Din punct de vedere comercial se poate face un lucru si anume recomandarea de upgrade: Servicii distribuite, VPS, server dedicat. De cele mai multe ori insa se amana inevitabilul, site-ul gatuind pana la urma toate resursele care i se ofera. Solutia eleganta deci este intervenirea asupra cauzei problemei, care tine de optimizarea codului.
In primul rand, folosirea unui sistem de caching, mai ales pentru contentul remote poate face minuni. Salveaza banda, salveaza resurse pretioase si nu in ultimul rand, salveaza niste nervi.
In ceea ce priveste codul, acesta trebuie sa fie structurat si modular. Nu toata lumea iubeste codul scris pe genunchi, cu atat mai putin programatorii care trebuie sa repare codul scris de developerii de duminica.
In cazul folosirii unor CMS-uri (Wordpress, Joomla etc) este recomandata rularea ultimelor versiuni. Oamenii care le dezvolta nu scot versiuni noi de dragul de a creste numarul versiunii si in mod cert nu fac asta in lipsa de lucru. Rularea ultimelor versiuni ale acestor CMS-uri va va scuti de multe dureri de cap.
Acelasi lucru este valabil si pentru pluginuri. Nu arareori am dat peste bloguri si site-uri care foloseau pluginuri cu 4-5 versiuni in urma, pe considerentul daca merge si asa, de ce sa fac upgrade? dupa care se mirau ca site-ul a fost spart si contentul sters. Daca tot suntem la capitolul pluginuri trebuie retinut ca cel mai nepont este folosirea de pluginuri opensource neverificate, mai ales daca site-ul este live si in productie. De cele mai multe ori aceste pluginuri au niste gauri de securitate care mai ca nu afiseaza o pancarta mare si luminoasa pe care scrie Haideti si intrati!
Astfel, un site nu poate sa se numeasca optimizat daca nu este si securizat. Concepte de genul safemode si openbasedir nu ar trebui sa fie straine nici unui developer. Tot la capitolul asta trebuie mentionate permisiunile fisierelor si directoarelor. Cat mai mici si mai putine. Cele mai multe probleme apar din cauza permisiunilor puse aiurea, care cauzeaza probleme grave, de la defacing pana la clocit fara voie o seama de virusi.
Bineinteles, exista cazuri in care nu se pot schimba permisiunile fisierelor si directoarelor fara a afecta buna functionare a unui site. Suna chiar ingrijorator, nu? Ei, nu chiar. In acest caz avem un mic salvator, la care ii zice .htaccess, care poate fi configurat sa permita accesul la anumite fisiere doar din cadrul site-ului si nu din afara.
Nu in ultimul rand, cea mai des intalnita gaura de securitate: Formularul de contact. Cel mai mult spam stealth se trimite prin intermediul formularelor de contact nesecurizate. Cel mai simplu si usor lucru care se poate face pentru securizarea acestuia este folosirea unui cod captcha. Metode usor mai avansate de securizare a formularelor includ redenumirea parametrilor, verificarea datelor, protejarea impotriva SQL injection-ului etc. Un exemplu de securizare a unui formular PHP gasiti aici.
Cele de mai sus sunt doar o mica parte din aspectele legate de optimizarea site-ului si codului. Asa ca inainte de a recomanda clientului un upgrade pentru ca foloseste prea multe resurse ca urmare a unui cod si site neoptimizat, interveniti asupra cauzei. Pe termen lung va va oferi o noapte linistita si un server care respira usor.