Contează sau nu serverul în testele de verificare a performanței unui site?

Una dintre chestiile care mă irită la uneltele astea de testare a vitezei de încărcare a unui site este sintagma Reduce server response times, care este incorectă.

Majoritatea celor care testează nu dau click pe Learn more pentru a vedea că nu e de fapt despre server, ci în primul rând despre cât de bine e optimizată aplicația (site-ul). Oamenii văd cuvântul server acolo și își formează deja ideea că problema e de la server sau de la găzduire.

Haideți să testăm…

Blogul meu stă pe o găzduire shared de la Simplenet, o să testez scorul de acolo, apoi o să-l mut pe un VPS la Google Cloud și o să testez cu mai multe niveluri de resurse, să vedem dacă se îmbunătățește ceva. Dacă n-ai chef să citești până la capăt, răspunsul final este că nu prea.

Ok, o să folosesc GTMetrix pentru testare, are în spate tot sistemul Lighthouse, la fel ca Pagespeed Insights.

Primul test

primul test
  • TTFB: 250 ms
  • Fully loaded: 1,7 secunde
  • Performance: 92
  • Structure: 96

Mare lucru nu e de spus, sunt scoruri bune, site-ul e destul de minimalist.

Testul 2

Am deschis un VPS pe Google Cloud, cel mai mic și mai oropsit, f1-micro (1 vCPU, 0.6 GB memory), care are un cost estimat de $6.72 / lună. Legat de costuri, că o să le vedeți la fiecare test, sunt estimările făcute de Google pentru CPU, RAM și un disk standard de 10 GB, deci fără trafic.

test 2
  • TTFB: 149 ms
  • Fully loaded: 1,6 secunde
  • Performance: 94
  • Structure: 100

Se vede îmbunătățirea, a scăzut TTFB-ul cu 100 ms și timpul de încărcare, au crescut puțin scorurile, e mai bine.

Având acum un CPU din seria N1 (Intel Xeon 2.0 GHz) care este shared, am vrut să văd dacă merge mai bine cu un CPU care nu e shared (nu știu ce înseamnă asta exact la Google Cloud, probabil ai acces la tot core-ul, nu la fracțiuni) și am decis să fac mai multe teste în zilele următoare și cu procesoarele N1, N2, E2 (general purpose) și C2 (compute optimized).

Testul 3

Custom N1 (1 vCPU + 1 GB memory) – cost estimat lunar $26.93

test 3
  • TTFB: 204 ms
  • Fully loaded: 1,5 secunde
  • Performance: 94
  • Structure: 96

A crescut TTFB-ul, dar a mai scăzut timpul de încărcare la 1,5 secunde.

Testul 4

Hai să testăm și cu un procesor tip N2, dar nu normal, ci varianta cu frecvență mai mare (2.8 GHz).

n2-highcpu-2 (2 vCPU + 2 GB memory) – cost estimat lunar $59.87

test 4
  • TTFB: 161 ms
  • Fully loaded: 1,4 secunde
  • Performance: 96
  • Structure: 97

A scăzut iar TTFB-ul, a scăzut și timpul de încărcare a paginii până la 1,4 secunde, a crescut puțin și scorul de performanță.

Testul 5

Hai să testăm și un procesor C2 (compute-optimized). Frecvența procesoarelor e mai mare, 3.1 GHz. Astea ar trebui să fie cele mai performante, descrierea lor zice: High-performance machine types for compute-intensive workloads. Am vrut să deschid un VPS maxim de curiozitate (60 CPU), dar se pare că am contul limitat la 8 CPU.

c2-standard-8 (8 vCPUs, 32 GB memory) – cost estimat lunar $243.95

  • TTFB: 186 ms
  • Fully loaded: 1,5 secunde
  • Performance: 95
  • Structure: 97

După cum se vede, iese puțin mai slab deși serverul e foarte performant. Am făcut mai multe teste ca să fiu sigur, ăsta a fost cel mai bun, restul au fost mai slabe. Am mai testat și alte configurări: E2 (2.2 GHz) cu 2 vCPU + 1 GB RAM și 2 vCPU + 2 GB RAM, precum și încă un C2 (3.1 GHz) cu 4 vCPU și 16 GB RAM. Nu le mai pun aici, niciunul nu a ieșit mai bine decât testele de mai sus.

Am văzut apoi că la N1 am limitarea mai sus, la 24 CPU, așa că am testat și un custom N1 (24 vCPUs, 64 GB memory) – cost estimat lunar $561.92

Și ăla a ieșit tot pe acolo, nicio diferență majoră.

Până acum am testat prima pagină a blogului care e destul de minimală, o listă de articole și 4 widget-uri. Hai să vedem ce se întâmplă dacă testăm pagina cea mai grea de pe site, articolul meu viral care are în jur de 1200 de comentarii, și dacă testăm și cealaltă extremă, o pagină statică, readme.html.

  • TTFB: 173 ms
  • Fully loaded: 2,6 secunde
  • Performance: 85
  • Structure: 93

