Cum se incarca asa de repede paginiile web?

M-am apucat de cateva luni de programare web si m-am tot intrebat : cum de cu toate procesarile si distanta si tot restul , pagina mea web se incarca in 2-3 secunde?
Adica daca e sa o luam asa: eu ca user fac request din browser si acuma nu am garantia ca serverul e in tara, poate e pe celalat colt al lumii, ceea ce sunt mii de kilometri. Plus daca are o arhitectura de tip microservicii intervine api gateway, verificari , decriptare chestii, dupa ce a fost procesat requestul la api gateway mai are inca drum lung pana la destinatie. Dupa acolo iara trebuie procesat si acolo iara sunt operatii facute pe el, si dupa ia-o inapoi la user cu response-ul, si iara vine criptat strabate mii de kilometrii, dar dupa ce ajunge la browser iara vin aici cateva procese ,procesare taguri, generare DOM,asezare elemente in pagina si dupa asta mai vine si un framework gen Angular care si el mai are 2-3 eventuri, procese, bucati de cod care vor sa fi executate la un moment specific in timp.
Si totusi toate astea sunt gata in 2-3 secunde sau sa zicem 5 secunde poate .
Eu daca scriu un script si il testez pe un set mare de date(sa zicem un coding challenge) si il fac ineficient, ii i-a ceva pana ruleaza, 2-3 secunde, si nu e complex codul sa zicem 50 de linii de cod , iar ditamai web app-ul se incarca extrem de repede . Care este secretul?

Evolutie!!

Calculatoare mai puternice, idem si servere
Transmisii de date mai bune cu latenta mai mica si viteza mai mare
Protocole (HTTP 2), browsere, toate au evoluat

Tot ce tine de Internet a evoluat fata de acum
ceva timp.

Acum vreo 20 de ani dura minute bune sa se incarce o pagina web. :slight_smile:

Un thread de interes

Pre-emptive processing + caching.

3 Likes

Pai de ce nu ar fi asa rapid?

Procesoarele sunt capabile de a efectua miliarde de operatii pe secunda.
Viteza cu care datele sunt transferate intre nodurile de internet se poate face aproape de viteza luminii.

Pune loguri pe parcursul unui request si vezi cat timp necesita fiecare parte.

Fata de anii trecuti cred ca principala diferenta consta in dezvoltarea infrastructurilor si implementarea paralelismului in mai multe puncte pe traseul de transfer si manipulare al datelor.

In momentul in care se poate face chiar streaming de video de mare rezolutie, criptat, si chiar niste calcule care ar fi dat de furca unui supercalculator acum catava vreme… in doar cateva secunde, tu iti pui intrebari de-astea relativ la rahatele?

Optimizari, cache, distributia geografica, cdn, in unele cazuri ssr, asa la prima strigare.

Sunt doar curios cum functioneaza tehnologia, adica doar invat despre cum functioneaza un request si cum sa il trimit din front-end spre backend si cum sa il prelucrez fara sa stiu mai mult de atat. Asta e defectul meu sunt o fire prea curioasa, si nu ma multumesc doar sa stiu minimul necesar :wink:

3 Likes

Iti recombd sa citesti despre stiva tcp ip, ce nivele are si cum comunica intre ele. Si care este rolul lor.

Citeste si despre protocoale, infrastructura, echipamentele care stau in spate. Ai un router acasa. Foloseste Wireshark ca sa vezi ce pachete se trimit pe retea si sa intelegi cum sunt structurate.

Este o intreaga lume in spatele unui request.

Ce am scris eu pe aici este doar o mica parte. Si este ceva ee rumegat. Nu ore ci poate luni sau chiar ani.

Bafta!
O sa actualizez raspunsurile( aacesta si cel de mai sus cu link-uri in context)

1 Like

Ok, in cazul ala ia-o pe bucatele. Nu e chiar asa de mare filosofie.
Intrebarea pe care trebuie s-o pui e prima oara ‘cum functioneaza?’, nu ‘cum functioneaza asa de repede?’. Aia cu ‘repede’ vine ceva mai tarziu si nu e mare branza.

Daca ai veni cu o idee cum sa se faca sa functioneze repede simularea unui calculator cuantic sau calculele ab initio in fizica nucleara, aia ar fi mare filosofie.

WebPageTest ar putea sa te ajute in privinta asta: https://www.webpagetest.org/

Cel mai simplu ar fi sa compari un raport al unui site care se incarca rapid cu cel al unui site care se incarca mai lent.

De fapt întrebarea corectă ar fi “de ce naiba durează atât de mult să se încarce o pagina web?” :slight_smile: 2-3 secunde pentru incărcarea unei pagini este de fapt extrem de mult.

