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