Förminskar textbaserade webbläsare nätverkstrafik?

Det råder ingen tvekan om att dagens webbsidor är fulla av rikt innehåll och använder mer bandbredd för att ladda upp fullt, men skulle en textbaserad webbläsare istället för en GUI-baserad vara en stor skillnad när det gäller att minska nätverkstrafiken? Dagens SuperUser Q & A-inlägg har svaren på en nyfiken läsarens fråga.

Dagens Question & Answer-session kommer till oss med tillstånd av SuperUser-en indelning av Stack Exchange, en community-driven gruppering av Q & A-webbplatser.

Lynx Browser skärmdump med tillstånd av Wikipedia.

Frågan

SuperUser-läsare Paulb vill veta om textbaserade webbläsare faktiskt kan minska nätverkstrafiken:

Använd textbaserade webbläsare som Lynx, Links och ELinks mindre bandbredd än GUI-baserade webbläsare som Firefox, Chrome och Internet Explorer?

Jag gissar att det inte finns någon minskning av trafiken. Min rationale för detta är att jag tycker att en textbaserad webbläsare hämtar hela sidan som den erbjuds av servern. Någon strömlinjeformning eller reduktion av sidmat widgetry sker lokalt.

Kanske finns det en viss minskning av trafiken eftersom de flesta textbaserade webbläsare inte kan utföra sidskript eller flashfiler, vilket kan leda till mer trafik.

Kan textbaserade webbläsare göra en märkbar skillnad när det gäller att minska nätverkstrafiken?

Svaret

SuperUser-bidragare gronostaj har svaret för oss:

Webbservern skickar inte hela webbplatsen, men dokument som webbläsare begär. Till exempel, när du kommer åt google.com frågar webbläsaren webbservern för dokumentet google.com. Webbservicen behandlar begäran och skickar tillbaka någon HTML-kod.

Då kontrollerar webbläsaren vad webbservern har skickat. I det här fallet är det en HTML-webbsida, så det analyserar dokumentet och letar efter refererade skript, stilark, bilder, typsnitt, etc.

I detta skede har webbläsaren slutat ladda ner originaldokumentet, men har fortfarande inte laddat ner de refererade dokumenten. Det kan välja att göra det eller hoppa över nedladdning av dem. Vanliga webbläsare försöker hämta alla refererade dokument för bästa visningsupplevelse. Om du har en annons blockerare (som Adblock Plus) eller ett integritets plugin (som Ghostery eller NoScript), då kan det också blockera några resurser.

Då laddar webbläsaren de refererade dokumenten en efter en, varje gång du frågar webbservern uttryckligen för en enda resurs. I vårt Google-exempel kommer webbläsaren att hitta följande referenser (bara för att nämna några av dem):

• https://www.google.com/images/srpr/logo11w.png (Google Logo)
• https://www.google.com/textinputassistant/tia.png (tangentbordsikon)
• https://ssl.gstatic.com/gb/images/i1_3d265689.png (Några kombinerade bilder, ett trick som används för att minska antalet webbläsningsförfrågningar.)

De faktiska filerna kan vara olika för olika användare eftersom webbläsare och sessioner kan ändras över tiden. Textbaserade webbläsare laddar inte ner bilder, Flash-filer, HTML5-video etc., så de laddar ner mindre data.

@NathanOsman gör en bra poäng i kommentarerna. Ibland är små bilder inbäddade direkt i HTML-dokument och i sådana fall kan inte nedladdning av dem undvikas. Detta är ett annat knep som används för att minska antalet förfrågningar. De är väldigt små, annars är överkoden för att koda en binär fil i base64 för stor. Det finns få sådana bilder på google.com (bas64 kodad storlek / avkodad storlek):

• 19 × 11 pixel Tangentbord Ikon (106 Bytes / 76 Bytes)
• 28 × 38 pixlar Mikrofonikon (334 Bytes / 248 Bytes)
• 1 × 1 pixel Genomskinlig GIF (62 Bytes / 43 Bytes) Den visas i Google Chrome: s Dev Tools Resources-flik, men jag kunde inte hitta den i källkoden (förmodligen lagt till senare med JavaScript).
• 1 × 1 pixel Korrekt GIF-fil som visas två gånger. (34 Bytes / 23 Bytes) Dess syfte är ett mysterium för mig.

Har du något att lägga till förklaringen? Ljud av i kommentarerna. Vill du läsa mer svar från andra tech-savvy Stack Exchange-användare? Kolla in hela diskussionsgängan här.