Kuidas veebileht päriselt töötab: brauserist serverini ja tagasi

Mis juhtub, kui vajutad Enter

Avad brauseri, kirjutad veebimets.ee, vajutad Enter. Umbes 200 millisekundi pärast on ekraanil leht. See tundub instant. Tegelikult käivitub selle aja jooksul vähemalt seitse erinevat süsteemi, kümneid TCP-pakette lendab läbi Atlandi ookeani ja brauser teeb ära mahuka töö, mille kohta enamik kodulehe omanikke ei oska pärida.

See artikkel on tehniline, aga kirjutatud nii, et arusaadav oleks ka ettevõtjale, kelle koodikäsitlus piirdub HTML-iga. Miks see üldse oluline on? Kui mõistad, mis kapoti all toimub, oskad teha paremaid otsuseid: miks valida CDN, miks SSL on tähtis, miks ühe pildi optimeerimine võib lehe kaks korda kiiremaks teha. Kõik need küsimused saavad vastuse, kui näed kogu pilti.

Niisiis, vaatame ühe veebilehe avamise selgrood.

Vaatame need viis sammu kõik järjest läbi. Iga sammu juures räägime ka sellest, mida saad selle kiirendamiseks teha.

1. samm: DNS leiab serveri aadressi

Kui kirjutad veebimets.ee, ei tea brauser veel ühtegi serverit. veebimets.ee on lihtsalt nimi, nagu „Mati Maasikas". Brauseril on vaja telefoninumbrit, ehk IP-aadressi, näiteks 185.243.112.45. Selle numbri leidmist nimetatakse DNS-päringuks (Domain Name System).

DNS töötab nagu hierarhiline kataloog. Brauser ei küsi otse domeeni omanikult, vaid liigub mööda ahelat alates juurest. Iga server selles ahelas teab vähem ja vähem, aga oskab öelda, kes teab rohkem.

Tegelikult juhtub see kõik harva igal külastusel. Brauser ja ISP cache'ivad vastuse minutiteks või tundideks (TTL ehk Time To Live määrab, kui kauaks). Esimene külastus võib võtta 50 ms, järgnevad 1 ms.

Eestis haldab .ee domeeni Eesti Interneti SA (EIS). Kui muudad oma domeeni nimeserverit, võib levik võtta kuni 24 tundi, kuna kõik vahepealsed cache'id peavad aeguma.

Praktiline järeldus: aeglane DNS tähendab, et iga uue lehe avamine algab viivitusega. Kui sul on Eesti hostingul ja kasutaja Eestis, on see paari millisekundi küsimus. Kui sul on USA hosting, võib DNS-päring koos hilinemisega võtta 100+ ms. Cloudflare ja teised CDN-id pakuvad ka DNS-i, mis on tihti kiirem.

2. samm: TCP ühendus ja TLS käepigistus

IP-aadress on käes. Aga IP üksi ei tähenda midagi, see on lihtsalt arvuti number Internetis. Andmete saatmiseks on vaja ühendust. Brauser avab TCP ühenduse (Transmission Control Protocol), mis on usaldusväärne kahesuunaline kanal. Selleks toimub kolme paketi vahetus, mida nimetatakse TCP-käepigistuseks (handshake): SYN, SYN-ACK, ACK. Iga edasi-tagasi sõit Eestis kohaliku serveriga võtab umbes 5–15 ms. Kui server on USA-s, läheb see 100 ms peale.

Kui leht on HTTPS-il (mis tänapäeval peakski olema iga leht), järgneb sellele TLS-käepigistus. See on see osa, mis krüpteerib su side. Kui näed brauseris tabaluku ikooni, on TLS töös.

TLS-i mõte on lihtne: keegi teel olev keskel-mees (kohvikuruuter, ISP, riik) ei saa lugeda, mida sa serverile saadad ega serverist tagasi tuleb. Kui sisestad parooli HTTP lehel, on see avalik. HTTPS lehel on see krüpteeritud nii, et isegi kui keegi paketi kinni püüab, näeb ainult mürarida.

Sertifikaat ehk SSL-sertifikaat (täpsemalt TLS-sertifikaat, kuid SSL on jäänud kõnekeelde) on faili, mis kinnitab, et see server on tegelikult veebimets.ee, mitte mingi pettur. Selle väljastab usaldatud asutus (CA). Tasuta sertifikaate annab Let's Encrypt, tasulisi DigiCert ja teised.

