Продуктивність браузерів при завантаженні сторінки

1. Мережеві з'єднання
2. паралельні завантаження
3. кешування
4. Пред-виклик (prefetching)
5. вбудовані зображення
6. висновок
7. Читати далі

Примітка: нижче розташований переклад замітки "Browser Page Load Performance" від John Resig, в якій він розглядає тестове оточення від Steve Souders для аналізу клієнтської продуктивності браузерів. Мої коментарі далі курсивом.

Steve Souders багато вніс в поліпшення продуктивності браузерів при завантаженні сторінки і клієнтської оптимізації більш, ніж будь-хто. Під час своєї роботи в Yahoo! він відповідав за YSlow (Чудовий інструмент для вимірювання продуктивності вашого сайту) і написав книгу, присвяченій поліпшенню продуктивності веб-сторінок - High Performance Web Sites . Зараз він працює в Google, але як і раніше займається тим же самим: робить завантаження веб-сторінок трішки швидше.

Я був захоплений виходом одного з його нових проектів - UA Profiler (Проект стартував досить давно, але хороших оглядів його роботи поки не було). Цей інструмент можна запустити в вашому браузері, щоб з'ясувати його поточні можливості щодо клієнтської продуктивності, які так чи інакше обмежують в ньому швидкість завантаження сторінок .

Давайте поглянемо на наступну таблицю:

на ній добре видно, що лідирує Firefox 3.1, маючи 9 з 11 потенційних можливостей для прискорення завантаження сторінки. У Firefox 3, Chrome і Safari 4 є всього 8 з цього списку. Firefox 2, Safari 3.1 і IE 8 є наступними за списком з 7 виконаними тестами. Ці цифри можуть допомогти оцінити загальну продуктивність браузерів при завантаженні сторінки. Природно, що всі ці тести не зачіпають особливостей рендеринга сторінки або JavaScript-продуктивність: їх козирною картою є продуктивність мережевого з'єднання ( CSS-продуктивність була детально розглянута раніше у відповідному циклі статей, який привів до деяким практичним аспектам її застосування).

Інформація про якість використання мережевого з'єднання важлива з двох причин:

1. Вона дозволяє виробникам браузерів дізнатися якість їхнього продукту в цьому аспекті. Якщо виробники покращать будь-які із заявлених показників, це виллється в більш швидке завантаження сторінок в їх браузері.
2. Вона дозволяє веб-розробникам вірно виставити пріоритети і позначити ті проблеми, з якими вони зіткнуться при створенні сайтів. Наприклад, якщо вони підтримують браузер, який не підтримує (каламбур просто виходить) паралельну завантаження файлів стилів, то, можливо, їх сайт потрібно видозмінити для поліпшення продуктивності.

Тести можуть бути розбиті на декілька категорій (Steve детально пояснює таку класифікацію в FAQ):

Мережеві з'єднання

В основному, тестуються дві речі: число одночасних з'єднань до одного хосту (піддомени розцінюються як окремі хости) і скільки з'єднань можна відкрити до всіх хостам одночасно. Ці числа є хорошим індикатором, яке можливе число паралельних з'єднань (це зазвичай впливає на число одночасно завантажуваних картинок).

Додатково перевіряється, чи підтримує браузер gzip-стиснення. Результати не надто вражають: всі сучасні браузери на даний момент підтримують стиснення.

паралельні завантаження

Всі браузери здатні завантажувати зображення в паралельному режимі (кілька зображення завантажуються одночасно) але що щодо інших ресурсів (таких як стилі і скрипти)?

На жаль, домогтися паралельної завантаження файлів скриптом і стилів набагато складніше, тому вони можуть дуже сильно змінити зміст (і зовнішній вигляд) решти сторінки. Поява цих компонентів на сторінці відбувається в кілька в етапів:

1. Завантаження (може бути паралельною)
2. аналіз
3. виконання

Тому завантаження цих файлів блокує один одного (нагадуючи гру в «камінь-ножиці-папір»): скрипти блокують аналіз і виконання інших скриптів, стилі блокують аналіз і виконання скриптів.

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

Зміни в цій області дозволять значно поліпшити клієнтську продуктивність. Можна сміливо сказати, що це як і раніше сама незаймана область для оптимізації (і саме вона найбільше турбує зараз фронт-енд архітекторів).

кешування

Хоча всі сучасні браузери підтримують кешування ресурсних файлів, кешування редиректів поширене набагато менше. Наприклад, уявіть такий випадок: користувач набирає в браузері http://google.com/ - і Google перенаправляє його на сторінку http://www.google.com/, але тільки пара браузерів здатне закешовану цей редирект, щоб не робити додаткового запиту в майбутньому.

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

Пред-виклик (prefetching)

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

хоча існує ціла сторінок , Присвячена використанню даного підходу на сайті розробників Mozilla , Але його застосування набагато простіше, ніж може спершу здатися. Це так само просто, як додавання нової посилання наверх вашого сайту:

<Link rel = "prefetch" href = "/ images / big.jpeg">

І всі необхідні ресурси будуть попередньо завантажені (без використання JavaScript)!

вбудовані зображення

У фіналі перевірки всіх можливостей браузерів йде тестування на підтримку вбудованих картинок, вставлених за допомогою data: URL . Data: URL дозволяє розробникам включати бінарні дані прямо в саму сторінку. Хоча це і економить число HTTP-запитів, але потрібно мати на увазі, що ресурси, включені таким чином, не кешуються (точніше, кешуються разом з вихідним документом або таблицею стилів). Використання цієї техніки може варіюватися від випадку до випадку (на мою думку, все невеликі фонові зображення на сторінці повинні бути виведені саме в такому форматі, що значно прискорить «візуальну» завантаження документа), але її підтримка повинна бути простою обов'язкової (докладніше про альтернативну технології mhtml і поточних методах забезпечення кросбраузерності для data: URL ).

висновок

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

Як було відмічено далі в коментарях, Steve є автором ще Cuzilion - моделювання завантаження сторінки при використанні різної кількості різних файлів - і доповнення до Firefox Hammerhead - дозволяє заміряти і запам'ятовувати час завантаження для обраних сайтів.

Читати далі

Всі коментарі (habrahabr.ru)