Коли ми говоримо про продуктивність на фронтенді, ми зазвичай думаємо про такі речі як конкатенація, мініфікація, кешування і стиснення ресурсів на сервері, що дозволяють завантажити сторінку швидше і допомогти користувачам швидше досягти своїх цілей.
Попередня вибірка ресурсів (префетчінг) це ще одна техніка, яка покращує продуктивність. Ми можемо використовувати її, щоб повідомити браузеру, які ресурси можуть знадобитися для найближчому майбутньому, перш ніж користувач їх реально запросить.
Префетчінг це спосіб попередження браузера про ресурсах, які, швидше за все, будуть використані в майбутньому, деякі попередження стосуються поточної сторінки, деякі стосуються майбутніх сторінок. Як розробники ми знаємо, що наші програми краще, ніж браузер. І ми можемо передати цю інформацію браузеру.
Практика передбачення потреб користувачів в ресурсах називається пребраузінг. Це складовою термін, сюди відноситься цілий набір різних технік - dns-prefetch. subresource. preconnect. the standard prefetch і prerender.
DNS-prefetch
У своєму епічному тексті про продуктивність фронтенда Гаррі Робертс пропонує використовувати цю техніку:
Ця проста рядок дає команду підтримує браузерам почати пошук DNS для зазначеного домену до того, як це дійсно знадобитися. Це означає, що процес пошуку DNS буде завершено до того моменту, коли він буде потрібно, то є браузер отримує невелику фору при завантаженні ресурсів з "префетченного URL".
preconnect
Цей метод дуже схожий на префетчінг DNS, але крім дозволу DNS даний метод починає TCP-з'єднання і узгодження TLS при захищеному з'єднанні.
Детально цей метод описаний в недавній статті Іллі Григорик:
Сучасні браузери намагаються передбачити, які з'єднання будуть потрібні сайту до скоєння запитів. Ініціюючи ранні "предсоедіненія", браузер може налаштувати необхідні сокети заздалегідь і видалити всі витратні роботи з DNS, TCP і TLS з критичного шляху поточного запиту. Але хоч як мене були просунуті сучасні браузери, вони не зможуть виділити відповідні цілі предсоедіненія для всіх сайтів. Гарна новина полягає в тому, що тепер ми можемо підказати браузеру, які сокети треба відкрити перед ініціацією запиту завдяки технології предсоедіненія, реалізованої в Firefox 39 і Chrome 46!
Якщо ми впевнені, що певний файл обов'язково знадобитися через деякий час, ми можемо попросити браузер заздалегідь завантажити його і зберегти в кеші для подальшого використання. Це може бути зображення або скрипт, або що-небудь ще, кешувального браузером.
На відміну від префетчінга DNS, браузер запитує і викачує шуканий ресурс і зберігає його в кеші. Однак, це залежить від деяких умов, префетчінг може бути і проігнорований браузером. Наприклад, якщо запитується великий файл зі шрифтами при повільному інтернет-з'єднанні. А Firefox предзагружает ресурси тільки перебуваючи в ледачому режимі.
Брем Стейн в своєму пості з цього питання пише, що це може дати помітне поліпшення продуктивності при завантаженні веб-шрифтів. На даний момент файли зі шрифтами перед завантаженням чекають побудови DOM і CSSOM. Префетчінг дозволяє обійти викликані цим проблеми з продуктивністю.
Примітка: останні версії Chrome і Firefox показують, які з ресурсів були предзагружени на вкладці "Мережа" в інструментах розробника. Також корисно пам'ятати, що для префетчінга немає обмежень "same-origin", тобто ви можете задати предзагрузкі ресурсів з будь-якого домену.
subresource
Ще одна техніка префетчінга допомагає ідентифікувати ресурси з максимальним пріоритетом, які повинні запитуватися в першу чергу. Наприклад, в Chrome і Opera ми можемо додати в head наступний запис:
Згідно з документацією Chrome цей запис працює наступним чином:
"LINK rel = subresource" надає новий тип зв'язку посилань з відмінною від LINK rel = prefetch семантикою. У той час як rel = prefetch задає пріоритет для завантаження ресурсів для інших сторінок, rel = subresource дає ранню завантаження ресурсів для поточної сторінки.
Отже, якщо ресурс буде потрібно на поточній сторінці або ж буде потрібно максимально швидко, краще використовувати subresource. а в інших випадках prefetch.
Ця абсолютно атомна опція - prerender дозволяє превентивно завантажити всі файли і ресурси для певного документа:
Але будьте обережні. Ви повинні бути впевнені, що користувач перейде за потрібною лінку, інакше клієнт даремно завантажить всі ресурси для рендеринга сторінки.
Як і з будь-якої упреждающей роботою, існує ризик, що вона виявиться марною. І якщо вона затратна (відбирає багато ресурсів процесора, розряджає батарею або забирає багато трафіку), то обережність необхідна. Вгадування намірів користувача може здатися складним, але найбільш поширеними є такі сценарії: * Якщо це результат пошуку і він очевидний, то ця сторінка швидше за все буде завантажена. * Якщо користувач перейшов на сторінку логіна, то на наступній сторінці буде підтвердження логіна. * Якщо користувач читає статтю, розбиту на декілька сторінок, він швидше за все перейде на сторінку, наступну за поточною.
Нарешті, Page Visibility API може використовуватися для захисту від запуску скриптів до їх рендеринга на сторінці.
Му вже обговорили всі поточні різновиди префетчінга, прийшов час зайнятися можливостями, які будуть реалізовані в майбутньому.
Майбутня можливість: preload
У новій специфікації, предзагрузкі використовується для тих ресурсів, які викачуються завжди. незалежно від браузера. Якщо префетчінг може бути проігнорований браузером, ресурси в предзагрузкі запитуються браузером в будь-якому випадку.
Незважаючи на те, що предзагрузкі поки не підтримується жодною з браузерів, ця ідея, безумовно, цікава.
висновок
Передбачення того, що будуть робити користувачі, вимагає планування і тестування, але вигоди в продуктивності варті того. І якщо ми хочемо поліпшити продуктивність, нам варто поекспериментувати з цими техніками.