Praktiline järeldus: kui sul pole HTTPS-i, kaotad kohe Google'i edetabelit, brauser näitab „mitte turvaline" hoiatust ja iga ettenägev klient lahkub. Let's Encrypt on tasuta ja iga normaalne hosting toetab seda. Kui hosting nõuab SSL eest 50€/aastas, vaheta hostingut.

3. samm: HTTP päring serverile

Turvaline kanal on avatud. Brauser saadab nüüd HTTP-päringu (HyperText Transfer Protocol). See on lihtsalt tekstiline sõnum ettenähtud formaadis. Kogu Internet käib HTTP peal, kuigi tänapäeval on osad osad uuendatud HTTP/2 või HTTP/3 peale. Põhimõte on sama, lihtsalt kiirem.

Üks tavaline päring näeb välja umbes nii:

Kolm asja, mida tähele panna:

• Meetod (GET, POST, PUT, DELETE) ütleb, mida tahad teha. GET tähendab „anna mulle", POST tähendab „võta vastu". Brauser kasutab GET-i lehe avamisel ja POST-i siis, kui esitad vormi.
• URL ja Host ütlevad serverile, millist konkreetset asja sa tahad. Üks server võib hostida mitut domeeni, seetõttu on Host kohustuslik.
• Headers on metainfo: kes oled, mida toetad, mis cookied sul on. Cookie on see, mis hoiab su sisseloginud, jätab meelde ostukorvi sisu, jälgib analüütikat.

HTTP/2 (kasutusel umbes 2018-st) ja HTTP/3 (alates 2020-tega) muudavad seda kanalist mitmeks paralleelseks alamkanaliks, et üks aeglane fail ei pidurdaks teisi. Vana HTTP/1.1 saatis päringuid jadamisi, üks kord. Tänapäevane brauser ja server räägivad enamasti HTTP/2 või HTTP/3 keelt automaatselt.

Praktiline järeldus: kui su hosting toetab ainult HTTP/1.1, on iga lehe laadimine aeglasem kui peaks. Cloudflare, AWS CloudFront ja igasugused moodernsed CDN-id pakuvad HTTP/3 tasuta. PageSpeed Insights ütleb sulle, kui kasutad vana protokolli.

4. samm: server töötab vastuse välja

Päring jõudis serverisse. Mis järgmiseks juhtub, sõltub sellest, kas tegu on staatilise või dünaamilise lehega.

Staatiline leht tähendab, et kogu HTML on juba failina serveris valmis. Server (näiteks nginx või Apache) leiab faili kõvakettalt ja saadab tagasi. Kõik. See on välkkiire, sest mingit „arvutamist" pole vaja teha.

Dünaamiline leht tähendab, et HTML genereeritakse iga päringu jaoks uuesti. WordPress, Drupal, Joomla ja enamus e-poed töötavad nii. Server võtab päringu vastu, käivitab PHP (või Node.js, Python, Ruby), see küsib andmebaasilt sisu, paneb HTML kokku ja saadab tagasi.

Selle ahela aeglaseim koht on tavaliselt andmebaas. Üks halvasti kirjutatud SQL-päring võib võtta 500 ms, mis on rohkem kui kogu ülejäänud lehe laadimine kokku. WordPressi puhul tähendab see N+1 probleemi, kus iga blogi-postituse jaoks tehakse eraldi päring autori andmete kohta. 20 postitust = 21 päringut.

Cache (näiteks Redis) hoiab tihti küsitavaid asju mälus, et andmebaasi mitte tülitada. Esimene külastaja maksab koormuse, järgmised tuhat saavad valmis vastuse mikrosekundi.

Kui server on koodi käivitanud ja HTML kokku pannud, saadab ta selle tagasi koos vastuse päiseridadega:

Vastuse esimene rida ütleb staatuse: 200 on OK, 404 on „pole olemas", 500 on „server kukkus kokku", 301 on „see asi liikus mujale". Kõik need tulevad kasuks SEO ja debug'imise jaoks.

Praktiline järeldus: kui su backend (PHP, andmebaas) on aeglane, ei aita ükski front-end optimeerimine. Kui Time To First Byte on 800 ms, on probleem serveris. Kui see on 80 ms aga kogu leht ikka aeglane, siis on probleem brauseri pool. Need kaks asja vajavad eri lähenemist.

5. samm: brauser joonistab pildi kokku

