Агрегація даних Performance API Resource Timing: Аналітика продуктивності завантаження фронтенду

У прагненні забезпечити винятковий користувацький досвід, оптимізація продуктивності фронтенду має першорядне значення. Критичним аспектом цієї оптимізації є розуміння того, як ресурси завантажуються на вашому веб-сайті чи в застосунку. Resource Timing API, частина ширшого набору Performance API, надає детальну інформацію про час завантаження кожного ресурсу, що отримується браузером. Ця інформація є безцінною для виявлення вузьких місць та покращення загальної продуктивності завантаження. Цей вичерпний посібник розглядає, як використовувати Resource Timing API, агрегувати його дані та застосовувати їх для аналітики продуктивності завантаження.

Розуміння Resource Timing API

Resource Timing API надає детальну інформацію про час завантаження ресурсів веб-сторінкою, таких як зображення, скрипти, таблиці стилів та інші активи. Це включає такі метрики:

• Тип ініціатора (Initiator Type): Тип елемента, який ініціював запит (наприклад, 'img', 'script', 'link').
• Ім'я (Name): URL-адреса ресурсу.
• Час початку (Start Time): Часова мітка, коли браузер починає отримувати ресурс.
• Початок вибірки (Fetch Start): Часова мітка безпосередньо перед тим, як браузер починає отримувати ресурс з кешу диска або мережі.
• Початок/кінець пошуку домену (Domain Lookup Start/End): Часові мітки, що вказують, коли починається і закінчується процес пошуку DNS.
• Початок/кінець з'єднання (Connect Start/End): Часові мітки, що вказують, коли починається і закінчується TCP-з'єднання з сервером.
• Початок/кінець запиту (Request Start/End): Часові мітки, що вказують, коли починається і закінчується HTTP-запит.
• Початок/кінець відповіді (Response Start/End): Часові мітки, що вказують, коли починається і закінчується HTTP-відповідь.
• Розмір передачі (Transfer Size): Розмір переданого ресурсу в байтах.
• Розмір закодованого тіла (Encoded Body Size): Розмір закодованого (наприклад, стиснутого GZIP) тіла ресурсу.
• Розмір декодованого тіла (Decoded Body Size): Розмір декодованого тіла ресурсу.
• Тривалість (Duration): Загальний час, витрачений на отримання ресурсу (responseEnd - startTime).

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

Доступ до даних Resource Timing

Доступ до Resource Timing API здійснюється через об'єкт performance в JavaScript:

            const resourceTimingEntries = performance.getEntriesByType("resource");

resourceTimingEntries.forEach(entry => {
  console.log(entry.name, entry.duration);
});

            

              
                Copy
              
            
          

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

Агрегація даних Resource Timing

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

За типом ресурсу

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

            const resourceTypes = {};

resourceTimingEntries.forEach(entry => {
  const initiatorType = entry.initiatorType;
  if (!resourceTypes[initiatorType]) {
    resourceTypes[initiatorType] = {
      count: 0,
      totalDuration: 0,
      averageDuration: 0
    };
  }
  resourceTypes[initiatorType].count++;
  resourceTypes[initiatorType].totalDuration += entry.duration;
});

for (const type in resourceTypes) {
  resourceTypes[type].averageDuration = resourceTypes[type].totalDuration / resourceTypes[type].count;
  console.log(type, resourceTypes[type].averageDuration);
}

            

              
                Copy
              
            
          

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

За доменом

Групування ресурсів за доменом дозволяє оцінити продуктивність різних мереж доставки контенту (CDN) або сторонніх сервісів. Це може допомогти вам визначити домени з низькою продуктивністю та розглянути альтернативних провайдерів.

            const resourceDomains = {};

resourceTimingEntries.forEach(entry => {
  const domain = new URL(entry.name).hostname;
  if (!resourceDomains[domain]) {
    resourceDomains[domain] = {
      count: 0,
      totalDuration: 0,
      averageDuration: 0
    };
  }
  resourceDomains[domain].count++;
  resourceDomains[domain].totalDuration += entry.duration;
});

for (const domain in resourceDomains) {
  resourceDomains[domain].averageDuration = resourceDomains[domain].totalDuration / resourceDomains[domain].count;
  console.log(domain, resourceDomains[domain].averageDuration);
}

            

              
                Copy
              
            
          

Цей код обчислює середній час завантаження для кожного домену та виводить його в консоль. Якщо ви помітили, що певний CDN постійно працює повільно, ви можете дослідити його продуктивність або перейти до іншого провайдера. Наприклад, розглянемо сценарій, де ви використовуєте і Cloudflare, і Akamai. Ця агрегація дозволить вам безпосередньо порівняти їхню продуктивність у вашому конкретному контексті.

