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 helt, men skulle en textbaserad webbläsare istället för en GUI-baserad göra en betydande skillnad för att minska nätverkstrafiken? Dagens SuperUser Q & A-inlägg har svaren på en nyfiken läsares fråga.
Dagens Fråga & Svar-session kommer till oss med tillstånd av SuperUser - en underavdelning av Stack Exchange, en community-driven gruppering av Q & A-webbplatser.
Lynx Browser skärmdump med tillstånd av Wikipedia .
Frågan
SuperUser-läsaren Paulb vill veta om textbaserade webbläsare faktiskt kan minska nätverkstrafiken:
Gör textbaserade webbläsare som Lodjur , Länkar och ELinkar konsumerar 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 motivering för detta är att jag tror att en textbaserad webbläsare laddar ner hela sidan eftersom den erbjuds av servern. Eventuell effektivisering eller minskning av sidwidgetry sker lokalt.
Kanske minskar trafiken något eftersom de flesta textbaserade webbläsare inte kör sidskript eller flashfiler, vilket kan orsaka mer trafik.
Kan textbaserade webbläsare göra en märkbar skillnad när det gäller att minska nätverkstrafiken?
Svaret
SuperUser-bidragsgivare gronostaj har svaret för oss:
Webbservern skickar inte hela webbplatsen utan dokument som webbläsare begär. Till exempel när du öppnar google.com frågar webbläsaren webbservern för dokumentet google.com. Webbservern behandlar begäran och skickar tillbaka en del HTML-kod.
Sedan kontrollerar webbläsaren vad webbservern har skickat. I det här fallet är det en HTML-webbsida, så den analyserar dokumentet och letar efter refererade skript, stilark, bilder, teckensnitt etc.
I detta skede har webbläsaren slutfört att ladda ner originaldokumentet, men har fortfarande inte laddat ner de refererade dokumenten. Det kan välja att göra det eller hoppa över nedladdningen. Vanliga webbläsare försöker ladda ner alla refererade dokument för bästa visningsupplevelse. Om du har en annonsblockerare ( som Adblock Plus ) eller ett integritetsplugin ( som Ghostery eller NoScript ), då kan det blockera vissa resurser också.
Därefter laddar webbläsaren ner de refererade dokumenten en efter en, varje gång begär webbservern uttryckligen om en enda resurs. I vårt Google-exempel hittar webbläsaren 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 (Vissa kombinerade bilder, ett trick som används för att minska antalet webbläsarförfrågningar.)
De faktiska filerna kan skilja sig åt för olika användare eftersom webbläsare och sessioner kan förä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 nedladdning inte undvikas. Detta är ett annat trick som används för att minska antalet förfrågningar. De är dock mycket små, annars är kostnaden för att koda en binär fil i base64 för stor. Det finns få sådana bilder på google.com ( base64 kodad storlek / avkodad storlek ):
- 19×11 pixel Keyboard Icon (106 Bytes/76 Bytes)
- 28 × 38 pixel mikrofonikon (334 byte / 248 byte)
- 1 × 1 pixel Transparent GIF (62 byte / 43 byte) Den visas på fliken Resurser i Google Chrome Dev Tools, men jag kunde inte hitta den i källkoden (antagligen tillagd senare med JavaScript).
- 1 × 1 pixel Skadad GIF-fil som visas två gånger. (34 byte / 23 byte) 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 fler svar från andra tekniskt kunniga Stack Exchange-användare? Kolla in hela diskussionstråden här .
