Frontend Device Memory API: Створення веб-досвіду з урахуванням пам'яті

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

Як нам подолати цей розрив? Як ми можемо надавати багатий досвід тим, хто може його підтримати, водночас забезпечуючи швидкий, функціональний та надійний досвід для тих, хто має менш потужне обладнання? Відповідь полягає у створенні адаптивних застосунків. Замість універсального підходу ми повинні адаптувати користувацький досвід до можливостей пристрою користувача. Одним з найважливіших, але часто ігнорованих, обмежень пристрою є пам'ять (ОЗП). Саме тут на допомогу приходить Device Memory API, пропонуючи простий, але потужний механізм для фронтенд-розробників, щоб зробити їхні застосунки чутливими до обсягу пам'яті.

Що таке Device Memory API?

Device Memory API — це веб-стандарт, який надає інформацію про обсяг оперативної пам'яті, доступної на пристрої користувача. Це надзвичайно простий API, доступний через єдину властивість лише для читання в об'єкті `navigator`:

`navigator.deviceMemory`

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

`console.log(navigator.deviceMemory);` // Можливий результат: 8

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

Ви можете помітити, що API не повертає точне число, наприклад, 7.89 ГБ. Натомість він повертає округлене значення, а саме — ступінь двійки. Специфікація пропонує такі значення: 0.25, 0.5, 1, 2, 4, 8 і так далі. Це навмисний вибір дизайну задля конфіденційності.

Якби API надавав точний обсяг ОЗП, це могло б стати ще одним джерелом даних для «фінгерпринтингу» браузера — практики поєднання багатьох дрібних фрагментів інформації для створення унікального ідентифікатора користувача, який можна використовувати для відстеження. Групуючи значення, API надає достатньо інформації, щоб бути корисним для оптимізації продуктивності, не збільшуючи значно ризик для конфіденційності користувачів. Це класичний компроміс: надання корисної підказки без розкриття надто специфічних деталей обладнання.

Підтримка браузерами

На момент написання цієї статті Device Memory API підтримується в браузерах на базі Chromium, включаючи Google Chrome, Microsoft Edge та Opera. Це цінний інструмент для охоплення значної частини глобальної веб-аудиторії. Завжди краще перевіряти ресурси на кшталт «Can I Use» для отримання найсвіжішої інформації про підтримку та розглядати наявність API як прогресивне поліпшення. Якщо `navigator.deviceMemory` є undefined, ви повинні плавно перейти до стандартного досвіду.

Чому пам'ять пристрою змінює правила гри для продуктивності фронтенду

Десятиліттями дискусії про продуктивність фронтенду зосереджувалися на швидкості мережі та обробці на ЦП. Ми стискаємо активи, мінімізуємо код та оптимізуємо шляхи рендерингу. Хоча все це надзвичайно важливо, пам'ять стала тихим «вузьким місцем», особливо на мобільних пристроях, які зараз домінують у веб-трафіку в усьому світі.

Проблема пам'яті на сучасних веб-сайтах

Сучасні веб-застосунки споживають багато пам'яті. Вони включають:

• Великі JavaScript-пакети: Фреймворки, бібліотеки та код застосунку потрібно розбирати, компілювати та тримати в пам'яті.
• Зображення та відео високої роздільної здатності: Ці активи споживають значний обсяг пам'яті, особливо під час декодування та рендерингу.
• Складні структури DOM: Тисячі вузлів DOM в односторінковому застосунку (SPA) створюють великий відбиток у пам'яті.
• CSS-анімації та WebGL: Багаті візуальні ефекти можуть бути дуже вимогливими як до графічного процесора, так і до системної ОЗП.

На пристрої з 8 ГБ або 16 ГБ ОЗП це рідко є проблемою. Але на бюджетному смартфоні з 1 ГБ або 2 ГБ ОЗП — що є поширеним у багатьох частинах світу — це може призвести до серйозного погіршення продуктивності. Браузеру може бути важко утримувати все в пам'яті, що призводить до смиканих анімацій, повільного часу відгуку та навіть збоїв вкладок. Це безпосередньо впливає на ключові показники продуктивності, такі як Core Web Vitals, зокрема Interaction to Next Paint (INP), оскільки головний потік занадто зайнятий, щоб реагувати на дії користувача.

Подолання глобального цифрового розриву

Врахування пам'яті пристрою — це акт емпатії до вашої глобальної бази користувачів. Для мільйонів користувачів недорогий пристрій на Android є їхнім основним, а можливо, і єдиним шлюзом в інтернет. Якщо ваш сайт призводить до збою їхнього браузера, ви не просто втратили сесію; ви могли втратити користувача назавжди. Створюючи застосунки, що враховують пам'ять, ви гарантуєте, що ваш сервіс є доступним і корисним для всіх, а не лише для тих, хто має висококласне обладнання. Це не просто добра етика; це хороший бізнес, що відкриває ваш застосунок для ширшого потенційного ринку.

Практичні приклади використання та стратегії впровадження

