Skal tekstbaserede browsere reducere netværkstrafik?
Der er ingen tvivl om, at dagens websider er fulde af rigeligt indhold og bruger mere båndbredde til fuldt opladning, men ville bruge en tekstbaseret browser i stedet for en GUI-baseret, en væsentlig forskel i at reducere netværkstrafik? Dagens SuperUser Q & A indlæg har svar på en nysgerrig læsers spørgsmål.
Dagens Spørgsmål & Svar session kommer til os med venlig hilsen af SuperUser-en underafdeling af Stack Exchange, en community-driven gruppe af Q & A-websteder.
Lynx Browser screenshot høflighed af Wikipedia.
Spørgsmålet
SuperUser-læser Paulb ønsker at vide, om tekstbaserede browsere rent faktisk kan reducere netværkstrafik:
Gør tekstbaserede browsere som Lynx, Links og ELinks mindre båndbredde end GUI-baserede browsere som Firefox, Chrome og Internet Explorer?
Jeg gætter på, at der ikke er nogen reduktion i trafikken. Min begrundelse for dette er, at jeg tror, at en tekstbaseret browser overfører hele siden som den udbydes af serveren. Enhver strømlining eller reduktion af side widgetry er gjort lokalt.
Måske er der en vis reduktion i trafikken, da de fleste tekstbaserede browsere ikke udfører sideskripter eller flashfiler, hvilket kan forårsage mere trafik.
Kan tekstbaserede browsere gøre en mærkbar forskel i at reducere netværkstrafik?
Svaret
SuperUser bidragyder gronostaj har svaret for os:
Webserveren sender ikke hele webstedet, men dokumenter, som browsere anmoder om. Når du f.eks. Får adgang til google.com, spørger browseren webserveren for dokumentet google.com. Webserveren behandler anmodningen og sender nogle HTML-kode tilbage.
Derefter kontrollerer browseren hvad webserveren har sendt. I dette tilfælde er det en HTML-webside, så det analyserer dokumentet og søger efter refererede scripts, stilark, billeder, skrifttyper osv..
På dette tidspunkt er browseren færdig med at downloade originaldokumentet, men har stadig ikke hentet de refererede dokumenter. Det kan vælge at gøre det eller springe over at downloade dem. Regelmæssige browsere vil forsøge at downloade alle referencedokumenter for den bedste oplevelse. Hvis du har en annonceblokerer (som Adblock Plus) eller et privatlivsprogram (som Ghostery eller NoScript), så kan det også blokere nogle ressourcer.
Derefter downloader browseren de omtalte dokumenter en efter en, hver gang de beder webserveren eksplicit for en enkelt ressource. I vores Google-eksempel finder browseren følgende referencer (bare for at nævne nogle få af dem):
- https://www.google.com/images/srpr/logo11w.png (Google Logo)
- https://www.google.com/textinputassistant/tia.png (Keyboard Icon)
- https://ssl.gstatic.com/gb/images/i1_3d265689.png (Nogle kombinerede billeder, et trick bruges til at reducere antallet af browserforespørgsler.)
De faktiske filer kan være forskellige for forskellige brugere, da browsere og sessioner kan ændre sig over tid. Tekstbaserede browsere downloader ikke billeder, Flash-filer, HTML5-video osv., Så de downloader mindre data.
@NathanOsman gør et godt punkt i kommentarerne. Nogle gange er små billeder integreret direkte i HTML-dokumenter, og i disse tilfælde kan det ikke undgås at downloade dem. Dette er et andet trick bruges til at reducere antallet af anmodninger. De er meget små, men ellers er overhead til kodning af en binær fil i base64 for stor. Der er få sådanne billeder på google.com (base64 kodet størrelse / dekodet størrelse):
- 19 × 11 pixel Tastaturikon (106 Bytes / 76 Bytes)
- 28 × 38 pixel Mikrofon-ikon (334 Bytes / 248 Bytes)
- 1 × 1 pixel Gennemsigtig GIF (62 Bytes / 43 Bytes) Det vises i Google Chrome's Dev Tools Resources-fanen, men jeg kunne ikke finde det i kildekoden (sandsynligvis tilføjet senere med JavaScript).
- 1 × 1 pixel Korrupt GIF-fil, der vises to gange. (34 Bytes / 23 Bytes) Dens formål er et mysterium for mig.
Har du noget at tilføje til forklaringen? Lyde af i kommentarerne. Vil du læse flere svar fra andre tech-savvy Stack Exchange brugere? Tjek den fulde diskussionstråd her.
