33 способу прискорити ваш фронтенд в 2017 році

enter image description here
Ви вже використовуєте прогресивну завантаження? А як щодо технологій Tree Shaking і розбиття коду в React і Angular? Ви налаштували стиснення Brotli або Zopfli, OCSP stapling і HPACK-стиснення? А як у вас справи з оптимізацією ресурсів та клієнтської частини, з вкладеністю CSS? Не кажучи вже про IPv6, HTTP/2 і сервіс-воркерах.
Були часи, коли продуктивність найчастіше поліпшували заднім числом. Роботу над нею відкладали до самого завершення проекту, і все зводилося до минификации, конкатенації, оптимізації ресурсів і, якщо пощастить, кільком тонким налаштуванням на стороні сервера. З тих пір ситуація значно змінилася.
Завдання підвищення продуктивності перестала бути суто технічним питанням. Тепер вона впроваджена в спільний робочий процес, і ті чи інші архітектурні рішення оцінюються з точки зору їх впливу на швидкість роботи системи. Продуктивність потрібно постійно моніторити, вимірювати і уточнювати, але з ростом складності веба перед розробниками постають все нові проблеми, що ускладнюють відстеження метрик, адже вони сильно залежать від пристроїв, браузерів, протоколів, типів мереж і затримки (CDN, інтернет-провайдери, кеші, проксі, файрволы, балансировщики навантаження і сервери — все це впливає на продуктивність).
Але якщо описувати всі фактори, про які слід пам'ятати при поліпшенні продуктивності — з початку роботи над проектом до запуску сайту, то як буде виглядати такий список? Нижче ви знайдете (сподіваюся, неупереджений і об'єктивний) чек-лист по поліпшенню продуктивності фронтенда на 2017 рік. Це огляд проблем, які потрібно вирішити для зменшення часу відгуку сайту і його плавної роботи.
Чек-лист
Микрооптимизации дозволяють тримати продуктивність під контролем, але при цьому вкрай важливо ясно уявляти собі конкретні цілі: вони повинні бути вимірні і впливати на всі вжиті в процесі роботи рішення. Існує декілька різних моделей, і ті, що будуть обговорюватися далі, дуже категоричні. Тому переконайтеся, що ви з самого початку обрали свої власні пріоритети.

Підготовка та вибір цілей