Знати обсяг пам'яті пристрою — це одне; діяти на основі цих знань — інше. Ось кілька практичних стратегій, щоб зробити ваші застосунки чутливими до пам'яті. Для кожного прикладу ми будемо використовувати просту класифікацію:

`const memory = navigator.deviceMemory;`
`const isLowMemory = memory && memory < 2;` // Давайте визначимо «низький рівень пам'яті» як менше 2 ГБ для цих прикладів.

1. Адаптивне завантаження зображень

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

Рішення: Використовуйте Device Memory API для надання зображень відповідного розміру. Хоча елемент `` чудово підходить для арт-дирекшену та перемикання роздільної здатності на основі розміру viewport, пам'ять дає нам ще один вимір для розгляду.

Реалізація:

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

function getHeroImageUrl() {
  const base_path = '/images/hero';
  const isLowMemory = navigator.deviceMemory && navigator.deviceMemory < 2;

  if (isLowMemory) {
    return `${base_path}-low-res.jpg`; // Менший, більш стиснутий JPEG
  } else {
    return `${base_path}-high-res.webp`; // Більший, високоякісний WebP
  }
}

document.getElementById('hero-image').src = getHeroImageUrl();

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

2. Умовне завантаження важких JavaScript-бібліотек

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

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

Реалізація з динамічним `import()`:

async function initializeProductViewer() {
  const viewerElement = document.getElementById('product-viewer');
  if (!viewerElement) return;

  const hasEnoughMemory = navigator.deviceMemory && navigator.deviceMemory >= 4;

  if (hasEnoughMemory) {
    try {
      const { ProductViewer } = await import('./libs/heavy-3d-viewer.js');
      const viewer = new ProductViewer(viewerElement);
      viewer.render();
    } catch (error) {
      console.error('Не вдалося завантажити 3D-переглядач:', error);
      // Показати запасне статичне зображення
      viewerElement.innerHTML = '<img src="/images/product-fallback.jpg" alt="Зображення продукту">';
    }
  } else {
    // На пристроях з малим обсягом пам'яті просто показати статичне зображення з самого початку.
    console.log('Виявлено малий обсяг пам\'яті. Пропускаємо 3D-переглядач.');
    viewerElement.innerHTML = '<img src="/images/product-fallback.jpg" alt="Зображення продукту">';
  }
}

initializeProductViewer();

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

3. Регулювання складності анімації та ефектів

Проблема: Складні CSS-анімації, ефекти частинок та прозорі шари можуть виглядати дивовижно, але вони вимагають від браузера створення численних композитних шарів, які споживають багато пам'яті. На пристроях з низькими характеристиками це призводить до ривків та затримок.

Рішення: Використовуйте Device Memory API для зменшення масштабу або вимкнення несуттєвих анімацій.

Реалізація за допомогою CSS-класу:

Спочатку додайте клас до елемента `` або `` на основі перевірки пам'яті.

// Запустіть цей скрипт на початку завантаження сторінки
if (navigator.deviceMemory && navigator.deviceMemory < 1) {
  document.documentElement.classList.add('low-memory');
}

Тепер ви можете використовувати цей клас у своєму CSS для вибіркового вимкнення або спрощення анімацій:

/* Стандартна, красива анімація */
.animated-card {
  transition: transform 0.5s ease-in-out, box-shadow 0.5s ease;
}

.animated-card:hover {
  transform: translateY(-10px) scale(1.05);
  box-shadow: 0 10px 20px rgba(0,0,0,0.2);
}

/* Спрощена версія для пристроїв з малою пам'яттю */
.low-memory .animated-card:hover {
  transform: translateY(-2px); /* Набагато простіша трансформація */
  box-shadow: none; /* Вимкнути дорогу тінь */
}

/* Або повністю вимкнути інші важкі ефекти */
.low-memory .particle-background {
  display: none;
}

4. Надання «спрощеної» версії застосунку

Проблема: Для деяких складних односторінкових застосунків незначних налаштувань недостатньо. Сама основна архітектура — з її сховищами даних у пам'яті, віртуальним DOM та великим деревом компонентів — є занадто важкою для бюджетних пристроїв.

Рішення: Візьміть приклад з таких компаній, як Facebook та Google, які пропонують «Lite» версії своїх застосунків. Ви можете використовувати Device Memory API як сигнал для надання фундаментально простішої версії вашого застосунку.

Реалізація:

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

const MEMORY_THRESHOLD_FOR_LITE_APP = 1; // 1 ГБ

function bootstrapApp() {
  const isLowMemory = navigator.deviceMemory && navigator.deviceMemory < MEMORY_THRESHOLD_FOR_LITE_APP;
  
  if (isLowMemory && window.location.pathname !== '/lite/') {
    // Перенаправлення на спрощену версію
    window.location.href = '/lite/';
  } else {
    // Завантаження повного застосунку
    import('./main-app.js');
  }
}

bootstrapApp();

«Спрощена» версія може бути застосунком, відрендереним на сервері, з мінімальним клієнтським JavaScript, що зосереджується виключно на основній функціональності.

