Чи зменшується мережевий трафік за допомогою текстових браузерів?
Немає сумніву, що сьогоднішні веб-сторінки наповнені багатим контентом і використовують більшу пропускну здатність для повної завантаження, але чи буде використання текстового браузера замість графічного інтерфейсу істотно змінити мережевий трафік? Сьогоднішня посада SuperUser Q&A має відповіді на запитання цікавого читача.
Сьогоднішня сесія запитань та відповідей приходить до нас люб'язно SuperUser - підрозділ Stack Exchange, групування веб-сайтів із запитаннями та відповідями на рівні спільноти..
Скріншот Lynx Browser надано Вікіпедією.
Питання
Читач від суперкористувача Paulb хоче знати, чи можуть текстові браузери фактично зменшити мережний трафік:
Чи використовують текстові браузери, такі як Lynx, Links і ELinks, меншу пропускну здатність, ніж графічні інтерфейси, такі як Firefox, Chrome і Internet Explorer?
Я здогадуюсь що немає зменшення у перевезенні. Моя обґрунтування цього полягає в тому, що я вважаю, що текстовий браузер завантажує всю сторінку, як вона пропонується сервером. Будь-яка оптимізація або зменшення розмітки сторінок здійснюється локально.
Можливо, трафік зменшився, оскільки більшість текстових браузерів не виконуватимуть скриптів сторінок або флеш-файли, що може призвести до збільшення трафіку.
Чи можуть текстові браузери помітно змінити мережевий трафік?
Відповідь
Співробітник SuperUser gronostaj має відповідь для нас:
Веб-сервер не надсилає весь сайт, а документи, які запитує браузер. Наприклад, коли ви отримуєте доступ до google.com, браузер запитує веб-сервер для документа google.com. Веб-сервер обробляє запит і відправляє назад якийсь HTML-код.
Потім браузер перевіряє, що веб-сервер надіслав. У цьому випадку це веб-сторінка HTML, тому вона розбирає документ і шукає посилання, скрипти, таблиці стилів, зображення, шрифти тощо..
На цьому етапі браузер закінчив завантаження оригінального документа, але досі не завантажив згадані документи. Він може зробити це або пропустити завантаження. Регулярні браузери намагатимуться завантажити всі посилання на документи для кращого перегляду. Якщо у вас є блокування об’яв (як Adblock Plus) або плагін конфіденційності (як Ghostery або NoScript), тоді він також може блокувати деякі ресурси.
Потім браузер завантажує відповідні документи один за одним, кожен раз запитуючи веб-сервер явно про один ресурс. У нашому прикладі Google веб-переглядач знайде такі посилання (просто назвати деякі з них):
- https://www.google.com/images/srpr/logo11w.png (Google Logo)
- https://www.google.com/textinputassistant/tia.png (значок клавіатури)
- https://ssl.gstatic.com/gb/images/i1_3d265689.png (Деякі комбіновані зображення, трюк для зменшення кількості запитів на веб-переглядачі.)
Фактичні файли можуть відрізнятися для різних користувачів, оскільки браузери та сесії можуть змінюватися з часом. Текстові браузери не завантажують зображення, флеш-файли, відео HTML5 тощо, тому вони завантажують менше даних.
@NathanOsman робить хороший момент в коментарях. Іноді невеликі зображення вбудовуються безпосередньо в документи HTML, і в цих випадках їх не можна уникнути. Це ще один трюк, який використовується для зменшення кількості запитів. Вони дуже малі, але в іншому випадку накладні витрати на кодування двійкового файлу в base64 занадто великі. Таких зображень на google.com мало (розмір закодованого розміру base64 / декодованого розміру):
- Піктограма клавіатури 19 × 11 пікселів (106 байтів / 76 байтів)
- Піктограма мікрофона 28 × 38 пікселів (334 байтів / 248 байтів)
- Прозорий GIF розміром 1 × 1 піксель (62 байта / 43 байта) Він відображається на вкладці Ресурси інструментів програми Google Chrome, але я не міг знайти його в вихідному коді (можливо, додано пізніше за допомогою JavaScript).
- 1 × 1 піксель Пошкоджений файл GIF, який з'являється двічі. (34 Bytes / 23 Bytes) Його мета - це для мене таємниця.
Маєте щось додати до пояснення? Звучить в коментарях. Хочете прочитати більше відповідей від інших технологічних користувачів Stack Exchange? Перегляньте повний потік обговорення тут.
