В предыдущем посте я поделился базовым примером того, как приложения с поддержкой базы данных, в частности WordPress, работают без кэширования.
И прежде чем мы поговорим о том, как работает базовое кэширование в WordPress, а именно с Transients API, важно обсудить основные принципы кэширования. Это включает в себя, почему мы это делаем, его преимущества и как это работает.
Затем мы рассмотрим, как мы можем использовать основные возможности WordPress, чтобы сделать это.
Понимание кэширования в WordPress: кэширование?
Почему мы это делаем
Вообще говоря, мы делаем это, чтобы наши сайты работали быстро. Мы знаем, что скорость влияет на ранжирование страницы в результатах поиска. И хотя это может быть не основной причиной, это важная причина.
Возможно, самый простой и лучший аргумент в пользу кэширования — наличие быстрого сайта (или производительного сайта). И, в данном контексте, это может означать сайт или веб-приложение.
Несмотря на это, мы знаем, каково это, когда мы сидим и ждем загрузки страницы или части страницы. Если нам это не нравится, почему мы хотим, чтобы наши посетители испытывали это?
Его преимущества
Преимущества кэширования проявляются как минимум в двух основных областях:
- Пользовательский опыт,
- время загрузки.
В предыдущем разделе я сказал, что преимущества кэширования можно ощутить, если вы пользователь. Это то, с чем мы все сталкивались, и как разработчики мы можем предложить это нашим пользователям с помощью различных методов.
Но «время загрузки» также имеет значение, и речь идет не только о преимуществах того, сколько времени требуется пользователю, чтобы загрузить сайт. Вместо этого, это немного более технический вопрос.
Напомним в предыдущем посте, что запрос — или поездка — начинается с того момента, когда пользователи запрашивают информацию с сервера, а затем процесс переходит от машины пользователя к серверу, к базе данных и обратно.
Когда мы ввели кэширование, нам не нужно делать все это. Вместо этого поездка сокращается, потому что данные фактически хранятся где-то в другом месте. А если путь короче (и я не имею в виду от компьютера пользователя до того места, где в мире находится сервер), то он должен быть и быстрее.
Но как?
Как это работает
Существует множество доступных типов кэширования, но я держу эту конкретную серию на высоком уровне. То есть я не буду различать кеш браузера, кеш страниц, кеш объектов и т.д.
Возможно в будущем посте. Но пока я говорю конкретно о кэшировании на высоком уровне.
В любом случае, вот как это работает:
- Во время первого посещения страницы собирается вся информация, необходимая для загрузки страницы.
- Вместо того, чтобы сбрасывать ее, когда пользователь покидает сайт (или страницу), информация хранится в легкодоступном месте, например, в памяти сервера.
- Когда следующий пользователь переходит на страницу, ему не нужно обращаться к базе данных, чтобы получить всю информацию, собрать ее и затем вернуть пользователю. Вместо этого он вытягивает полностью собранную информацию из памяти сервера (что, в большинстве случаев) уже быстрее, а затем возвращает ее пользователю.
При этом необходимо учитывать множество предостережений, таких как настраиваемые пользовательские данные, частичная загрузка страниц и т. д., но принцип поездки остается прежним.
Переходные процессы WordPress
Итак, как это работает в WordPress? На самом фундаментальном уровне Transients API предоставляет для этого некоторые базовые функции.
Но важно понимать, как это работает и почему это работает именно так, а не иначе. Поэтому в следующем посте этой серии я расскажу именно об этом.