За сторінкою

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

Це часто вимагає інтеграції з системою маршрутизації вашого застосунку. Вам потрібно буде пов'язати кожен запис про час завантаження ресурсу з поточною URL-адресою сторінки або маршрутом. Реалізація буде залежати від фреймворку, який ви використовуєте (наприклад, React, Angular, Vue.js).

Створення власних метрик

Окрім стандартних метрик, що надаються Resource Timing API, ви можете створювати власні метрики для відстеження конкретних аспектів продуктивності вашого застосунку. Наприклад, ви можете захотіти виміряти час, необхідний для завантаження певного компонента або рендерингу конкретного елемента.

Це можна досягти за допомогою методів performance.mark() та performance.measure():

            performance.mark('component-start');

// Load the component

performance.mark('component-end');

performance.measure('component-load', 'component-start', 'component-end');

const componentLoadTime = performance.getEntriesByName('component-load')[0].duration;

console.log('Component load time:', componentLoadTime);

            

              
                Copy
              
            
          

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

Аналіз даних Resource Timing для покращення продуктивності

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

Тривалий час пошуку DNS

• Причина: Повільний DNS-сервер, віддалений DNS-сервер, рідкісні DNS-запити.
• Рішення: Перейти до швидшого DNS-провайдера (наприклад, Cloudflare, Google Public DNS), використовувати CDN для кешування DNS-записів ближче до користувачів, реалізувати попереднє завантаження DNS (DNS prefetching).
• Приклад: Веб-сайт, орієнтований на користувачів по всьому світу, мав повільний час завантаження в певних регіонах. Аналіз даних Resource Timing виявив тривалий час пошуку DNS у цих регіонах. Перехід на CDN з глобальними DNS-серверами значно скоротив час пошуку DNS та покращив загальну продуктивність.

Повільний час з'єднання

• Причина: Перевантаження мережі, проблеми на стороні сервера, втручання брандмауера.
• Рішення: Оптимізувати інфраструктуру сервера, використовувати CDN для розповсюдження контенту ближче до користувачів, налаштувати брандмауери для ефективної комунікації.
• Приклад: Веб-сайт електронної комерції мав повільний час з'єднання в години пікових покупок. Аналіз даних Resource Timing вказав на перевантаження сервера як на основну причину. Оновлення серверного обладнання та оптимізація запитів до бази даних покращили час з'єднання та запобігли погіршенню продуктивності під час пікового трафіку.

Великі розміри передачі

• Причина: Неоптимізовані зображення, немініфікований код, непотрібні активи.
• Рішення: Оптимізувати зображення (наприклад, стискати, змінювати розмір, використовувати сучасні формати, як-от WebP), мініфікувати JavaScript та CSS код, видаляти невикористовуваний код та активи, вмикати GZIP або Brotli стиснення.
• Приклад: Новинний веб-сайт використовував великі, неоптимізовані зображення, що значно збільшувало час завантаження сторінки. Оптимізація зображень за допомогою інструментів, таких як ImageOptim, та впровадження відкладеного завантаження (lazy loading) зменшили розміри передачі зображень та покращили продуктивність завантаження сторінки.
• Аспект інтернаціоналізації: Переконайтеся, що оптимізація зображень враховує різні розміри екранів та роздільні здатності, поширені в різних регіонах.

Повільний час відповіді сервера

• Причина: Неефективний код на стороні сервера, вузькі місця в базі даних, затримка в мережі.
• Рішення: Оптимізувати код на стороні сервера, покращити продуктивність бази даних, використовувати CDN для кешування контенту ближче до користувачів, впровадити HTTP-кешування.
• Приклад: Платформа соціальних мереж мала повільний час відповіді сервера через неефективні запити до бази даних. Оптимізація запитів до бази даних та впровадження механізмів кешування значно скоротили час відповіді сервера та покращили загальну продуктивність.

Ресурси, що блокують рендеринг

• Причина: Синхронний JavaScript та CSS, що блокують рендеринг сторінки.
• Рішення: Відкласти завантаження некритичного JavaScript, вбудувати критичний CSS, використовувати асинхронне завантаження для скриптів, усунути невикористовуваний CSS.
• Приклад: Веб-сайт блогу використовував великий CSS-файл, що блокував рендеринг і затримував початкове відображення сторінки. Вбудовування критичного CSS та відкладене завантаження некритичного CSS покращили сприйняття продуктивності веб-сайту.