Fiind o pagină lungă, cu multe elemente în DOM (peste 18.000), se vede cum au scăzut scorurile și a crescut timpul de încărcare.

Testul a fost făcut pe același VPS custom N1 (24 vCPUs, 64 GB memory) – cost estimat lunar $561.92.

Am mutat site-ul înapoi pe shared și am reluat testul.

test pagină grea
  • TTFB: 222 ms
  • Fully loaded: 2,5 secunde
  • Performance: 80
  • Structure: 92

Diferențele sunt foarte mici, timpul de încărcare e chiar mai bun, dar era 1 noaptea și serverul shared avea încărcare foarte mică. Fac o paranteză aici despre găzduirea shared, fiind mai mulți clienți pe același server, uneori merge mai bine, alteori mai puțin bine, este imposibil de garantat un nivel constant de performanță / viteză. Nu vorbesc de Simplenet, ci la modul general despre serverele shared.

Hai să testăm și extrema cealaltă, o simplă pagină statică.

test pagină statică
  • TTFB: 180 ms
  • Fully loaded: 362ms
  • Performance: 100
  • Structure: 100

100 pe linie, încărcare super rapidă – 362 milisecunde. De ce? Pentru că e o pagină statică, fără Javascript, fără interogări în baza de date, fără inițializarea WordPress și a tuturor plugin-urilor.

Ce concluzie tragem din testele astea

Pare ciudat, poate ireal, că niște servere așa de tari și scumpe nu reușesc să ofere performanțe mai bune, dar tocmai asta e ideea, de asta am făcut testele și scris articolul, ca să arăt că performanța serverelor se vede în alte scenarii, nu la teste cu PageSpeed.

Uneltele gen PageSpeed Insights sau GTmetrix testează performanța aplicației, nu a serverului sau a găzduirii.

Dacă faceți teste și primiți recomandarea Reduce server response times, nu vă grăbiți să dați vina pe server, ci uitați-vă mai întâi la pagina pe care o testați și la aplicația folosită (dacă e WordPress, la temă, plugin-uri și baza de date). Sunt șanse mult mai mari să creșteți performanța site-ului dacă optimizați aplicația decât dacă schimbați serverul.

In

