Перейти к основному содержимому

Быстрое ПО не ускоряет всё подряд. Оно убирает работу из времени ожидания пользователя.

Лестница

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

  1. 1 Не вычислять вовсе critical-path-deferred-tail
  2. 2 Вычислить один раз hierarchical-cache
  3. 3 Вычислить до того, как попросят intent-preloading
  4. 4 Вычислять рядом с данными или пользователем compute-locality
  5. 5 Независимую работу выполнять параллельно no-waterfall-loading
  6. 6 Закэшировать результат stale-while-revalidate
  7. 7 Отвечать оптимистично там, где это безопасно optimistic-mutation
  8. 8 Откладывать некритичную работу critical-path-deferred-tail

Критичное, отложенное, фоновое

Отнести работу к верному классу обычно выгоднее, чем ускорить её.

Критичное

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

Отложенное

Должно случиться скоро, но никто этого не ждёт: аналитика, индексация поиска, уведомления, производные метаданные.

Фоновое

Вообще не связано с этим ответом: экспорт, обработка медиа, обогащение через ИИ, очистка, дорогие проекции.

Что здесь измеряется

Вкладка «Данные» выполняет обе ветви каждого сравнения прямо в запросе, который их попросил, — настоящая зависимость на 60 мс, настоящая лавина из 100 вызывающих, настоящие модули кэша. Поверхности измерений живут отдельно:

Когда не нужно

Архитектура производительности создаёт сложность, а сложность без выгоды — это чистые издержки. Статическому сайту нужны доставка ассетов, предзагрузка и бюджеты бандла — а не Redis, singleflight, read-модели или распределённая трассировка.

Внедряйте наименьший набор, который оправдан реальными задержками вашего приложения.

Думаете, этот паттерн можно сделать лучше? Расскажите как.

Оставить отзыв