HTML jõudis brauserisse. Aga HTML iseenesest pole pilti. See on tekstidokument, mis kirjeldab struktuuri. Brauseri töö on see tekst lehe pildiks muuta. See tee on pikem kui paljud arvavad.

Tähtsamad sammud:

1. Parsing: brauser loeb HTML-i ja ehitab DOM-puu (Document Object Model). See on objekt, mille kaudu JavaScript saab elementidega rääkida.
2. CSS: paralleelselt loetakse CSS ja ehitatakse CSSOM (CSS Object Model). Kui CSS on serveris või eraldi failis, peab brauser seda alla laadima ja parsima enne, kui saab edasi minna. Seetõttu on suur CSS-fail render-blocking.
3. Render Tree: DOM ja CSSOM kombineeritakse Render Tree-ks. Elemendid, mida ei kuvata (display: none), siia ei lähe.
4. Layout ehk reflow: brauser arvutab iga elemendi täpse asukoha ja suuruse. „See nupp on x=120, y=480, laius 200px."
5. Paint: brauser joonistab iga elemendi pikslid (värvid, varjud, gradiendid).
6. Composite: brauser paneb erinevad kihid kokku ja saadab GPU-le, et see lõplikuks pildiks muudaks.

JavaScript on kõikide nende tegevuste kõrval natuke eriline. Kui brauser kohtab <script>-tagi ilma async või defer atribuudita, peatab ta DOM-i ehitamise, laadib JS-i alla, käivitab selle ja alles siis liigub edasi. Selline blokeeriv JS võib lehe avamist sekundite võrra venitada. defer ütleb brauserile „lae alla, käivita siis, kui DOM valmis", async ütleb „lae alla ja käivita kohe kui valmis, ära oota teisi".

Praktiline järeldus: kui sul on Google Tag Manager, Facebook Pixel ja kolm chat-vidinat <head>-is ilma async-ita, on su lehe esmasväljakuvamine selle tõttu 1–3 sekundit aeglasem. Lisa async või defer või liiguta need </body> ette.

6. samm: JavaScript paneb lehe elama

Esimene HTML on ekraanil. Aga modernne sait ei piirdu sellega. JavaScript käib taustal: laadib pilte lazily, valmistab vormi, küsib API-st andmeid, näitab popup-e. Igal juhul, kui sul on midagi muud kui staatiline tekst, on JS sees.

Kaks põhilist JS-mustrit, mida tasub teada:

• Vanilla DOM-manipulatsioon: kood otse muudab DOM-i. Lisab klassi, kuvab elemendi, küsib AJAX-iga andmeid. See on kiire ja kerge. Veebimetsa lehe taoline lihtne sait töötab täielikult selle peal.
• SPA (Single Page Application): React, Vue, Svelte. Brauser laadib esimese korraga suure JS-ipakkide, mis joonistab kogu rakenduse. Edasised navigeerimised ei lae uut HTML-i, vaid kirjutab DOM-i ümber. See teeb interaktsioonid välkkiireks, aga esimene laadimine aeglasemaks.

Tänapäeva trend on hübriid: Server-Side Rendering (SSR) genereerib esimese HTML-i serveris (kiire esmaslaadimine), siis JS „hüdraatiseerib" lehe (interaktiivseks tegemine). Next.js, Nuxt, Astro töötavad nii. Sellistel saitidel on parim mõlemast: SEO-sõbralik kohe ekraanile ja edasi sujuv kasutuskogemus.

Vahekiht, mida me unustame: caching

Kogu see ahel, mida ülal kirjeldasime, ei juhtu igal külastusel täies pikkuses. Caching katab kõike: brauserit, CDN-i, serverit, andmebaasi.

Mis kus cache'is hoitakse:

• Brauseri cache hoiab kõike, mille server saatis koos pikema Cache-Control: max-age headeri'iga. Pildid, fontid, CSS, JS. Külasta sama lehte uuesti, suur osa varadest tuleb su enda kõvakettalt.
• CDN edge on kümned serverid üle maailma. Cloudflare'il on Tallinnas server. Kui sinu sait on Cloudflare'i taga, jõuab Eesti kasutaja vastuseni 5 ms-ga, mitte 100 ms-ga, kuna ei pea minema USA-s asuvasse algusserverisse.
• Reverse proxy ja application cache seisavad serveri ees ja salvestavad genereeritud HTML-i terveks lehe versiooniks. WordPressi puhul on see WP Rocket või W3 Total Cache.
• Database cache on Redis või Memcached, mis hoiab tihti pärinud andmeid mälus, et MySQL ei peaks kettalt lugema.

