Проверка корректности payload

Web Vitals — это библиотека, предназначенная для измерения ключевых показателей производительности веб-страниц, таких как LCP (Largest Contentful Paint), FID (First Input Delay) и CLS (Cumulative Layout Shift). Важной частью работы с Web Vitals является проверка корректности данных, которые отправляются на сервер или обрабатываются внутри приложения. Неправильные или неполные payload могут привести к искажению метрик, что снижает ценность аналитики и может повлиять на оптимизацию сайта.

Основные принципы проверки payload

  1. Структура объекта

    Все метрики в Web Vitals передаются в виде объектов с определёнными свойствами. Например, объект для LCP выглядит так:

    {
      name: 'LCP',
      value: 1234.56,
      id: 'v1-1234567890',
      entries: [PerformanceEntry],
      rating: 'good'
    }

    Ключевые свойства, требующие обязательной проверки:

    • name — название метрики (LCP, FID, CLS и др.).
    • value — числовое значение метрики.
    • id — уникальный идентификатор измерения.
    • entries — массив записей PerformanceEntry, откуда получены данные.
    • rating — словесная оценка показателя (good, needs-improvement, poor).
  2. Типизация значений

    Для корректного анализа данных критично, чтобы типы свойств совпадали с ожидаемыми:

    • value должен быть числом. Проверка через typeof metric.value === 'number'.
    • entries должен быть массивом объектов типа PerformanceEntry.
    • rating должен соответствовать допустимому набору строк: ['good', 'needs-improvement', 'poor'].
  3. Диапазоны значений

    Значения метрик Web Vitals имеют рекомендации по допустимым диапазонам:

    Метрика Хороший результат Показатель нуждается в улучшении Плохой результат
    LCP ≤ 2.5 сек 2.5–4 сек > 4 сек
    FID ≤ 100 мс 100–300 мс > 300 мс
    CLS ≤ 0.1 0.1–0.25 > 0.25

    Проверка payload должна включать в себя контроль, что числовые значения попадают в реалистичные диапазоны. Например:

    if (metric.value < 0 || metric.value > 10000) {
      console.warn('Некорректное значение метрики', metric);
    }

Практические методы верификации

  1. Функция проверки объекта метрики

    Создание функции для централизованной проверки всех поступающих метрик позволяет гарантировать, что payload соответствует требованиям:

    function validateMetric(metric) {
      if (!metric || typeof metric !== 'object') return false;
      if (!['LCP','FID','CLS','TTFB','FCP'].includes(metric.name)) return false;
      if (typeof metric.value !== 'number' || metric.value < 0) return false;
      if (!Array.isArray(metric.entries)) return false;
      if (!['good','needs-improvement','poor'].includes(metric.rating)) return false;
      return true;
    }
  2. Проверка целостности данных перед отправкой на сервер

    Перед отправкой payload на аналитическую платформу важно убедиться, что все ключи присутствуют и не содержат пустых значений. Пример:

    const metrics = [];
    webVitals.getLCP(metric => {
      if (validateMetric(metric)) metrics.push(metric);
    });
    webVitals.getFID(metric => {
      if (validateMetric(metric)) metrics.push(metric);
    });
    
    if (metrics.length) {
      sendMetricsToServer(metrics);
    }
  3. Логирование ошибок и исключений

    В случаях, когда payload не соответствует требованиям, необходимо логировать ошибки с детальной информацией. Это позволит быстро обнаружить сбои и неправильно измеряемые метрики:

    if (!validateMetric(metric)) {
      console.error('Ошибка в payload Web Vitals', metric);
    }

Особенности CLS и FID

  • CLS (Cumulative Layout Shift) может содержать несколько entries, каждая из которых имеет отдельный value и startTime. При проверке нужно убедиться, что агрегированное значение соответствует сумме всех смещений и не превышает ожидаемых рамок.
  • FID (First Input Delay) часто измеряется только один раз, но объект может содержать processingStart и startTime. В payload необходимо проверить наличие этих полей для правильной интерпретации задержки.

Проверка нестандартных случаев

  1. Метрики могут приходить с value = 0 в случае, если событие не произошло. В таких случаях payload корректен, но значение требует особого внимания.
  2. Если entries пустой массив, нужно убедиться, что это нормальная ситуация для конкретной метрики (например, FID на странице без интерактивных элементов).
  3. Проверка уникальности id для каждой метрики предотвращает дублирование данных.

Автоматизация проверки

Для больших проектов рекомендуется использовать Unit-тесты для функций валидации payload. Например:

describe('validateMetric', () => {
  it('должна возвращать true для корректного payload', () => {
    const metric = {
      name: 'LCP',
      value: 1500,
      id: 'v1-abc123',
      entries: [],
      rating: 'good'
    };
    expect(validateMetric(metric)).toBe(true);
  });

  it('должна возвращать false для некорректного payload', () => {
    const metric = {
      name: 'LCP',
      value: -50,
      id: 'v1-abc123',
      entries: [],
      rating: 'good'
    };
    expect(validateMetric(metric)).toBe(false);
  });
});

Такой подход позволяет автоматически контролировать качество данных и минимизировать ошибки при передаче payload в аналитические системы.