2 Likes

Mmm, cate raspunsuri si niciunul bun. Secretul #1: browserul lanseaza maxim 2 threaduri catre acelasi url. Secretul #2: compresia datelor

Distanța nu este neapărat o problemă. În mod ideal, viteza datelor este viteza luminii (i.e. face un tur complet al planetei în vreo 0.1-0.2s, dacă-mi aduc aminte bine). Chiar și cu hopuri, tot nu crește foarte mult.

1 Like

E o problema. Serioasa. Realizezi asta cand trebuie sa transferi audio & video ‘real time’. Delay-ul e mult prea vizibil cand folosesti tcp, ceva mai bine cu udp dar acolo apar multe alte probleme…

1 Like

Aprope de “se incarca foarte repede, i.e. in 2-3 secunde sau 5 secunde”. Pentru o pagina web, 2-3 secunde nu este deloc foarte repede, dimpotriva.

Va recomand sa aruncati o privire pe site-ul asta, eu am gasit cateva lucruri foarte interesante: https://lawsofux.com/

Una dintre acele “legi” spune ca interactiunea om-masina trebuie sa se faca in ~500ms (milisecunde) pentru ca niciunul dintre actori sa nu “se plictiseasca”.
Intr-o aplicatie web, asta se traduce prin: odata ce eu, ca utilizator, apas un buton (sau vizitez o pagina noua), contentul trebuie sa-mi “explodeze” pe ecran in maxim 500ms, altfel o s-o percep ca pe o intarziere.

Binenteles ca nu toate paginile web se incarca in ~500ms, mai ales la prima vizita.
De regula aplicatiile web complexe care folosesc framework-uri precum React, Angular, VueJS au nevoie de un timp mai mare de initializare, dar exista tehnici care imbunatatesc TTI (time to interactive).

Multe companii mari au un entry page foarte simplu, de regula fara niciun framework prea complex, tocmai pentru a se incarca “instant”. Un exemplu foarte bun este Netflix: https://medium.com/dev-channel/a-netflix-web-performance-case-study-c0bcde26a9d9

1 Like

La video/audio “live” bottleneck-ul ţine mai degrabă de modul în care se generează stream-ul. Înainte că măcar să încerci să transmiţi un bit de video, trebuie să aştepţi să se adune măcar câteva frame-uri, ca să ai la ce să faci compresie. După aia, clientul trebuie să buffereze un pic, că să compenseze jitter-ul. La tranmisii UDP cred că există şi riscul să se inverseze pachetele (cele trimise mai devreme să ajungă mai târziu decât cele trimise mai târziu), deci un buffer trebuie să aştepte un pic să vadă dacă nu cumva mai sunt pachete rătăcite care încă n-au apucat să ajungă la destinaţie.

Aş zice câ în “live streaming” întârzierile sunt mai degrabă deliberate, ca să dea impresia de “fluenţă”.

‘Cateva frame-uri’ nu genereaza un asemenea delay. Totusi e vorba de ceva in genul macar 15 fps daca nu 30 fps. Cu tcpip delay-ul e insa foarte sesizabil, nu doar cateva frameuri.

La udp exista toate riscurile: pachete care vin in ce ordine vor ele, nu vin, sau chiar vin duplicate. Trebuie sa ai o mica fereastra in care sa le ordonezi, bineinteles ca si aia genereaza intarziere.

Lasand astea deoparte, diferenta dintre local (sau o conexiune buna cu ceva apropiat de prin Europa) si sa zicem India e sesizabila, cu aceleasi setari.

Ideea e că nu avem doar o simplă sârmă între România şi India, până ajunge un pachet TCP sau UDP la destinaţie trece prin jdemii de routere şi switch-uri, fiind verificat, marcat, bufferat, stând în cozi de aşteptare, la concurenţă cu miliarde de alte pachete IP care încearcă să-şi găsească destinaţia, convertit din semnal electric în semnal optic şi invers. Chestiile astea generează latenţă, care latenţă măcar dacă era constantă, dar nu, există şi păcătosul de jitter.

1 Like

Yeap. Nu e asa de simplu ca ‘viteza luminii’. Si de fapt, chiar viteza luminii prin mediu nu e tot aia cu cea din vid, pe fibra optica o ia mai lent.
Ceva similar e si cu cablurile electrice, e vorba tot de un mediu de propagare diferit de vid.

1 Like

Viteza luminii e lower bound. Realist nu ai “o viteza” între România și India, ci ai multe viteze - o distribuție, chiar nestationara (sistematic mai rapid câteodată, sistematic mai lent alta data).

1 Like