Praktiline järeldus: 80% kiiruskasust tuleb õigesti seadistatud caching-ist. Kui sa ütled „mu sait on aeglane", on tihti vastus „cache pole õigesti üles seatud". Konsulteeri arendajaga ja kontrolli, mis Cache-Control päiseid sa tegelikult saadad. Tasuta tööriist WebPageTest.org näitab seda kohe.

Mida see sinu kodulehega praktiliselt teeb

Kogu see torustik tõlgib end väga konkreetseteks numbriteks su kodulehel. Google mõõdab neid Core Web Vitals nime all ja kasutab edetabeli koostamisel.

LCP ütleb, kui kiiresti suurim sisuelement (tavaliselt kangelaspilt või pealkiri) ekraanile jõuab. Aeglane DNS, aeglane server, blokeeriv CSS, optimeerimata pildid, kõik teevad LCP-d halvemaks.

INP mõõdab, kui kiiresti leht reageerib su klikkidele ja sisestustele. JavaScript, mis blokeerib põhilõnga, lükkab INP-d.

CLS mõõdab visuaalset värisemist. Kui hüppab pilt, mille kõrgust polnud HTML-is märgitud, või Google Ads laadib alla ja tõukab teksti allapoole, kasvab CLS. See on kõige odavam asi parandada: pane pildile width ja height külge.

Konkreetsed asjad, mida me Veebimetsas kõigi klientide juures kontrollime:

1. HTTPS koos HTTP/2 või HTTP/3-ga. Kontrolli tools.keycdn.com/http2-test abil.
2. Pildid on WebP- või AVIF-formaadis ja õige suurusega. Mitte 4000-pikslise originaalfoto väiksemaks skaleerimine CSS-iga, vaid juba 800-pikslise saatmine.
3. Fontid on eellaaditud (<link rel="preload">) ja kasutavad font-display: swap, et tekst poleks alguses nähtamatu.
4. JS on defer või async, eriti analytics ja kolmandate osapoolte vidinad.
5. CSS on inline kriitiline ja muu lazy-loaded. Kriitiline tähendab seda, mida kasutaja kohe näeb.
6. Cache-Control päiseid saadetakse õigesti. Pildid, fontid, CSS, JS olgu cache'itavad kuus kuud, HTML olgu kas cache'imata või lühikese TTL-iga.

Kokkuvõte: 200 millisekundi täielik tee

Kui kõik töötab hästi ja Eesti kasutaja avab Eesti hostingul oleva Cloudflare'i taga oleva lehe, näeb täielik tee välja umbes nii:

See on hea sait. Halb sait sama setup'iga võtab 4–8 sekundit, sest mängu tulevad kaalukad WordPressi pluginad, optimeerimata pildid, USA-s asuv hosting, render-blocking JavaScript ja andmebaasi-päringud, mis võtavad sekundeid.

Kui sa nüüd käid PageSpeed Insights-is ja vaatad oma lehe tulemusi, saad iga punase numbri kõrval mõelda, milline torustiku osa veab. „LCP on 4 s" võib tähendada, et server on aeglane (suuri SQL-päringuid), pilt on kaalukas (paar megabait JPEG), CDN puudub (kõik tuleb USA-st) või CSS on render-blocking (eraldi fail eelnevalt laaditud).

Sellega see torustik on ka praktiline. Sa ei pea ise ehitama veebiservreid, aga kui mõistad, mis seal toimub, oskad õigeid küsimusi küsida ja õigeid otsuseid teha. Kas su praegune hosting on Eestis või USA-s? Kas sertifikaat on Let's Encrypt'ist või iga-aastane ostetud? Kas pildid on WebP-s? Kas pluginaid on viis või viiskümmend?

Kui sul on kahtlus, et midagi sinu lehel pole õigesti, ja tahaksid kogu selle tee oma lehe puhul läbi käia, võta meiega ühendust. Vaatame Tab-i Network DevTools-is, käime PageSpeed soovitused punkthaaval läbi ja teeme välja tegevusplaan, mis päriselt aitab.

Lisaks loe, kui aeglane koduleht peletab kliente minema ja kuidas mobiilse optimeerimisega jõuda kiiremate skooorideni.