7 răspunsuri

  1. Avatar Gabi Udrescu
    Gabi Udrescu

    Într-adevăr, bad wording. Însă ce voia să spună poetul e ca la un page load, atât îi ia serverului sa răspundă.

    Că e de la hardware, de la OS sau de la aplicație… Eh, aici Lighthouse n-are cum sa mai știe.

    Însă înțeleg de ce pentru un business de hosting treaba asta e precum kryptonita…

    1. Avatar Andrei Chira
      Andrei Chira

      Ar putea scrie application response, cred că ar fi mai aproape de adevăr.

      1. Avatar Gabi Udrescu
        Gabi Udrescu

        fair point. Application response cred că ar suna mai bine. faci un pull request la Google :D?

  2. Da, e foarte amuzantă chetia asta, plătești ani la rând mii de euro în plus pentru a te asigura că este rapid, că stă bine din punctul ăsta de vedere pentru SEO.

    Și descoperi că ar fi trebuit să dai câteva sute unui specialist care să se joace cu niște chestii de javascript.

    În altă ordine de idei, @Andrei, de mai mulți ani m-am gândit la o chestie: pachet hosting care să se scaleze.

    Adică, ești un blogger, dai o virală, pică site-ul pt. că ai un hosting de 50 euro.
    La fel, ești un blogger, dai lunar 200 euro în caz că dai o postare virală și-ți pică site-ul.

    Nu vin din zona tehnică.
    Dar, la Google, iei o mașină, alea sunt resursele.
    La un host, aceași poveste, iei un pachet, alea sunt resursele.

    Dar dacă dai virala, pică și hostul Google și cel de la alt furnizor…

    Aici practic e loc pentru un nou approach în materie de hosting.

    Dai cât consumi.

    Dacă eu consum 100 useri pe zi, atât plătesc.
    Dau postarea virală, mă duc în 5000 de useri pe zi, iar hostul meu se scalează.

    @Andrei – există astfel de hosting?
    Nu mă refer la host care are în spate mecanisme de scalare și distribuire.
    Mă refer la basic clasic hosting.

    1. Avatar Andrei Chira
      Andrei Chira

      Articolul nu se referă la performanța reală, ci strict la testele de tip PageSpeed.
      Am vrut să testez cum variază rezultatele dacă serverul are din ce în ce mai multe resurse (CPU în principal) și să arăt că nu variază prea mult.
      Deci serverele mari și scumpe nu sunt inutile. Doar că nu te ajută la testele astea. Te ajută la performanță reală, în special la susținut mai mult trafic. O să scriu un articol mai detaliat în care să explic tehnic cum funcționează.

      Pachete tradiționale de găzduire cu scalare nu o să vezi prea curând.

      Sunt mai multe probleme aici, cum scalezi (vertical, orizontal sau ambele) și cum facturezi?
      Găzduirea clasică e prepaid, plătești în avans pentru 1 lună, 3, 6, 1 an, whatever. Dacă faci ceva scalabil ar trebui ca clientul să plătească la final pentru ce a consumat în luna respectivă. Asta deschide o portiță pentru abuzatori. O soluție ar fi să depună niște bani în avans și la facturare să i se tragă din acel credit. Asta presupune o complicare, și tehnică, și contabilă, și operațională.

      Legat de scalare, în mediul shared cu cPanel nu poți scala orizontal.
      Scalarea orizontală presupune separarea codului PHP (core WP, teme și plugin-uri) de baza de date (server separat de bază de date) și de conținutul media (folderul uploads trebuie mutat pe alt server / bucket). Deci din prima ai nevoie de 4 servere: load balancer, serverul WP, serverul de baze de date și serverul cu media. Apoi, dacă vine trafic, ai nevoie să se deschidă automat clone ale serverului WP și load balancer-ul să împartă traficul între ele.
      Am scris „servere”, dar astea 4 nu trebuie neapărat să fie servere, pot fi containere sau pods sau cum le mai numește fiecare. Se pot face cu Docker și Kubernetes, dar e un setup complet diferit de cel tradițional cu cPanel.

      În mediul shared cu cPanel poți scala un cont doar vertical, adică să-i crești limitările de resurse și să poată folosi mai mult CPU și RAM. Problema e că mai ai alte câteva sute de site-uri pe serverul ăla shared și un consumator din ăsta mare îi poate afecta. Banii pe care îi iei de la consumator pentru resursele consumate nu îți acoperă nemulțumirea celorlalți. Și câți bani să-i iei pe resursele consumate, cum monitorizezi și calculezi cât are de plată? Și cum faci scalarea, o automatizezi sau faci manual, la cerere? Dacă o automatizezi și scalează toți (sau câțiva mari) se duce serverul în cap. Ce facem dacă un client implementează ceva greșit la site, codul PHP intră într-o buclă, consumă resurse în draci, contul scalează să-i dea mai multe resurse pentru a acoperi consumul și la final de lună are de plătit o groză de bani? Și vine și te întreabă de ce să-ți dea bani, că el nu a avut trafic mare. Ce facem? Monitorizăm fiecare site de pe server? Monitorizăm ce modificări de cod face fiecare client pe site? Deja nu mai e găzduire shared ieftină, e managed WordPress hosting. Ne complicăm.

      Găzduirea shared nu se vrea a fi o soluție complicată, e chiar invers, clientul vrea o soluție ieftină cu de toate (web, mail, backup etc) care să fie good-enough, furnizorul vrea o soluție construită să meargă pe pilot automat, standardizată și automatizată la maxim, ca să poată face profit din ăia 2-3 euro pe care îi ia de la client.

      1. Da, e o problemă foarte complicată.
        Dar, ea în sinea ei, cere un răspuns simplificat.
        Cred că cine o să intre în piață cu așa serviciu de hosting, va câștiga mult.
        Adică, nici bloggerul sau vedeta nu știe ce trafic va avea.
        Deci nu știe cât să plătească în avans.

        Clar, codul server-side și client-side sunt o componentă importantă.
        Poate mult mai importantă decât puterea serverului.

        Pe pe scară de 1-10, tu cum ai poziționa aceste 3 componente:

        1 – puterea serverului
        2 – codul care rulează pe server
        3 – codul care rulează în navigator

        Care e cea mai mare provocare?

        1. Avatar Andrei Chira
          Andrei Chira

          Există deja servicii de găzduire care scalează, dar nu sunt (și nu pot fi) găzduiri clasice shared cu cPanel. E ca și cum ai vrea să pui un disc cu un joc PS într-un Xbox, n-are cum să meargă, sunt platforme diferite. Din cauza asta sunt condamnate să fie nișate, nu pot fi vândute către consumatorul mass-market, care trăiește în paradigma cPanel și e greu să îi vinzi ceva complet diferit, chiar dacă e un serviciu mai bun.

          Calitatea codului cred că e primordială. Un site făcut bine va merge bine și pe un shared ieftin, dar un site făcut prost va pune în genunchi și un server puternic. Serverul contează foarte mult în cazul unui trafic mare, cu cât ai mai multe nuclee CPU, cu atât se pot deschide mai mulți workeri PHP care pot rezolva mai multe request-uri. Deci aș zice că pe primul loc e codul și pe locul 2 serverul, ca importanță. Legat de cod, nu sunt programator, dar aș zice că cel ce rulează pe server e mai important.

Lasă un răspuns

Adresa ta de email nu va fi publicată.