Перейти к содержимому 
Кэширование иерархий обеспечиваю самое быстрое время загрузки, когда использую каждый слой в отдельности: опкод, страницу, браузер и край. Я показываю в четких шагах, как я комбинирую эти слои, избегаю конфликтов и настраиваю конфигурации таким образом, что запросы становятся короче, а TTFB заметно сокращается.
Центральные пункты
Для того чтобы обзор был понятным, я сначала кратко излагаю основные темы и связываю их непосредственно с целями эффективности. Я объясняю все уровни с конкретными настройками, чтобы внедрение прошло успешно и без сбоев. Я четко разграничиваю динамические части, чтобы сохранить персонализацию. Я оптимизирую заголовки и ключи кэша, чтобы в кэше не было ненужных отходов. Наконец, я объединяю все в строгую цепочку, чтобы каждое извлечение происходило по самому быстрому пути.
- Опкод ускоряет работу PHP
- Кэш страниц сокращенный TTFB
- Браузер Экономия пропускной способности
- Край Уменьшает задержку
- Оркестровка Предотвращает конфликты
Что на самом деле означает „кэширование иерархий“?
Я понимаю, что Иерархия поэтапное кэширование от ядра сервера до конечного устройства. Каждый уровень отвечает на разные вопросы: должен ли сервер перекомпилировать код, должен ли PHP перерисовывать страницу, должен ли браузер перезагружать активы или пограничный узел доставлять готовый контент в непосредственной близости от пользователя. Я избегаю дублирования работы, согласовывая уровни и распределяя четкие обязанности. Таким образом, я снижаю нагрузку на процессор, количество запросов к бэкенду и сетевые задержки без потери функциональности. Краткое представление об уровнях можно найти в этом компактном руководстве: Простые уровни кэширования.
Кэширование опкодов: ускорьте PHP немедленно
На сайте Опкод-С помощью кэширования я храню скомпилированный байткод PHP в оперативной памяти и избавляю себя от повторного разбора. Это ускоряет каждый запрос, связанный с PHP, особенно CMS, такие как WordPress. Я включаю OPcache и увеличиваю объем памяти настолько, что часто используемые скрипты никогда не вытесняются. Я устанавливаю умеренную ревалидацию, чтобы изменения оставались видимыми быстро и без слишком частых проверок. Таким образом, я заметно снижаю как нагрузку на процессор, так и время отклика.
Я намеренно устанавливаю типичные параметры OPcache в php.ini консервативно, слежу за показателями и корректирую их по мере необходимости. Количество ускоряемых файлов достаточно велико, чтобы проект полностью поместился. Я использую предварительную загрузку для центральных классов, чтобы даже холодный старт выполнялся быстрее. Я развертываю изменения со сбросом кэша, чтобы избежать риска несовместимых состояний. Я использую конфигурационный блок как отправную точку, а не как жесткую догму.
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2
Я регулярно проверяю OPcache-статистика, потому что только измерение показывает, работает ли кэш или нет. Панели управления хостингом или страницы состояния PHP помогают мне минимизировать количество промахов. Я избегаю слишком маленьких значений памяти, которые приводят к вытеснению. Я также избегаю редкой валидации, чтобы продуктивные изменения не застревали. Благодаря такому балансу я работаю эффективно и безопасно.
Кэширование страниц: HTML без времени ожидания
На сайте Кэш страниц Я сохраняю готовый HTML так, чтобы PHP и база данных больше не запускались. Это значительно снижает TTFB и дает самые большие скачки под нагрузкой. Я последовательно исключаю персонализированные пути, такие как корзина, оформление заказа и учетные записи пользователей. В то же время я инкапсулирую небольшие динамические части с помощью AJAX или edge-side includes, чтобы все остальное было доступно из кэша. Благодаря этому сайт работает быстро, не теряя важной индивидуальности.
Я решаю, использовать ли кэширование на уровне сервера или работать с плагином. На сервере я добиваюсь наилучшего результата Латентность, Плагины дают мне возможность гибко управлять CMS. Механизмы предварительной загрузки предварительно заполняют кэш, чтобы не ждать первых вызовов. При обновлении контента я очищаю осиротевшие записи с помощью правил очистки. Для особо дорогих областей я также объединяю объектный кэш, чтобы обращения к базе данных происходили реже.
Кэширование в браузере: сохраняйте активы локально
На сайте Браузер-Я оставляю статические файлы, такие как изображения, CSS и JS, в локальном кэше. Тогда возвращающиеся посетители почти ничего не загружают, а сервер остается свободным. Я устанавливаю длительные значения max-age для неизменяемых активов, которые я обеспечиваю версионированием имен файлов. Я добавляю короткое время или must-revalidate к динамическим конечным точкам, чтобы приложение оставалось актуальным. Таким образом, я снижаю пропускную способность и оптимизирую воспринимаемую скорость.
Я обращаю внимание на чистое сочетание контроля кэша, ETag и last-modified. Для неизменяемых файлов я устанавливаю immutable, чтобы браузер не проверял их без необходимости. Для ресурсов с частыми обновлениями я использую условные запросы по ETag. Я избегаю двусмысленных заголовков, потому что противоречивые сигналы приводят к недопониманию. Я держу контроль непосредственно на веб-сервере или через CMS-плагин, в зависимости от окружения.
Пограничное кэширование: близость к пользователю
О сайте Край-сети, я доставляю контент в глобальные PoP, что минимизирует задержки и сглаживает пики. HTML, изображения и API могут обслуживаться в непосредственной близости от пользователя в зависимости от набора правил. Я работаю с ключами кэша, которые содержат только необходимые переменные, чтобы минимизировать фрагментацию. Такие правила, как stale-while-revalidate и stale-if-error, гарантируют, что пользователи сразу увидят корректную копию, даже если Origin только разогревается. Особенно выигрывают международные целевые группы, поскольку время маршрутизации заметно сокращается.
Я разделяю варианты, когда мобильные и настольные версии сильно отличаются. Я намеренно оставляю область оформления заказа и аккаунта на краю, чтобы избежать столкновения с сессиями и куками. Я регулярно проверяю процент попаданий и корректирую TTL до достижения оптимальных показателей. Практический углубленный взгляд на это Руководство по кэшированию краев с акцентом на задержку и сетевые пути. Я держу под рукой чистые стратегии очистки, чтобы обновления вступали в силу немедленно по всему миру.
Правильно установите HTTP-заголовок
Die Заголовок контролировать, как далеко содержимому разрешено перемещаться и когда оно перепроверяется. Я использую контроль кэша для определения видимости, срока жизни и обязательств по перепроверке. ETag уникально идентифицирует ресурс и позволяет выполнять запросы, если они не совпадают. Last-Modified обеспечивает запасной вариант для клиентов, которые игнорируют ETag. Я поддерживаю четкую комбинацию, чтобы клиент, CDN и источник имели одинаковые ожидания.
Я использую следующий обзор в качестве практического руководства при конфигурировании. Я проверяю каждую строку на соответствие типу ресурса и поведению при изменении. Для статических файлов я устанавливаю длительные значения max-age с помощью immutable. Для часто обновляемого контента я уменьшаю длительность и полагаюсь на условные запросы. Это позволяет сохранить эффективность и корректность пути данных.
| Заголовок | Функция |
|---|---|
| Управление кэшем | Контролирует продолжительность, видимость, повторное подтверждение (например, max-age, public, must-revalidate). |
| ETag | Уникальный идентификатор версии, основа для условных вызовов |
| Last-Modified | Временная метка как альтернатива ETag, используется для проверки |
Стратегии аннулирования и свежести кэша
Я планирую Инвалидизация так же тщательно, как и само кэширование. Выборочная очистка по идентификатору, тегу или пути предотвращает полную очистку, которая приводит к издержкам. При развертывании я очищаю только то, что действительно изменилось. Stale-while-revalidate позволяет пользователям работать быстро, пока в фоновом режиме загружаются свежие копии. Stale-if-error ловит сбои в Origin, не ухудшая работу пользователей.
Если контент часто ротируется, я сочетаю короткое TTL с высоким коэффициентом попадания. Для архивов, медиа и библиотек я выбираю длительное время, версионные имена файлов и удаляю контрольные загрузки. Панели мониторинга на стороне CDN или сервера показывают мне, где кэш-баки слишком малы. Тогда я корректирую количество слотов и размеры объектов. Эта постоянная тонкая настройка имеет большое значение в повседневной жизни.
Ключи кэша, файлы cookie и Vary
С тонким Ключи Я поддерживаю небольшое количество вариантов. В ключ попадают только те параметры, которые действительно меняют результат. Я намеренно использую заголовки Vary, например, после классов Accept-Encoding или User-Agent, если это необходимо. Слишком большое количество куки в ключе разрушает кэш и снижает процент попаданий. Я удаляю из ключа неиспользуемые куки и регулирую параметры, которые используются для отслеживания.
Если мне нужно варьировать языки, валюты или макеты, я использую специальные ключи, такие как lang=de или currency=EUR. Я ограничиваю это разнообразие теми случаями, которые мне действительно нужны. Для A/B-тестов я разделяю только те сегменты, которые отличаются по содержанию. Все остальное я делаю на стороне клиента или с помощью пограничной логики без взрыва ключей. Так я поддерживаю эффективность глобального кэша.
Кэш объектов и переходные процессы
A Объект-Кэш уменьшает количество дорогостоящих запросов к базе данных, сохраняя результаты в памяти. Для WordPress я выбираю Redis или Memcached, чтобы обеспечить быстрый доступ к часто запрашиваемым параметрам, запросам и сессиям. Я использую переходные процессы для временного хранения дорогостоящих вычислений. Я очищаю эти значения во время развертывания, когда меняются зависимости. Таким образом, страница остается динамичной и при этом быстрой.
Это сравнение помогает мне в проектах с интенсивной загрузкой данных: Redis против Memcached. Там я узнаю типичные сильные стороны обеих систем в зависимости от рабочей нагрузки. Я определяю объем оперативной памяти и проверяю стратегии вытеснения, чтобы освободить место для редко используемых объектов. Мониторинг количества попаданий/пропусков показывает, работает ли конфигурация. Этот уровень идеально дополняет страничный кэш.
Комбинация: оптимизированная цепочка
Я сочетаю Уровни чтобы каждый запрос проходил по кратчайшему пути. OPcache ускоряет генерацию, когда HTML фактически создан. Кэш страниц предоставляет готовую разметку для анонимных посетителей. Кэширование браузера предотвращает повторную передачу активов, а Edge распределяет контент глобально. В самом конце - чистая очистка и стратегия версионирования, чтобы обновления вступали в силу немедленно.
Я держу следующую таблицу под рукой в качестве шпаргалки при изменении настроек. Я читаю колонку „Конфигурация“ как список дел во время реализации. Я слежу за тем, чтобы уровни дополняли друг друга и не отменяли друг друга. Это позволяет сохранить общую архитектуру понятной и эффективной. Такой обзор позволяет избежать ошибок при планировании.
| Уровень кэша | Преимущество | Типичное содержание | Конфигурация |
|---|---|---|---|
| Опкод | Быстрое выполнение PHP | Байткод PHP | php.ini, Server-Panel |
| Страница | Низкий уровень TTFB | Готовый HTML | Уровень сервера или плагина |
| Браузер | Повторное использование в местных условиях | CSS, JS, изображения | HTTP-заголовок, версионирование |
| Край | Глобальная близость | HTML и активы | Правила CDN, Ключи, Очистка |
Измерение: TTFB, LCP и количество попаданий
Я измеряю TTFB, чтобы узнать, как быстро приходит первый байт. LCP показывает, вовремя ли появляется видимое содержимое. Я использую аналитику кэша, чтобы проверить количество попаданий и выявить маршруты, на которых накапливаются промахи. Я соотношу показатели с развертыванием, нагрузкой краулеров и пиками трафика. Только цифры показывают, где мне нужно подкрутить гайки.
Я регистрирую такие заголовки ответа, как Age и статус кэша CF, чтобы визуализировать успехи на границе. Журналы сервера показывают, правильно ли работает кэш страниц. Если есть большие отклонения, я ищу куки, параметры запроса или переменные, которые разделяют кэш. Я тестирую варианты с состоянием входа в систему и без него. Таким образом, я могу быстро найти настройки для стабильной скорости.
Типичные ошибки и их исправление
Слишком много Варианты в кэше являются частым тормозом. Я уменьшаю параметры запроса в ключе и нейтрализую параметры отслеживания. Еще одна классика - противоречивые заголовки, например no-store вместе с длинным max-age. Пустые или некорректные очистки также могут создавать впечатление, что кэш не работает. Я быстро решаю такие проблемы с помощью четких правил и журналов.
Еще одна проблема - плагины, которые записывают динамический контент в HTML. Я перемещаю такие элементы на фрагментированные конечные точки, которые кэшируются или перезагружаются независимо. Куки часто непреднамеренно блокируют краевой кэш; я удаляю ненужные куки на ранних этапах. Плохая версионность заставляет браузеры перезагружаться снова и снова; я последовательно нумерую файлы. Это позволяет сохранить чистоту и устойчивость конвейера.
Дерево решений: кто отвечает на запрос?
Я определяю четкий путь принятия решения, чтобы определить, какой уровень разрешено доставить. Это позволяет избежать ненужных ударов по источнику и воспроизводимо снизить TTFB.
- 1) Является ли ресурс неизменяемым (файл с версиями)? Кэш браузера с большим max-age и неизменяемый.
- 2) Является ли запрос анонимным, GET и без чувствительных файлов cookie? Кэш края/страницы с public, s-maxage и stale-while-revalidate.
- 3) Содержит ли запрос Auth-Cookies, Authorisation-Header или является POST? Origin, опционально с Object-Cache.
- 4) Содержит ли URL только косметические параметры (utm, fbclid)? Я удаляю их из кэш-ключа.
- 5) Вам нужны небольшие живые фрагменты (например, количество корзин)? Фрагментация с помощью AJAX или ESI.
// псевдологика
if (immutable_asset) return browser_cache;
if (is_get && is_anonymous && cacheable) return edge_or_page_cache;
if (needs_fragment) return cached_html + dynamic_fragment;
return origin_with_object_cache;Освоение фрагментации: ESI, AJAX и частичный рендеринг
Я изолирую динамические острова, чтобы остальные могли усиленно кэшироваться. ESI подходит для инъекций на стороне сервера (например, персонализированные блоки), AJAX - для точек перезагрузки на стороне клиента. Важно, чтобы фрагменты имели свой собственный, короткий TTL, чтобы они оставались актуальными, не теряя при этом актуальности всего документа.
- Статические основы: long TTL, public, s-maxage, stale-while-revalidate.
- Динамический фрагмент: короткий TTL, must-revalidate или no-store, если персонализирован.
- Случай ошибки: stale-if-error в HTML-обертке предотвращает появление белых страниц.
// Пример заголовка для HTML-конверта
Cache-Control: public, max-age=0, s-maxage=600, stale-while-revalidate=60, stale-if-error=86400
// Пример заголовка для личного фрагмента
Cache-Control: private, no-storeИзбегайте давки в кэше и контролируйте разминку
Я предотвращаю эффект стада, когда множество одновременных промахов наводняют Origin. Мягкий TTL/жесткий TTL, коалесцирование и блокировка запросов - вот мои инструменты. Я использую прелоадеры, которые циклически разогревают карты сайтов или важные пути, и распределяю TTL так, чтобы не все истекало одновременно.
- Мягкий TTL: рабочий может обновлять объекты с истекшим сроком действия, в то время как другие потребители продолжают получать просроченные объекты.
- Coalescing: одновременные запросы на один и тот же ключ объединяются.
- Поэтапные TTL: Критические страницы получают ступенчатое время выполнения, чтобы сгладить волны очистки.
// Пример градуированного времени выполнения
/home, /category/* -> s-maxage=900
/article/* -> s-maxage=1800
/search -> s-maxage=120, stale-while-revalidate=30Выровняйте конструкцию TTL в цепи
Я настраиваю TTL в браузере, на границе и в оригинале так, чтобы повторная проверка происходила там, где это наиболее выгодно. Для HTML я полагаюсь на s-maxage на границе и держу max-age низким в браузере, чтобы гарантировать быструю очистку. Для активов я делаю все наоборот: очень длинные TTL в браузере, потому что версионность гарантирует актуальность.
// HTML
Cache-Control: public, max-age=0, s-maxage=600, stale-while-revalidate=60
// Версифицированные активы
Cache-Control: public, max-age=31536000, immutableЯ избегаю противоречивых спецификаций, таких как no-cache и immutable. Четкие правила создают согласованные результаты во всей иерархии.
Сжатие, HTTP/2/3 и приоритизация
Я активирую Gzip/Brotli и правильно настраиваю заголовок Vary, чтобы варианты были чисто разделены. С HTTP/2/3 я получаю преимущество от мультиплексирования и приоритезации; это уменьшает блокировку головной части линии при параллельной загрузке большого количества активов.
Пример # NGINX
gzip включен;
gzip_types text/css application/javascript application/json image/svg+xml;
brotli включен;
brotli_types text/css application/javascript application/json image/svg+xml;
add_header Варьировать "Accept-Encoding" всегда;
# Длительное TTL браузера для активов
location ~* .(css|js|svg|woff2|jpg|png)$ {
срок действия 1 год;
add_header Cache-Control "public, max-age=31536000, immutable";
}Аутентификация, файлы cookie и безопасность
Я никогда не кэширую личный контент публично. Запросы с заголовками авторизации или сессионными куками я помечаю как приватные или специально обхожу краевой кэш. В то же время я вношу в белый список только важные файлы cookie, чтобы ключ кэша оставался свободным.
- Зоны входа/аккаунта: Контроль кэша: приватный или no-store.
- Публичные HTML-страницы: public, s-maxage; не устанавливать cookie.
- Гигиена куки: удалите из ключа неактуальные куки (например, отслеживающие).
// VCL-подобная логика
if (req.http.Authorisation) { return(pass); }
if (req.http.Cookie ~ "session=") { return(pass); }
// Только необходимые куки в ключе
unset req.http.Cookie: ".*";
Эффективное кэширование API и конечных точек поиска
Я строго разграничиваю методы: GET можно кэшировать, POST обычно нет. Для частых поисковых запросов я устанавливаю короткие значения s-maxage плюс stale-while-revalidate, чтобы сгладить время отклика. Ответы с ошибками 4xx/5xx я кэширую недолго или вообще не кэширую, чтобы исправления вступали в силу немедленно.
// Пример заголовка для публичного GET API
Cache-Control: public, max-age=0, s-maxage=120, stale-while-revalidate=30
// Ошибки кэширования допускаются редко
Cache-Control: public, s-maxage=10Наблюдаемость: заголовки, журналы и проверка TTFB
Я использую проверку заголовков и журналы, чтобы сделать цепочку прозрачной. Возраст, индикаторы попаданий/промахов и состояние восходящего потока показывают мне, где теряется время. Я использую простые инструменты для воспроизводимой проверки TTFB и поиска промахов.
Измерьте # TTFB
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}sn" https://example.org
Проверка заголовка #
curl -I https://example.org | sed -n '1,20p'Журнал # NGINX со статусом кэша
log_format timed '$remote_addr "$request" $status $body_bytes_sent '
'$upstream_cache_status $upstream_response_time $request_time';
access_log /var/log/nginx/access.log timed;Я сравниваю данные журнала с развертываниями и очистками. Высокие пики пропусков сразу после развертывания указывают на недостаточный прогрев или слишком короткие TTL. Если показатель Age остается постоянно низким, я проверяю, не обходят ли куки-файлы пограничный кэш непреднамеренно.
Развертывание: версионирование и скользящая очистка
Я встраиваю версии в имена файлов (например, app.9f3c1.js), чтобы кэширование браузера было агрессивным. Для HTML я использую скользящую очистку, при которой сначала обновляются критические страницы, а затем - глубинные и долгоиграющие. Синие/зеленые развертывания отделяют сборку от релиза и дают мне время специально прогреть кэш.
// Конвейер активов
style.[hash].css
app.[hash].js
// HTML всегда ссылается на новые хэшиЯ планирую окна очистки вне пиковых моментов и сразу после этого отслеживаю количество попаданий. Таким образом я избегаю пиков нагрузки на Origin.
Варианты изображений, DPR и отзывчивое кэширование
Я генерирую варианты изображений (размер, формат) детерминированно, чтобы ключ кэша оставался стабильным. Для вариантов WebP/AVIF я разделяю их явно через путь к файлу или параметры, а не только через заголовки Accept, чтобы избежать взрывов Vary. Для дисплеев высокого разрешения (DPR) я использую srcset/sizes, что позволяет браузеру выбрать лучший вариант, а кэшу - вступить в силу для каждого конкретного актива.
<img src="img/hero-1024.jpg"
srcset="img/hero-768.jpg 768w, img/hero-1024.jpg 1024w, img/hero-1600.jpg 1600w"
sizes="(max-width: 768px) 90vw, 1024px" alt="">Я поддерживаю небольшое количество вариантов на мотив и удаляю устаревшие размеры из конвейера, чтобы кэш не фрагментировался.
Планирование емкости: кэш-память и размеры объектов
Я определяю размер кэша в соответствии с реальными моделями доступа: несколько больших объектов (изображения, видео) требуют иных стратегий, чем множество маленьких (HTML, JSON). Я устанавливаю ограничения на максимальный размер объекта и проверяю, остаются ли популярные объекты в памяти. Высокий коэффициент повторного использования важнее, чем абсолютный размер; поэтому я обрезаю ключи, объединяю варианты и предотвращаю дубликаты.
// Пример: Ограничения
max_object_size = 10m
default_ttl = 600
nuke_limit = moderate (выселения без ларьков)Практический контрольный список для внедрения
Я активирую OPcache с достаточным объемом памяти и проверьте количество посещений. Затем я настраиваю кэширование страниц, исключаю критические пути и предварительно загружаю важные URL-адреса. Затем я устанавливаю заголовки браузера с длительным временем хранения неизменяемых файлов и версионность. В CDN я определяю ключи кэша, TTL и стратегии очистки, а также активирую stale-while-revalidate. Наконец, я использую измерительные инструменты, чтобы проверить, достигают ли целевых показателей TTFB, LCP и edge hit rate.
Краткое содержание
Я использую Кэширование Иерархический: OPcache ускоряет код, кэш страниц доставляет HTML, заголовки браузера сохраняют локальность активов, а Edge приближает контент к пользователям. С помощью четких ключей, подходящих TTL и продуманного аннулирования я снижаю нагрузку на сервер, пропускную способность и задержку. Измеренные значения обеспечивают прогресс и показывают потенциал оптимизации. Таким образом, создается надежная цепочка от источника до конечного устройства. Тот, кто ищет дополнительные подробности о глобальной доставке, найдет достаточно отправных точек на практике, чтобы сделать свою собственную архитектуру заметно быстрее.
