Кейс Guardian: свіжі новини за 1 секунду



Guardian – одна з найбільших газет у Великобританії, а сайт видання є одним з найбільш популярних онлайн-ЗМІ в цій країні. Трафік на сайт перевищує 100 мільйонів відвідувачів в місяць. Видання отримує значні доходи від реклами, яка показується відвідувачам сайту. Мати максимально комфортний сайт для відвідування – одна з ключових завдань команди Guardian.

Патрік Хаманн, старший розробник Guardian, розповідає, як його команді вдалося прискорити сайт Guardian.

Постановка завдання
Команда почала з опитування користувачів щодо того, що для них важливо. Для опитування були визначені 17 ключових потенційних показників сайту. Було опитано 3000 користувачів сайту. Швидкість завантаження сайту виявилася №2 по важливості, «програвши» тільки такому фактору як «легко знайти потрібний контент».

Ці дані підтверджують інші дослідження, наприклад, опубліковане на Web Performance Today дослідження про те, що очікування користувачів щодо швидкості завантаження сайтів постійно зростають – користувачі чекають все більш і більш швидкого завантаження сайту.



В той же час відома наступна шкала сприйняття затримки між дією і результатом при виконанні завдань:
  • 0-100 мс: затримка не сприймається.
  • 100-300 мс: затримка помітна користувачеві.
  • 300-1000 мс: сприймається як затримка, яка не суперечить нормальному функціонуванню.
10 000 мс: користувач залишає спроби виконати завдання.

(цитується за книгою Іллі Григорика «Високопродуктивна робота браузера в мережі»)

Тому команда Хаманна поставила собі мету – відображати вміст статті з сайту за 1 секунду (1000 мс). Для цієї мети вони взяли методику призначення «бюджету» в мілісекундах різних завдань, які виконуються, щоб браузер міг показати основний вміст статті.

У підсумку команда встановила 4 ключових правила для роботи над проектом:
  • Основний контент статті повинен з'являтися на екрані першим.
  • Основний контент повинен з'явитися на екрані за 1000 мс або менше (інші елементи сторінок можуть з'явитися на екрані пізніше).
  • «Навіть відмова має виглядати добре»: якщо деяка функціональність відмовляє, це не повинно заважати іншим компонентам сторінки і її відображення, а користувач повинен отримати основний контент.


Очевидно, що користувачі приходять на сайт Guardian, щоб читати статті. Вони не приходять туди, ставлячи собі за мету поділитися статтею в соцмережах або подивитися рекламні банери. Тому першим на екрані зобов'язана з'явитися вміст статті – те, заради чого користувач прийшов на сайт.

Різні віджети, сайдбары і рекламні банери чекатимуть своєї черги.



Архітектурне вирішення
Зазвичай, коли користувач запитує сторінку з певною статтею, відбувається звертання до бази даних за самою статтею, потім ще одне звернення до бази даних для віджету «статті по цій темі», потім ще одне звернення до бази даних для секції коментарів до статті.

Хаманн звертає увагу, що в звичайному блозі на типової платформі WordPress можуть відбуватися до 8-ми звернень до бази даних, щоб показати користувачеві сторінку зі статтею.

Кожне таке звернення «з'їдає» частину бюджету часу. Це особливо помітно, коли бюджет часу — всього 1 секунда.

Нижче показана типова архітектура сторінку старої версії сайту. Перед тим, як показати сторінку користувачеві, робилося 3 звернення до бази даних. Більш того, ці обігу перебували на критичному шляху – тобто якщо звернення до бази, щоб отримати коментарі з якихось причин не спрацьовувало, то ця помилка не давала показати всю сторінку користувачеві.



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

Тому архітектура сторінки була змінена, як показано на малюнку нижче.



Після цього сторінка стала завантажуватися поступово. Нижче показано, як сторінка виглядає на самому початку, як тільки її починає бачити користувач, і як вона виглядає, коли завантаження сторінки цілком закінчена.



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

Завантаження за 1 секунду
Щоб виконати цю вимогу про появу основного вмісту за 1 секунду команді довелося докладно розібратися з тим, як працює браузер користувача. Починаючи від того моменту, як користувач клікнув по посиланню і до того моменту, як контент з'являється на екрані.

Guardian звертає увагу і на мобільних користувачів, частка яких постійно зростає. У них ситуація із завантаженням сторінок гірше, ніж у користувачів, підключених до швидкого інтернету в будинку і офісі. Послідовність роботи браузера до відображення сторінки виглядає так (слайд з Google Page Insights):



При середньому 3G-з'єднання 600 мс вже зайняті тією частиною, яка пов'язана з мережевою частиною, і тут в принципі розробник сайту зробити нічого не може: це звернення до DNS, TCP-з'єднання і GET-запит, щоб отримати сторінку та отримання цієї сторінки. І 600 мс – це мінімум. На деяких 3G-мережах взагалі не вдасться вкластися у вимога показу основного вмісту за 1 секунду.

У розробника залишається тільки 400 мс, на які він може вплинути, наприклад, оптимізуючи сервер чи правильно структуруючи сторінку.

Важливий момент полягає в тому, що браузер не може отрендерить сторінку, поки він не отримав CSS.



Оскільки команда працює з встановленим вимогам вкластися в 1 секунду для показу основного вмісту самий критичний набір CSS-стилів – це стилі, пов'язані з показом тіла статті.



Однак якщо дотримуватися традиційної логіки поділу, яка вважається найкращою практикою – коли стилі лежать в окремому CSS-файлі, поведінка описано в JS-файлі, то такий підхід буде накопичувати додаткові запити і ніколи не дозволить укластися в бюджет 1-ї секунди, тому що кожен запит вимагає 600 мс тільки мережний частини, пов'язаної з встановленням з'єднання.

Тому команда стала включати критично важливі стилі, пов'язані з відображенням основного вмісту в html-файли сторінок.



В кінці документа інші стилі завантажуються асинхронно.

Цей метод йде проти кращих практик, але його результат в плані прискорення завантаження вражає, команда заощадила близько 500 мс за рахунок того, що включила базовий CSS в html-документ.



Крім того, команда стала використовувати зберігання стилів на машині користувача для прискорення завантаження наступних сторінок.

Підхід до шрифтів
Іншу проблему представляв фірмовий шрифт Guardian. Багато веб-дизайнери сперечатимуться про те, важливо використовувати конкретний шрифт на сторінці чи можна зупинитися на якомусь сімейство шрифтів, з зарубками або без.

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

Тому команда Хаманна застосувала наступний алгоритм роботи зі шрифтом: якщо браузер користувача сучасний, і підтримує WOFF, то фірмовий шрифт асинхронно скачується в локальний кеш на диску користувача і показується далі звідти. Сам шрифт кодується base-64 в json-файлі.



Такий підхід забезпечує всього один http-запит.



Результат
У підсумку після всіх зазначених модифікацій мета – показувати основний контент за 1 секунду була виконана, а повний час завантаження сайту скоротилася з 12,1 до 3,2 ц.

На закінчення повторимо основні рекомендації Патріка Хаманна:
  • Виділити бюджет часу на відкриття сторінки і розглядати різні дії браузера з цієї позиції.
  • Визначити найбільш критичний контент для користувача.
  • Показувати цей контент найбільш швидко, подгружая інше пізніше.
  • Переконатися, що навіть при наявності помилок функціональності сайту або віджетів критичний для користувача контент однаково коректно відображається.
Джерело: Хабрахабр

0 коментарів

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