Попередній вибір, попереднє завантаження, попередній перегляд

15

Від автора: коли мова заходить про front-end продуктивності, у першу чергу, ми починаємо думати про конкатенації, минификации, кешуванні або стисненні ресурсів на сервері, все це ми робимо для того, щоб сторінки вантажилися швидше, а користувачі могли якомога швидше домогтися необхідних результатів.

Так званий попередній вибір файлів це ще одна техніка по підвищенню продуктивності. З її допомогою ми можемо повідомити браузеру, які файли можуть знадобитися користувачеві ще до того, як такі потрібні.

Patrick Hamann пояснює:

«Попередній вибір це спосіб дати підказку браузеру про те, які ресурси будуть потрібні в будь-якому випадку або які можуть бути використані в майбутньому. Деякі підказки застосовуються до поточної сторінки, інші ж можуть впливати на майбутні сторінки. Як розробники ми знаємо наші програми набагато краще, ніж браузер. Це можна використовувати для інформування про браузера доступних ресурсах.»

Дана практика, коли ми передбачаємо, що користувачеві знадобиться ще до того, як користувач викликав відповідні ресурси, називається попереднє завантаження (prebrowsing). Це не просто техніка, вона підрозділяється на інші: dns-prefetching, подресурсы (subresource), стандартний попередній вибір (prefetch), попереднє з’єднання (preconnect) і попередня візуалізація (prerender).

DNS prefetching

Даний спосіб повідомляє клієнта про те, що є певні ресурси, які знадобляться нам пізніше з певної адреси. Скажімо, нам потрібен ресурс, зображення або аудіо файл з адреси example.com. Тоді в хедері необхідно прописати:

Потім, коли цей файл нам потрібно, нам не потрібно буде чекати, поки відробить DNS. Даний підхід вкрай корисна при роботі зі стороннім кодом третіх осіб або при роботі з ресурсами з соціальних мереж. У другому випадку ми можемо завантажувати ресурси через віджет з допомогою .

У цій фундаментальній статті по front-end продуктивності Гаррі Робертс пропонує використовувати цю техніку:

«Одна єдина рядок говорить браузеру, що потрібно витягнути необхідні ресурси по посиланню з певного домену ще до того, як ресурси дійсно знадобляться. Це означає, що пошук DNS вже буде проходити, як тільки браузер помітить тег віджета. Такий підхід дає браузеру маленьку фору.»

Те, що ми описали, може здатися настільки малим приростом продуктивності, що від нього зовсім немає толку. Однак не обов’язково застосовувати цю техніку тільки за описаним нами сценарієм – Chrome постійно робить подібні речі. Ви тільки почали вводити домен в адресний рядок, а програма вже автоматично добудовує DNS (іноді навіть розмальовує сторінки). Це і є ті самі вирішальні мілісекунди.

Попереднє з’єднання

Також як і в методі попередньої вибірки DNS, метод попереднього з’єднання дозволяє DNS, але крім усього іншого також здійснюється TCP рукостискання і опціонально TLS переговори. Застосувати метод можна так:

Ілля Григорик написав чудову статтю, де все розставлено по поличках:

«Сучасні браузери роблять все, що в їх силах, щоб передбачити адресу ще до переходу на нього. Ініціюючи попередню завантаження, браузер може встановити необхідні сокети і видалити DNS, TCP і TLS пробіжки ще до самого запиту. Тим не менш, наскільки б не були розумні браузери, вони все ще не можуть передбачити всі можливі з’єднання для кожного сайту. Хороша новина в тому, що ми можемо допомогти браузеру; ми можемо повідомити браузеру необхідний сокет ще до самого запиту за допомогою нової підказки в попередньому з’єднанні в нових версіях Firefox 39 і Chrome 46!»

Попередній вибір

Якщо ми точно знаємо, що якийсь ресурс нам у майбутньому буде потрібно, ми можемо попросити браузер, щоб він завантажив його в кеш на якийсь час, щоб ми могли до нього потім звертатися. Прикладом може стати зображення або скрипт, або що завгодно, що можна кешувати:

