Het lijdt geen twijfel dat de webpagina's van tegenwoordig vol staan met rijke inhoud en meer bandbreedte gebruiken om volledig te laden, maar zou het gebruik van een op tekst gebaseerde browser in plaats van een op een GUI gebaseerde browser een significant verschil maken bij het verminderen van netwerkverkeer? De SuperUser Q & A-post van vandaag bevat de antwoorden op de vraag van een nieuwsgierige lezer.
De vraag- en antwoordsessie van vandaag komt tot ons dankzij SuperUser - een onderdeel van Stack Exchange, een community-gedreven groepering van Q & A-websites.
Lynx Browser screenshot met dank aan Wikipedia .
De vraag
SuperUser-lezer Paulb wil weten of tekstgebaseerde browsers het netwerkverkeer daadwerkelijk kunnen verminderen:
Gebruik tekstgebaseerde browsers zoals Lynx , Links , en ELinks minder bandbreedte verbruiken dan GUI-gebaseerde browsers zoals Firefox, Chrome en Internet Explorer?
Ik vermoed dat er geen vermindering van het verkeer is. Mijn grondgedachte hiervoor is dat ik denk dat een tekstgebaseerde browser de hele pagina downloadt zoals deze wordt aangeboden door de server. Elke stroomlijning of vermindering van pagina-widgetry wordt lokaal gedaan.
Misschien is er enige afname van het verkeer omdat de meeste tekstgebaseerde browsers geen paginascripts of flash-bestanden zullen uitvoeren, wat mogelijk meer verkeer zal veroorzaken.
Kunnen op tekst gebaseerde browsers een merkbaar verschil maken bij het verminderen van netwerkverkeer?
Het antwoord
SuperUser-bijdrager gronostaj heeft het antwoord voor ons:
De webserver verstuurt niet de hele website, maar documenten die browsers opvragen. Als u bijvoorbeeld google.com opent, vraagt de browser de webserver naar het document google.com. De webserver verwerkt het verzoek en stuurt wat HTML-code terug.
Vervolgens controleert de browser wat de webserver heeft verzonden. In dit geval is het een HTML-webpagina, dus het parseert het document en zoekt naar scripts, stijlbladen, afbeeldingen, lettertypen, enz. Waarnaar wordt verwezen.
In dit stadium is de browser klaar met het downloaden van het originele document, maar heeft hij de documenten waarnaar wordt verwezen nog steeds niet gedownload. Het kan ervoor kiezen om dit te doen of het downloaden ervan overslaan. Gewone browsers zullen proberen alle documenten waarnaar wordt verwezen te downloaden voor de beste kijkervaring. Als u een advertentieblokkering heeft ( zoals Adblock Plus ) of een privacy-plug-in ( zoals Ghostery of NoScript ), dan kan het ook enkele bronnen blokkeren.
Vervolgens downloadt de browser de documenten waarnaar wordt verwezen een voor een, waarbij de webserver telkens expliciet om een enkele bron wordt gevraagd. In ons Google-voorbeeld vindt de browser de volgende referenties ( om er maar een paar te noemen ):
- https://www.google.com/images/srpr/logo11w.png (Google-logo)
- https://www.google.com/textinputassistant/tia.png (Toetsenbordpictogram)
- https://ssl.gstatic.com/gb/images/i1_3d265689.png (Sommige gecombineerde afbeeldingen, een truc die wordt gebruikt om het aantal browserverzoeken te verminderen.)
De daadwerkelijke bestanden kunnen voor verschillende gebruikers verschillen, aangezien browsers en sessies in de loop van de tijd kunnen veranderen. Tekstgebaseerde browsers downloaden geen afbeeldingen, Flash-bestanden, HTML5-video, enz., Dus downloaden ze minder gegevens.
@NathanOsman maakt een goed punt in de commentaren . Soms worden kleine afbeeldingen rechtstreeks in HTML-documenten ingebed en in die gevallen kan het downloaden ervan niet worden vermeden. Dit is een andere truc die wordt gebruikt om het aantal verzoeken te verminderen. Ze zijn echter erg klein, anders is de overhead van het coderen van een binair bestand in base64 te groot. Er zijn maar weinig van dergelijke afbeeldingen op google.com ( base64 gecodeerde grootte / gedecodeerde grootte ):
- Toetsenbordpictogram van 19 × 11 pixels (106 bytes / 76 bytes)
- Microfoonpictogram van 28 × 38 pixels (334 bytes / 248 bytes)
- Transparante GIF van 1 × 1 pixel (62 bytes / 43 bytes) Het verschijnt op het tabblad Google Chrome Dev Tools Resources, maar ik kon het niet vinden in de broncode (waarschijnlijk later toegevoegd met JavaScript).
- 1 × 1 pixel Beschadigd GIF-bestand dat twee keer voorkomt. (34 bytes / 23 bytes) Het doel ervan is mij een raadsel.
Iets toe te voegen aan de uitleg? Geluid uit in de reacties. Wilt u meer antwoorden lezen van andere technisch onderlegde Stack Exchange-gebruikers? Bekijk hier de volledige discussiethread .