Більше, ніж `if`: Створення єдиного профілю продуктивності

Покладатися на один сигнал ризиковано. Пристрій може мати багато ОЗП, але бути в дуже повільній мережі. Більш надійний підхід — поєднувати Device Memory API з іншими адаптивними сигналами, такими як Network Information API (`navigator.connection`) та кількість ядер ЦП (`navigator.hardwareConcurrency`).

Ви можете створити єдиний об'єкт конфігурації, який буде керувати рішеннями у вашому застосунку.

function getPerformanceProfile() {
  const profile = {
    memory: 'high',
    network: 'fast',
    cpu: 'multi-core',
    saveData: false,
  };

  // Перевірка пам'яті
  if (navigator.deviceMemory) {
    if (navigator.deviceMemory < 2) profile.memory = 'low';
    else if (navigator.deviceMemory < 4) profile.memory = 'medium';
  }

  // Перевірка мережі
  if (navigator.connection) {
    profile.saveData = navigator.connection.saveData;
    switch (navigator.connection.effectiveType) {
      case 'slow-2g':
      case '2g':
        profile.network = 'slow';
        break;
      case '3g':
        profile.network = 'medium';
        break;
    }
  }

  // Перевірка ЦП
  if (navigator.hardwareConcurrency && navigator.hardwareConcurrency < 4) {
    profile.cpu = 'single-core';
  }
  
  return profile;
}

const performanceProfile = getPerformanceProfile();

// Тепер ви можете приймати більш тонкі рішення
if (performanceProfile.memory === 'low' || performanceProfile.network === 'slow') {
  // Завантажувати зображення низької якості
}

if (performanceProfile.cpu === 'single-core' && performanceProfile.memory === 'low') {
  // Вимкнути всі несуттєві анімації та JS
}

Обмеження, найкращі практики та інтеграція на стороні сервера

Хоча Device Memory API є потужним інструментом, його слід використовувати зважено.

1. Це підказка, а не гарантія

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

2. Сила Client Hints на стороні сервера

Приймати ці рішення на стороні клієнта — це добре, але це означає, що користувач уже завантажив початкові HTML, CSS та JS, перш ніж ви зможете адаптуватися. Для справді оптимізованого першого завантаження ви можете використовувати Client Hints. Це дозволяє браузеру надсилати інформацію про можливості пристрою на ваш сервер з першим HTTP-запитом.

Ось як це працює:

1. Ваш сервер надсилає заголовок `Accept-CH` у своїй відповіді, повідомляючи браузеру, що його цікавить підказка `Device-Memory`.
2. Приклад заголовка: `Accept-CH: Device-Memory, Viewport-Width, DPR`
3. При наступних запитах від цього браузера до вашого джерела він буде включати заголовок `Device-Memory` зі значенням пам'яті.
4. Приклад заголовка запиту: `Device-Memory: 8`

Маючи цю інформацію на сервері, ви можете приймати рішення ще до надсилання першого байта тіла відповіді. Ви можете відрендерити простіший HTML-документ, посилатися на менші CSS/JS-пакети або вставляти URL-адреси зображень з нижчою роздільною здатністю безпосередньо в HTML. Це найефективніший спосіб оптимізувати початкове завантаження сторінки для бюджетних пристроїв.

3. Як тестувати вашу реалізацію

Вам не потрібна колекція різних фізичних пристроїв для тестування ваших функцій, що враховують пам'ять. Chrome DevTools дозволяє вам перевизначати ці значення.

• Відкрийте DevTools (F12 або Ctrl+Shift+I).
• Відкрийте командне меню (Ctrl+Shift+P).
• Введіть «Show Sensors» і натисніть Enter.
• У вкладці «Sensors» ви можете знайти розділ для емуляції різних Client Hints, хоча сам Device Memory API найкраще тестувати безпосередньо або через сервер, який логує заголовок Client Hint. Для прямого тестування на стороні клієнта вам може знадобитися використовувати прапорці запуску браузера для повного контролю або покладатися на емуляцію пристроїв для комплексного тесту. Простішим способом для багатьох є перевірка значення заголовка `Device-Memory`, отриманого вашим сервером під час локальної розробки.

Висновок: Створюйте з емпатією

Frontend Device Memory API — це більше, ніж просто технічний інструмент; це засіб для створення більш емпатичних, інклюзивних та продуктивних веб-застосунків. Визнаючи та поважаючи апаратні обмеження нашої глобальної аудиторії, ми виходимо за рамки універсального підходу. Ми можемо надавати досвід, який є не тільки функціональним, але й приємним, незалежно від того, чи доступ до нього здійснюється з найсучаснішого комп'ютера або зі смартфона початкового рівня.

Почніть з малого. Визначте найбільш ресурсоємну частину вашого застосунку — чи то велике зображення, важка бібліотека, чи складна анімація. Впровадьте просту перевірку за допомогою `navigator.deviceMemory`. Виміряйте вплив. Роблячи ці поступові кроки, ви можете створити швидший, більш стійкий та привітніший веб для всіх.