Інтеграція даних Resource Timing в інструменти моніторингу продуктивності

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

Популярні інструменти моніторингу продуктивності, що підтримують дані Resource Timing, включають:

• Google PageSpeed Insights: Надає рекомендації щодо покращення швидкості сторінки на основі різних метрик продуктивності, включаючи дані Resource Timing.
• WebPageTest: Дозволяє тестувати продуктивність вашого веб-сайту з різних місць та браузерів, надаючи детальну інформацію про час завантаження ресурсів.
• New Relic: Пропонує комплексні можливості моніторингу продуктивності, включаючи дані Resource Timing в реальному часі та візуалізації.
• Datadog: Надає детальні метрики Resource Timing поряд із ширшим моніторингом інфраструктури та застосунків, пропонуючи цілісне уявлення про продуктивність.
• Sentry: В основному зосереджений на відстеженні помилок, Sentry також надає функції моніторингу продуктивності, включаючи дані Resource Timing для кореляції проблем продуктивності з конкретними помилками.
• Lighthouse: Автоматизований інструмент з відкритим кодом для покращення якості веб-сторінок. Він має аудити для продуктивності, доступності, прогресивних веб-додатків, SEO та іншого. Може бути запущений з Chrome DevTools, з командного рядка або як модуль Node.

Інтегруючи дані Resource Timing у ці інструменти, ви можете отримати глибше розуміння продуктивності вашого веб-сайту та ефективніше визначати області для покращення.

Етичні міркування та конфіденційність користувачів

При зборі та аналізі даних Resource Timing важливо враховувати етичні наслідки та конфіденційність користувачів. Будьте прозорими з користувачами щодо даних, які ви збираєте, та як вони використовуються. Переконайтеся, що ви дотримуєтесь відповідних правил конфіденційності, таких як GDPR та CCPA.

Уникайте збору особистої ідентифікаційної інформації (PII) та анонімізуйте або псевдонімізуйте дані, де це можливо. Впроваджуйте відповідні заходи безпеки для захисту даних від несанкціонованого доступу або розголошення. Розгляньте можливість надання користувачам опції відмови від моніторингу продуктивності.

Просунуті техніки та майбутні тенденції

Resource Timing API постійно розвивається, і з'являються нові функції та техніки для подальшого вдосконалення аналітики продуктивності фронтенду. Ось деякі просунуті техніки та майбутні тенденції, на які варто звернути увагу:

Server Timing API

Server Timing API дозволяє серверам надавати інформацію про час їх обробки запиту. Цю інформацію можна поєднувати з даними Resource Timing для отримання більш повної картини наскрізної продуктивності.

Long Tasks API

Long Tasks API визначає завдання, які блокують основний потік на тривалий час, викликаючи ривки інтерфейсу (UI jank) та проблеми з відгуком. Цю інформацію можна використовувати для оптимізації JavaScript-коду та покращення користувацького досвіду.

WebAssembly (Wasm)

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

HTTP/3

HTTP/3 - це остання версія протоколу HTTP, яка використовує транспортний протокол QUIC для забезпечення покращеної продуктивності та надійності. HTTP/3 пропонує кілька переваг над HTTP/2, включаючи зменшену затримку та покращене управління з'єднаннями.

Висновок

Resource Timing API - це потужний інструмент для розуміння та оптимізації продуктивності фронтенду. Агрегуючи та аналізуючи дані про час завантаження ресурсів, ви можете виявляти вузькі місця, покращувати час завантаження та забезпечувати кращий користувацький досвід. Незалежно від того, чи є ви досвідченим фронтенд-розробником, чи тільки починаєте, оволодіння Resource Timing API є важливим для створення високопродуктивних веб-застосунків. Використовуйте силу оптимізації на основі даних і розкрийте повний потенціал вашого веб-сайту чи застосунку. Не забувайте надавати пріоритет конфіденційності користувачів та етичним міркуванням при зборі та аналізі даних про продуктивність. Залишаючись в курсі останніх тенденцій та технік, ви можете забезпечити, щоб ваш веб-сайт залишався швидким, відгукливим та зручним для користувачів на довгі роки. Використання цих технік та інструментів сприятиме створенню більш продуктивного та глобально доступного вебу.

Дієвий інсайт: Почніть з реалізації базової агрегації часу завантаження ресурсів за типом ресурсу та доменом. Це надасть негайне розуміння того, де знаходяться ваші вузькі місця продуктивності. Потім інтегруйтеся з інструментом моніторингу продуктивності, таким як Google PageSpeed Insights або WebPageTest, щоб автоматизувати збір та аналіз даних.