1. Будьте на 20% швидше за свого найшвидшого конкурента
Згідно з одним психологічного дослідження якщо ви хочете, щоб ваші користувачі сприймали ваш сайт як найшвидший, вам потрібно бути як мінімум на 20% швидше. Час повного завантаження сторінки нерелевантно на відміну від таких показників, як час початку показу, час до першого корисного екрану (тобто час, необхідне для відображення на сторінці первинного контенту) і час до початку взаємодії (час, через яке сторінка (і в першу чергу одностраничное додаток) виявляється готова до того, щоб користувач міг з нею взаємодіяти).
Виміряйте час до початку відтворення (з допомогою WebPagetest) і до першого корисного екрану (за допомогою Lighthouse на Moto G, якому-небудь смартфоні Samsung бізнес-класу і рядовому пристрої на кшталт Nexus 4 (бажано в який-небудь відкритої лабораторії на звичайних 3G-, 4G і Wi-Fi-підключення.

Lighthouse, новий інструмент аудиту продуктивності, розроблений Google
Проаналізуйте отримані результати, щоб зрозуміти, яка ситуація у ваших користувачів. Потім можете для тестування імітувати 90-й перцентиль. Зберіть дані таблицю, зріжте 20% і поставте собі конкретні цілі (бюджет продуктивності). Тепер ви можете при тестуванні орієнтуватися на конкретні показники. Якщо ви будете тримати бюджет в розумі і намагатися придушити» хоча б найменший скрипт заради зменшення часу до початку взаємодії, то ви на вірному шляху.
enter image description here
Performance budget builder
Поділіться чек-листом з колегами. Ознайомте з ним кожного члена команди, щоб уникнути непорозумінь. Кожне рішення впливає на продуктивність, і проект дуже сильно виграє від залучення фронтенд-розробників в процес прийняття рішень щодо концепції, UX та дизайну. Прив'яжіть дизайн рішення до бюджету продуктивності і пріоритетів, накреслених у чек-листі.
2. Час відгуку – 100 мілісекунд, 60 кадрів в секунду
Модель продуктивності RAIL задає правильні цілі: зробіть все можливе, щоб користувачі отримували відгук раніше, ніж через 100 мс після початкового введення даних. Для цього сторінка повинна повертати управління головного потоку не пізніше ніж через кожні <50 мс. У високонавантажених зонах зразок анімації скрізь, де можливо, краще нічого не робити, або робити абсолютний мінімум.
Крім того, кожен кадр анімації повинен завершуватися менш ніж за 16 мс, щоб забезпечити частоту 60 кадрів/с (1 ÷ 60 = 16,6 мс). Бажано — менш ніж за 10 мс. Оскільки браузеру потрібно час для показу нового кадру, ваш код повинен завершити виконання раніше 16,6 мс. Будьте оптимістичні з розумом скористайтесь часом очікування. Очевидно, що ці цілі відносяться до runtime-продуктивності, а не до продуктивності завантаження.
3. Перший корисний екран менш ніж за 1,25 с, Speed Index нижче 1000
Хоча це може виявитися дуже важкодосяжним, ваша головна мета — початок відтворення менш ніж через 1 с і значення Speed Index нижче 1000 (на швидких підключення). До першого корисного екрану не повинна перевищувати 1250 мс. Для мобільних пристроїв, підключених по 3G, вважається прийнятним початок відтворення не пізніше ніж через 3 с. Навіть якщо буде трохи довше, не страшно, але намагайтеся зменшити це значення.

Визначте середу


4. Виберіть і встановіть інструменти для складання
Не звертайте занадто багато уваги на те, що сьогодні вважається нібито крутим. Дотримуйтеся свого середовища для складання, будь то Grunt, Gulp, Webpack, PostCSS або якась комбінація інструментів. Поки ви досить швидко отримуєте результати і не відчуваєте проблем з підтриманням процесу складання, ви все робите правильно.
5. Прогресивне поліпшення
Нехай прогресивне поліпшення буде основним принципом ваших фронтенд-архітектури і розгортання, це безпрограшний варіант. Спочатку створюйте основні схеми взаємодії, а потім розширюйте їх можливостями, підтримуваними різними браузерами, створюючи відмовостійкі схеми. Якщо ваш сайт працює швидко на повільних машинах з паршивенькими екранами, у застарілих браузерах і неоптимальних мережах, то він буде працювати ще швидше на швидких машинах з хорошими браузерами і пристойною мережею.
6. Angular, React, Ember і компанія
Виберіть фреймворк, який дозволяє виконувати рендеринг на сервері. Обов'язково виміряйте час завантаження на мобільних пристроях в режимах відтворення на серверної, і на клієнтської сторонах, перш ніж зупинитися на конкретному фреймворку (потім буде дуже складно «міняти коней на переправі», і це призведе до проблем з продуктивністю). Якщо ви вирішите скористатися JS-фреймворком, то обов'язково переконайтеся, що ваш вибір – продуманий, осознанный. Різні фреймворки по-різному впливають на продуктивність і вимагають різних підходів до оптимізації, так що потрібно чітко розуміти всі переваги і недоліки обраного вами інструменту. При створенні веб-додатки зверніть увагу на PRPL-патерн і архітектуру оболонки програми.
enter image description here
PRPL розшифровується як Pushing critical resource, Rendering initial route, Pre-caching remaining routes and Lazy-loading remaining routes on demand: передача критичних ресурсів, відтворення початкового маршруту, попереднє кешування інших маршрутів, відкладене завантаження решти маршрутів по запиту.
enter image description here
Оболонка програми — це поєднання HTML, CSS і JavaScript, мінімально необхідне для роботи інтерфейсу
7. AMP або Instant Articles?
В залежності від пріоритетів і стратегії, прийнятих у вашій організації, ви можете скористатися Google AMP або Facebook Instant Articles. Можна і без них домогтися гарної продуктивності, але AMP пропонує надійний та швидкий фреймворк з безкоштовною мережею доставки контенту (CDN), а Instant Articles підвищує продуктивність ваших продуктів в Facebook. Також є можливість створювати прогресивні веб-AMP.
8. Вибирайте CDN з розумом
В залежності від того, скільки у вас динамічних даних, спробуйте «винести» частина контенту генератор статичних сайтів, передаючи його в CDN і обслуговуючи таким чином статичну версію, уникаючи запитів до бази даних. Можна навіть вибрати платформу статичного хостингу на базі CDN, поліпшивши сторінки за допомогою інтерактивних компонентів-розширень (JAMstack).
Ви звернули увагу, що CDN може обслуговувати (і розвантажувати) ще і динамічний контент? Немає потреби обмежувати її лише статичними ресурсами. Переконайтеся, що обрана CDN виконує стиснення та конвертування вмісту, підтримує розумну доставку допомогою HTTP/2, технологію ESI, за допомогою якої статичні і динамічні частині сторінок збираються на стороні CDN (тобто в найближчій до серверної частини), та вирішує інші завдання.

Оптимізація складання


9. Встановіть пріоритети
Перш за все, потрібно розуміти, з чим ви маєте справу. Проведіть інвентаризацію всіх ресурсів (JavaScript, зображення, шрифти, сторонні скрипти і «дорогі» модулі на сторінці начебто каруселей, складною інфографіки та мультимедійного контенту) і розділіть їх на групи.
Побудуйте таблицю. Визначте основну функціональність для застарілих браузерів (тобто повну доступність основного вмісту), розширену функціональність для сучасних браузерів (тобто поліпшену, повну функціональність) і додаткові матеріали (ресурси, в яких немає необхідності і які можуть подгружаться ліниво: веб-шрифти, додаткові стилі, скрипти каруселей, відеоплеєри, кнопки соцмереж, великорозмірні зображення). Детальніше про це можна почитати в статті Improving Smashing magazine's Performance.
10. Використовуйте підхід Cutting the Mustard
використовується для передачі застарілим браузерам основний, а сучасним браузерам — розширеної функціональності. Будьте суворі при завантаженні своїх ресурсів: негайно вантажте основну функціональність, розширення — з подій
DOMContentLoaded
, а додаткові матеріали — по подіям
load
.
Зверніть увагу, що цей підхід визначає можливості пристрою за версією браузера, що сьогодні робити вже не слід. Наприклад, на дешевих Android-смартфонах у країнах, що розвиваються, здебільшого працює Chrome, тому описаний сценарій буде виконуватися, незважаючи на невеликий обсяг оперативки і скромний процесор. Хоча на даний момент альтернативи такому підходу немає, потрібно розуміти, що останнім часом він все рідше і рідше потрібно.
11. Розгляньте питання микрооптимизаций і прогресивної завантаження
У ряді випадків потрібно якийсь час на ініціалізацію програми, перш ніж перетворювати сторінку. Замість індикаторів завантаження краще використовувати каркасне відображення. Пошукайте модулі і методики, що дозволяють зменшити час первинної відтворення (наприклад, Tree-Shaking і розбиття коду), тому що більшість проблем з продуктивністю відноситься до первинного парсингу при запуску програми. Також використовуйте AOT-компилятор для перенесення частини клієнтської відтворення на сторону сервера, що прискорить отримання гідного результату. Нарешті, розгляньте можливість застосування Optimize-js для більш швидкої первинної завантаження за рахунок обгортання негайно викликаються функцій (хоча це може бути вже і необов'язково).
enter image description here
Прогресивна завантаження — це відображення сторінки на стороні сервера для зменшення часу до першого корисного екрану (це вимагає якогось мінімального JavaScript, необхідного для того, щоб час до початку взаємодії було близько до часу до першого корисного екрану)
Що краще — рендеринг на стороні клієнта або сервера? В обох випадках необхідно налаштувати прогресивну завантаження: рендеринг на стороні сервера прискорить появу першого корисного екрану, але це вимагає якогось мінімального JavaScript, необхідного для того, щоб час до початку взаємодії було близько до часу до першого корисного екрану. Потім вже ми можемо довантажити другорядні частини програми, за запитом або якщо дозволяє час. На жаль, у фреймворках зазвичай відсутня поняття пріоритетів, явно надаються розробникам, так що з більшістю бібліотек та фреймворків прогресивну завантаження реалізувати непросто. Якщо у вас є час і ресурси, то можете скористатися цією стратегією для істотного підвищення продуктивності.
12. Правильно налаштовані заголовки HTTP кешу?
Перевірте, щоб
expires
,
cache-control
,
max-age
та інші заголовки HTTP кешу були настроєні правильно. В цілому, ресурси повинні кешуватися або на дуже короткий термін (якщо вони можуть змінитися), або на невизначений (якщо вони статичні) — при необхідності можна поміняти їх версію в URL.
Щоб уникнути ревалідацію fingerprinted-ресурсів, по можливості використовуйте призначений для них
Cache-Control: immutable
(станом на грудень 2016 року підтримується тільки в Firefox в транзакціях
https://
). Можете почитати допомога по заголовках HTTP кешу, статтю «Кращі методики кешування» і ще одне допомога по HTTP-кешуванню.
13. Обмежте вплив сторонніх бібліотек і асинхронно завантажуйте JavaScript
Коли користувач запитує сторінку, браузер бере HTML і збирає DOM, потім бере CSS і збирає CSSOM, а потім генерує дерево відтворення, зіставляючи DOM і CSSOM. Якщо потрібно обробити якийсь JavaScript, то браузер не почне перетворювати сторінку, поки не завершиться обробка. Тому розробники повинні чітко сказати» браузеру, щоб він не чекав і відразу починав малювати. Для скриптів це робиться за допомогою HTML-атрибутів
defer
та
async
.
Але на практиці краще
замість async
defer
заради користувачів IE до версії 9 включно, в іншому випадку у них можуть не працювати скрипти). Також рекомендується обмежити вплив сторонніх бібліотек і скриптів, особливо кнопок соціальних мереж і вбудованих
<iframe>
. В якості альтернативи можна використовувати статичні кнопки соцмереж (наприклад, SSBG і статичні посилання на інтерактивні карти.
14. Правильно оптимізовані зображення?
Як можна більше використовуйте адаптивні зображення
srcset
,
sizes
і елементом
<picture>
. І заодно можете застосовувати формат WebP для обслуговування WebP-зображень з елементом
<picture>
і запасним JPEG (приклад коду або використовувати узгодження змісту (content negotiation) (з допомогою заголовків
Accept
). Sketch нативно підтримує WebP, до того ж є плагін для експорту WebP-зображень з Photoshop. Доступні й інші варіанти.
enter image description here
Генератор Responsive Image Breakpoints Generator автоматизує створення зображень і розмітки
клієнтські хінти, які сьогодні починають підтримуватися браузерами. Не вистачає ресурсів для створення складної розмітки для адаптивних зображень? Для автоматизації оптимізації зображень використовуйте Responsive Image Breakpoints Generator або сервіси на кшталт Cloudinary.
Також у багатьох випадках застосування одних лише
srcset
та
sizes
допоможе досягти значних результатів. У Smashing Magazine для імен зображень ми використовуємо закінчення-opt. Наприклад,
brotli-compression-opt.png
; якщо зображення має таке закінчення, то все в команді розуміють, що картинка була оптимізована.
15. Переходьте на новий рівень оптимізації зображень
Працюючи над лэндинговой сторінкою, для якої важлива блискавична завантаження певного зображення, переконайтеся, що використовуєте прогресивні JPEG'і зі стисненням MozJPEG (це зменшує час до початку відтворення за рахунок маніпулювання рівнями сканування), Pingo PNG, Lossy GIF для GIF і SVGOMG для SVG. Застосуйте розмиття до маловажним частинам зображення (наприклад, з допомогою фільтра «розмивання по Гауссу»), щоб зменшити розмір файлу. Можна навіть зменшити колірну палітру або зробити додаток чорно-білим. Для фонових зображень при експорті з Photoshop встановлюйте якість від 0 до 10%, цього буде цілком достатньо.
Все ще недостатньо швидко? Ну, можна ще поліпшити продуктивність з допомогою різних методик, що застосовуються до фонових картинок (1 2, 3, 4).
16. Оптимізовані веб-шрифти?
Напевно використовувані вами веб-шрифти використовують гліфи та інші додаткові символи, які не будуть використовуватися. Заради зменшення розмірів файлів можете звернутися до постачальника з проханням надати зменшений набір символів або вирізати все зайве самостійно, якщо ви використовуєте opensource-шрифти (наприклад, залишивши лише латинський алфавіт і кілька уточнюючих гліфів). Класна річ — підтримка WOFF2, а для браузерів, які не підтримують його, можна застосовувати WOFF і OTF. Також виберіть одну з стратегій, описаних у статті Comprehensive Guide to Font Loading Strategies, і використовуйте кеш сервіс-воркера для надійного кешування веб-шрифтів.
Потрібно швидке рішення? Вивчіть цей матеріал, щоб вантажити шрифти в певному порядку.
enter image description here
статті Comprehensive Guide to Font Loading Strategies описані десятки способів поліпшення доставки веб-шрифтів
Якщо ви не можете передавати шрифти зі свого сервера і покладаєтеся на сторонні хости, то скористайтеся Web Font Loader. Краще використовувати FOUT, ніж FOIT. Відразу ж почніть перетворювати текст в запасний версії шрифту і подгружайте шрифти асинхронно. Для цього можна застосовувати loadCSS. Можливо, вам взагалі вдасться обійтися встановлених в операційній системі шрифтів.
17. Швидко передавайте критичний CSS
Щоб браузер як можна швидше починав малювати сторінку, стандартною практикою є збір всього CSS, необхідного для відтворення видимої частини першої сторінки («критичний CSS», або «CSS без прокрутки екрана» (above-the-fold CSS)) з наступним вбудовуванням в розділ
<head>
сторінки. Це знижує кількість звернень до сервера. Із-за обмеженого розміру пакетів, якими сторони обмінюються в ході повільної початкової фази, ваш бюджет критичного CSS становить близько 14 Кб. Якщо ви перевищите, браузеру знадобиться додатковий roundtrip для отримання стилів. Утриматися в рамках бюджету вам допоможуть CriticalCSS і Critical. Можливо, їх доведеться застосовувати з кожним шаблоном. По можливості використовуйте метод умовного вбудовування, практикований Filament Group.
У випадку з HTTP/2 критичний CSS можна зберігати в окремому файлі і доставляти з ініціативи сервера (server push) без роздування HTML. Суть в тому, що такий тип доставки не має обов'язкової підтримки і має деякі проблеми з кешуванням (див. слайд 114 презентації). Так що ефект може виявитися навіть негативним: мережеві буфери збільшаться в розмірах, що запобіжить доставку в документ оригіналів фреймів. Із-за повільного старту TCP доставка з ініціативи сервера набагато ефективніше на гарячих з'єднання. Можливо, вам знадобиться створити механізм такий доставки допомогою HTTP/2, залежний від кеша. Але пам'ятайте, що нова специфікація кешування скасує необхідність вручну створювати подібні «залежні від кеша» сервери.
18. Використовуйте Tree Shaking та розділення коду для зниження корисного навантаження
Tree Shaking — це спосіб очищення вашого процесу складання за рахунок включення тільки того коду, який використовується в робочому проекті. Для виключення надлишок при експорті можете скористатися Webpack 2, а для видалення невикористовуваних стилів CSS — UnCSS або Helium. Можливо, вам буде корисно почитати про те, як писати ефективні CSS-селектори, а також уникати роздування і підвищення вартості стилів.
Розбиття коду — інша функція Webpack. Кодова база ділиться на «чанкі», які вантажаться за запитом. Після того, як ви вкажете точки розбиття в коді, Webpack подбає про залежностях і генеруються файлах. Розділення коду дозволяє зменшити обсяг даних при початковій завантаженні, подгружая наступні порції коду по мірі необхідності.
Зверніть увагу, що Rollup демонструє значно кращі результати порівняно з експортом Browserify. У цьому випадку ви, ймовірно, захочете «помацати» Rollupify, перетворює модулі ECMAScript 2015 в один великий модуль CommonJS — адже маленькі модулі можуть напрочуд сильно знижувати продуктивність в залежності від обраного пакувальника (Bundler) та модульної системи.
19. Покращуємо продуктивність відтворення
З допомогою обмеження CSS ми можемо ізолювати дорогі компоненти. Наприклад, для обмеження області видимості браузерних стилів, макета, відтворення для прихованої навігації (paint work for off-canvas navigation) або сторонніх віджетів. Переконайтеся у відсутності лагів при прокручуванні сторінки або при роботі анімації елементів. Також перевірте, щоб частота кадрів постійно була не менше 60 кадрів/с. Якщо цього досягти не вдається, то хоча б утримуйте частоту в межах від 15 до 60. Щоб повідомити браузеру, які елементи і властивості зміняться, використовуйте
will-change
з CSS.
Також вимірюйте продуктивність відтворення в ході виконання (наприклад, DevTools). Для початку ознайомтеся з безкоштовним курсом на Udacity по оптимізації відтворення в браузері. Також можете почитати статтю про анімацію з використанням GPU.
20. Прогрів з'єднання для прискорення доставки
Використовуйте каркасне відображення (skeleton screens) і ліниву завантаження всіх дорогих компонентів, таких як шрифти, JavaScript, каруселі, відео iframe. Використовуйте хінти для ресурсів для економії часу на:
  • dns-prefetch
    (шукає DNS
    фоновому режимі),
  • preconnect
    (просить браузер у фоновому режимі почати хендшейк для встановлення з'єднання (DNS, TCP, TLS)),
  • prefetch
    (просить браузер запросити ресурси),
  • prerender
    (просить браузер промалювати певні сторінки у фоновому режимі),
  • preload
    (крім іншого, заздалегідь вибирає ресурси без їх виконання).
Зверніть увагу: на практиці в залежності від підтримки браузера ви віддасте перевагу preconnect, а не dns-prefetch і з обережністю будете використовувати prefetch і prerender. Останній варто використовувати тільки в тому випадку, якщо ви абсолютно впевнені в тому, куди відправиться користувач (наприклад, піде далі воронки продажів).

HTTP/2


21. Підготовка до HTTP/2
У міру того, як Google йде до створення більш безпечного інтернету, і Chrome в кінці кінців починає звертатися з усіма HTTP-сторінками як з «небезпечними», вам доведеться вирішувати, чи залишитеся ви на HTTP/1.1 або налаштуєте HTTP/2-середовище. HTTP/2 дуже добре підтримується. Він нікуди не дінеться, і в більшості випадків краще дотримуватися цього протоколу. Вкладення суттєві, але рано чи пізно це доведеться зробити. Крім того, ви можете отримати сильний приріст продуктивності завдяки сервіс-воркерам і відправки даних з ініціативи сервера (по украй мірі, в довгостроковій перспективі).
Зворотна сторона медалі: вам доведеться мігрувати на HTTPS і в залежності від того, наскільки велика ваша користувальницька база на HTTP/1.1 (користувачі застарілих ОС або браузерів), доведеться розсилати різні білди, для чого буде потрібно створити новий процес складання. Майте на увазі: налаштування міграції та нового процесу складання може бути важкою і тривалою завданням. Далі по тексту будемо виходити з припущення, що ви або переходьте, або вже перейшли на HTTP/2.
22. Правильне розгортання HTTP/2
Ще раз: роздача ресурсів через HTTP/2 потребує глибокого перегляду звичних процесів. Вам доведеться знайти баланс між упаковкою модулів і паралельної завантаженням численних маленьких модулів.
З одного боку, ви можете захотіти уникнути об'єднання ресурсів, розбивши інтерфейс на численні дрібні модулі, стискаючи їх у ході складання, посилаючись на них в рамках scout-методики і паралельно завантажуючи. Зміна одного файлу не зажадає перезавантаження всієї таблиці стилів або JavaScript.
З іншого боку, упаковка має сенс, оскільки відправка браузеру численних маленьких JS-файлів пов'язана з певними проблемами. По-перше, погіршиться стиснення. При повторному використанні словника ми отримуємо вигоду від стиснення великого пакета, але не окремих маленьких. По-друге, браузери ще не оптимізовані для подібних робочих процесів. Наприклад, для декількох ресурсів Chrome запускає послідовне виконання межпроцессных взаємодій (IPC), так що якщо у нас буде кілька сотень ресурсів, то ми отримаємо великі витрати під час виконання в браузері.
enter image description here
Для досягнення найкращих результатів за допомогою HTTP/2 скористайтесь прогресивної завантаженням CSS
Також ви можете спробувати прогресивно вантажити CSS. Очевидно, що в такому випадку користувачі HTTP/1.1 опиняться у програші, тому частиною процесу розгортання може стати генерування і передача різних збірок різних браузерам. Це дещо ускладнить процес. Ще вам може допомогти об'єднання (coalescing) HTTP/2-з'єднань, що дозволяє використовувати шардінг домену без втрати переваг HTTP/2, але на практиці це таємничим.
Як бути? Якщо ви використовуєте HTTP/2, то розумним компромісом може стати відправка приблизно десяти пакетів (це не дуже погано для застарілих браузерів). Поекспериментуйте і підберіть найкращий для вашого сайту варіант.
23. Переконайтеся в надійності системи безпеки вашого сервера
Все браузерні реалізації HTTP/2 працюють через TLS, так що ви напевно захочете уникнути попереджень системи безпеки або дисфункції деяких елементів на сторінці. Переконайтеся в правильності налаштування заголовків безпеки, закрийте відомі уразливості і перевірте свій сертифікат.
Ви ще не мігрували на HTTPS? Ретельно вивчіть стандарт HTTPS-Only. Переконайтеся, що всі зовнішні плагіни і відстежують скрипти вантажаться через HTTPS, що атака через міжсайтовий скриптінг неможлива, і що правильно налаштовані заголовки HTTP Strict Transport Security і Content Security Policy.
24. Ваші сервери і CDN підтримують HTTP/2?
Різні сервери і CDN можуть по-різному підтримувати HTTP/2. Для перевірки скористайтеся інструментом Is TLS Fast Yet? або перевірте виконання вашими серверами і підтримку ними можливостей.
enter image description here
Is TLS Fast Yet? дозволяє дізнатися можливості ваших серверів і CDN при переході на HTTP/2
25. Використовується стиснення Brotli або Zopfli?
У минулому році Google представив Brotli, новий opensource-формат даних без втрат, який сьогодні широко підтримується в Chrome, Firefox і Opera. На практиці Brotli виходить ефективніше Gzip і Deflate. В залежності від налаштувань цей формат може стискатися повільніше, але зате ступінь стиснення виходить вище.
Однак розархівація виконується швидко. Оскільки формат розроблений Google, не дивно, що браузери приймають його лише при відвідуванні сайтів через HTTPS. До речі, для цього є технічні причини. Сьогодні Brotli не встановлена на більшості серверів, і його не так просто налаштувати без перекомпилированных NGINX або Ubuntu. Однак ви можете включити Brotli навіть у тих CDN, які його поки не підтримують (з допомогою сервіс-воркера).
В якості альтернативи можна використовувати алгоритм стиснення Zopfli, що кодує дані у формати Deflate, GZIP і ZLIB. При стисканні будь-якого ресурсу звичайним GZIP ви виграєте від застосування Deflate-кодування, поліпшеного з допомогою Zopfli, тому що файли стануть на 3-8% менше, ніж при максимальному ZLIB-стисканні. Проблема в тому, що стискання буде йти приблизно в 80 разів довше. Тому рекомендується застосовувати Zopfli для тих ресурсів, які не сильно змінюються, а також для файлів, що стискаються один раз і багаторазово викачуються.
26. Включений OCSP stapling?
Включивши на своїх серверах OCSP stapling, ви можете прискорити TLS-хендшейки. Протокол Online Certificate Status Protocol (OCSP) був створений в якості альтернативи протоколу Certificate Revocation List (CRL). Вони обидва використовуються для перевірки анулювання сертифіката SSL. Однак OCSP не вимагає від браузера завантажувати список сертифікатів і потім шукати в ньому потрібну інформацію, що економить час, що витрачається на хендшейки.
27. Ви вже впровадили IPv6?
У зв'язку з вичерпанням IPv4 і швидким впровадженням протоколу IPv6 в основних мобільних мережах (в США достигнут поріг 50-відсоткового впровадження) має сенс оновити ваш DNS до IPv6. Переконайтеся, що в рамках мережі забезпечується підтримка подвійного стека — це дозволяє одночасно використовувати IPv6 і IPv4. Майте на увазі, що IPv6 не має зворотної сумісності. Дослідження показують, що цей протокол може прискорювати роботу сайтів на 15% за рахунок «виявлення сусідів» (NDP) та оптимізації маршрутів.
28. Ви використовуєте стиснення HPACK?
Якщо ви використовуєте HTTP/2, то перевірте, щоб ваші сервери застосовували HPACK-стиснення для заголовків HTTP відгуків. Це зменшує непотрібні накладні витрати. З-за своєї новизни HTTP/2-сервери можуть підтримувати специфікації не повністю, в тому числі і HPACK. Можете перевірити це за допомогою прекрасного інструменту H2spec. Робота HPACK.
enter image description here
H2spec
29. Використовуються сервіс-воркеры для кешування і як мережевий fallback (network fallbacks)?
Ніякі оптимізації продуктивності в рамках мережі не можуть зрівнятися з кешем, що зберігаються на комп'ютері. Якщо ваш сайт працює через HTTPS, то вивчіть керівництво Pragmatist's Guide to Service Workers, щоб кешувати статичні ресурси в кеші сервіс-воркера, а також зберігати резервний оффлайн-контент (або навіть сторінки цілком) з подальшим витяганням з користувацької машини замість передачі по мережі. Почитайте Offline Cookbook і вивчіть безкоштовний курс на Udacity Offline Web Applications. В браузерах з'являється підтримка, а мережа в будь-якому випадку виступає в якості резервного рішення.

Тестування і моніторинг


30. Відстежуйте попередження про змішаному контенті (mixed-content warnings)
Якщо ви нещодавно мігрували з HTTP, HTTPS, від обов'язково відстежуйте активні і пасивні попередження про змішаному контенті. Це можна робити за допомогою report-uri.io. Також можна сканувати HTTPS-сайт на наявність змішаного вмісту за допомогою Mixed Content Scan.
31. Оптимізований ваш процес розробки?
Виберіть інструмент для налагодження та клікніть по кожній кнопці. Переконайтеся, що ви знаєте, як аналізувати продуктивність відтворення і виводяться в консоль дані, як налагоджувати JavaScript і редагувати CSS-стилі. У цьому виступі розглядаються десятки неясностей і ризиків у ході налагодження і тестування за допомогою інструментів розробника.
32. Ви провели тестування в застарілих і проксі-браузерах?
Недостатньо просто протестувати Chrome і Firefox. Перевірте, як ваш сайт працює застарілих і проксі-браузерах. Приміром, UC Browser і Opera Mini займають пристойну частку ринку в Азії (до 35%). Виміряйте середню швидкість інтернету у ваших цільових країнах, щоб уникнути неприємних сюрпризів. Протестуйте в умовах регулювання смуги пропускання, емулюйте пристрою з високим значенням DPI. BrowserStack — фантастична річ, але обов'язково проводите тести і на реальних пристроях.
33. Налаштований у вас безперервний моніторинг?
Наявність власного примірника WebPagetest корисно для швидкого тестування без обмежень. Налаштуйте безперервний моніторинг бюджету продуктивності з автоматичною розсилкою попереджень. Також налаштуйте власні тимчасові мітки (user timing marks) для вимірювання та моніторингу специфічних бізнес-метрик. Відстежувати зміну продуктивності можна за допомогою SpeedCurve та/ або New Relic. Це допоможе зрозуміти обмеження WebPagetest. Також зверніть увагу на SpeedTracker, Lighthouse і Calibre.
Швидкі результати
У нас вийшов досить об'ємний список, і оптимізація займе якийсь час. А якщо у вас є всього один годину, щоб значно поліпшити продуктивність? Давайте зведемо наш список до десяти самим быстрорешаемым завдань. Звичайно, перед початком оптимізації та після її закінчення необхідно буде провести вимірювання, включаючи час початку малювання і значення Speed Index при 3G — і кабельному з'єднанні.
  1. Ваша мета — почати малювання менш ніж через одну секунду для кабельного і менш ніж через три секунди – для 3G-з'єднання. Значення SpeedI ndex — менше 1000. Оптимізуйте час початку малювання і час до початку взаємодії.
  2. Підготуйте критичний CSS для ваших шаблонів і увімкніть його в
    <head>
    (ваш бюджет — 14 Кб).
  3. Відкладайте і ліниво завантажуйте як можна більше скриптів (як власних, так і сторонніх), особливо кнопки соціальних мереж, відеоплеєри і дорогий JavaScript.
  4. Скористайтесь хинтами для ресурсів задля прискорення доставки з допомогою
    dns lookup
    ,
    preconnect
    ,
    prefetch
    ,
    preload
    та
    prerender
    .
  5. Використовуйте зменшені набори символів у веб-шрифтів і завантажуйте їх асинхронно (або взагалі перейдіть на системні шрифти).
  6. Оптимізувати зображення і постарайтеся використовувати WebP на найважливіших сторінках (наприклад, лэндинговых).
  7. Перевірте правильність налаштування заголовків HTTP-кеша і заголовків безпеки.
  8. Увімкніть на сервері стиснення Brotli або Zopfli. Якщо це неможливо, то не забудьте включити GZIP-стиснення.
  9. Якщо доступний HTTP/2, то включіть HPACK-стиснення і почніть відстежувати попередження про змішаному контенті. Якщо ви працюєте через TLS, то включіть OCSP stapling.
  10. У міру можливості кэшируйте такі ресурси, як шрифти, стилі, JavaScript і зображення (чим більше, тим краще!) у кеші сервіс-воркера.
Скачайте чек-лист (PDF, Apple Pages)
Тримаючи в голові цей чекліст, ви будете готові до роботи над будь-якими проектами щодо поліпшення продуктивності фронтенда.
Якщо вам потрібні альтернативні рішення, зверніться до чек-листів Дена Раблика і Джона Яблонскі.
Поїхали!
Деякі оптимізації можуть не входити в вашу зону відповідальності або бюджет або можуть бути просто зайвими, якщо вам доводиться працювати з legacy-кодом. Нічого страшного! Цей чек-лист можна взяти за основу для створення свого власного списку, що враховує особливості вашої роботи. Але найважливіше — тестуйте і вимірюйте метрики своїх проектів, щоб виявляти проблеми до виконання оптимізацій.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.