На відміну від попередньої вибірки DNS в даному випадку ми по-справжньому запитуємо потрібний файл, завантажуємо його і зберігати в кеші. Попередня вибірка може бути заблокована браузером, тому необхідно дотримати деякі умови. Наприклад, користувач може скасувати запит на завантаження об’ємного файлу шрифтів при повільному з’єднанні. Firefox робить предвыборку тільки, якщо браузер знаходиться в «режимі очікування».

Як Bram Stein explains пояснює у своїй статті, даний підхід дав би величезний приріст продуктивності веб-шрифтів. На даний момент шрифт зобов’язаний дочекатися побудови DOM і CSSOM ще до того, як вони завантажилися. Інша справа, якщо ми зробимо предвыборку за DOM і CSSOM, тоді цей момент легко вирішується.

Зверніть увагу: Раніше попередня вибірка ресурсів була незручна для тестування, але тепер у Chrome і Firefox ресурси передвибірки відображаються у вкладці Мережу. Також варто пам’ятати, що не існує загальних обмежень за попередніми вибірках.

Подресурсы

Ще одна техніка вибору, але на відміну від вище описаних вона розрізняє ресурси з різними пріоритетами і ті, які стоять вище завантажуються першими. Наприклад, для Chrome і Opera можна додати наступний код в шапку:

По документації Chromium даний метод працює наступним чином:

«LINK rel=subresource» являє собою новий тип зв’язку посилань з відмінною від LINK rel=prefetch семантикою. У той час як LINK rel=prefetch забезпечує низкоприоритетную завантаження ресурсів для подальшого їх використання на майбутніх сторінках, rel=subresource служить для ранньої завантаження поточної сторінки.

Отже: якщо ресурс буде потрібно на поточній сторінці або через якийсь час, то краще використовувати subresource, в іншому випадку prefetch.

Попередня візуалізація сторінок

Ця техніка працює на рівні ядра, prerender дозволяє заздалегідь завантажити всі ресурси поточної сторінки:

Steve Souders чудово роз’яснив цю техніку:

«Це як перейти за адресою на закритій вкладці – всі ресурси завантажені, DOM побудований, сторінка завантажилася, CSS применился, JavaScript теж виконався і т. д. Якщо користувач переходить за вказаною href, то прихована сторінка моментально відображається. В пошуку Google ця фішка вже давно доступна і називається вона Миттєві сторінки. Нещодавно і Microsoft оголосили про створення схожого способу попередньої візуалізації в Bing IE11.»

Але будьте обережні! Ви повинні бути впевнені на 100%, що користувач перейде по посиланню, інакше браузер буде завантажувати всі ресурси для відтворення сторінки, яку користувач так і не побачить.

Steve Souders також говорить:

«Як і з будь-якими прогнозами є шанс, що вони не збудуться. Якщо предзагрузка занадто затратна (наприклад, завантажує CPU, споживає занадто багато батареї або забиває мережа), то краще її не використовувати або використовувати, але з обережністю. Здавалося б, що може бути важче, ніж визначити, за якою ссылке далі перейде користувач. Однак існують так звані сценарії високої довіри:

Якщо користувач ввів в пошуковику очевидний запит, і ви точно знаєте, з якоїсь засланні він перейде.

Якщо шукає сторінку входу, то вона, звичайно, повинна бути наступною.

Якщо користувач читає статтю або які-небудь результати на кількох сторінках, то, очевидно, за поточною сторінкою повинна йти наступна.»

І нарешті, Page Visibility API можна використовувати для захисту від самозапускающихся скриптів, щоб вони не отрисовывались на екрані. Отже, поговоривши про поточні способи попереднього завантаження, давайте обговоримо майбутні доповнення в специфікацію, які можуть бути цікаві.

Додаток в майбутньому: попереднє завантаження

Нова специфікація preload свідчить, що іноді краще всього постійно завантажувати певні ресурси, незважаючи на думки браузера з цього приводу. Основна відмінність від попередньої вибірки в тому, що предзагрузку не можна проігнорувати.

Висновок

Дуже складно передбачити, куди ж користувач вирушить далі, цей процес вимагає ретельного планування і тестування, але очікуваний приріст продуктивності того варто.