Kunnen tekstgebaseerde browsers het netwerkverkeer verminderen?
Het lijdt geen twijfel dat de webpagina's van vandaag vol rijke inhoud zijn en meer bandbreedte gebruiken om volledig te laden, maar zou het gebruik van een op tekst gebaseerde browser in plaats van een op GUI gebaseerde browser een aanzienlijk verschil maken in het verminderen van netwerkverkeer? De SuperUser Q & A-post van vandaag biedt de antwoorden op de vraag van een nieuwsgierige lezer.
De Question & Answer-sessie van vandaag komt tot ons dankzij SuperUser - een onderdeel van Stack Exchange, een gemeenschapsgedreven groep 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:
Gebruiken tekstgebaseerde browsers zoals Lynx, Links en ELinks minder bandbreedte dan GUI-gebaseerde browsers zoals Firefox, Chrome en Internet Explorer?
Ik gok dat er geen vermindering van het verkeer is. Mijn reden hiervoor is dat ik denk dat een tekstgebaseerde browser de hele pagina downloadt zoals deze door de server wordt aangeboden. Elke stroomlijning of vermindering van de pagina-widget wordt lokaal gedaan.
Misschien is er wat minder verkeer, omdat de meeste tekstgebaseerde browsers geen paginascripts of flash-bestanden uitvoeren, wat kan leiden tot meer verkeer.
Kunnen tekstgebaseerde browsers een merkbaar verschil maken in het verminderen van netwerkverkeer?
Het antwoord
SuperUser-bijdrager gronostaj heeft het antwoord voor ons:
De webserver verzendt niet de volledige website, maar documenten die door browsers worden aangevraagd. Wanneer u bijvoorbeeld toegang krijgt tot google.com, vraagt de browser de webserver naar het document google.com. De webserver verwerkt de aanvraag en stuurt enkele HTML-code terug.
Vervolgens controleert de browser wat de webserver heeft verzonden. In dit geval is het een HTML-webpagina, dus wordt het document geparseerd en wordt gezocht naar verwijzingen naar scripts, stijlpagina's, afbeeldingen, lettertypen enzovoort.
In dit stadium is de browser klaar met het downloaden van het originele document, maar heeft het de documenten waarnaar wordt verwezen nog steeds niet gedownload. Het kan ervoor kiezen om dit te doen of het downloaden overslaan. Gewone browsers zullen proberen alle documenten waarnaar wordt verwezen te downloaden voor de beste kijkervaring. Als u een advertentieblokker (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 één voor één, telkens wanneer hij de webserver expliciet om een enkele bron vraagt. 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 (Enkele gecombineerde afbeeldingen, een truc die wordt gebruikt om het aantal browser-aanvragen te verminderen.)
De daadwerkelijke bestanden kunnen voor verschillende gebruikers verschillen, omdat browsers en sessies na verloop van 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 opmerkingen. Soms worden kleine afbeeldingen rechtstreeks ingesloten in HTML-documenten en in die gevallen kan het downloaden ervan niet worden voorkomen. 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 weinig van dergelijke afbeeldingen op google.com (base64-gecodeerde grootte / gedecodeerde grootte):
- Toetsenbordpictogram van 19 × 11 pixels (106 bytes / 76 bytes)
- Microfoonpictogram 28 x 38 pixels (334 bytes / 248 bytes)
- 1 × 1 pixel Transparant GIF (62 bytes / 43 bytes) Het wordt weergegeven op het tabblad Dev Tools-bronnen van Google Chrome, maar ik kon het niet vinden in de broncode (waarschijnlijk later toegevoegd met JavaScript).
- 1 × 1 pixel Beschadigd GIF-bestand dat tweemaal wordt weergegeven. (34 bytes / 23 bytes) Het doel is mij een raadsel.
Heb je iets toe te voegen aan de uitleg? Geluid uit in de reacties. Wilt u meer antwoorden van andere technisch onderlegde Stack Exchange-gebruikers lezen? Bekijk hier de volledige discussiethread.
