Кэшируем свой сайт


Оглавление (нажмите, чтобы открыть):

Что такое кэш сайта и его удаление

26 октября 2020 года. Опубликовано в разделах: Азбука терминов. 5591

Больше видео на нашем канале — изучайте интернет-маркетинг с SEMANTICA

Кэширование ресурса – процедура занесения отдельной информации с сайта в кэш.

Объекты кэширования – файлы CSS, JavaScript, HTML-шаблоны, графические изображения.

Чтобы вы понимали, что такое кэш, объясним это понятие простыми словами на примере.

На ПК есть пространство, выделенное для хранения текущей информации, получаемой с ресурсов. Во время работы на сайте там сохраняются данные. Благодаря кэшированию можно просмотреть местоположение загруженного файла, выполнить перезагрузку. Определение «кэш» не применяется исключительно к интернет-ресурсам, хранилище используется и при работе в мобильных телефонах, стационарных компьютерах, планшетах.

Основные задачи кэширования

Главная задача — это ускорение работы программы, загрузки сайта и т. д. Время извлечения из кэша меньше, нежели получение информации из какого-то удаленного источника.

Чем чище кэш браузера, тем легче работать с ресурсом. Чтобы обеспечивать высокую скорость загрузки страниц, закачку приложений и файлов, вызывать минимум ошибок «Time out» на странице, требуется время от времени сбрасывать кэш сайта.

Взаимодействие приложений с кэшем браузера

Кэш работает следующим образом:

  • Вначале информация сайта загружается с сервера, а затем необходимые данные поступают в кэш на клиентский компьютер.
  • В дальнейшем, некоторые данные загружаются не с сервера, а берутся из кэша. Это ускоряет загрузку сайта.
  • Если временное хранилище пустует или же данные позиционируют как устаревшие (сайт постоянно меняется, обновляется и дополняется свежими материалами), запрос отправляется по первоначальному маршруту, вся последующая вереница действий повторяется.

Каким бывает кэширование ресурса

Процесс кэширования информации довольно длинный, ведь сохранение исходных файлов осуществляется на принципиально разных уровнях.

Существует два вида кэширования.

Серверное

Все данные находятся во временном хранении исключительно на сервере. Специально для этого применяют некоторый механизм кэширования, который присущ самой платформе. Сохраняются в указанном случае страницы HTML, имеющиеся результаты ранее отправленных запросов в сетевые базы данных. Сведения располагаются как отдельные файлы, занесенные в оперативную память ПК (для чего используется memcached). Чтобы не создавать проблем с хранением информации, администрация отдельных проектов даже создает отдельный сервер исключительно под кэш.

Клиентское

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

У отдельных провайдеров предусмотрена возможность настройки кэширования файлов, которая позволит оптимально управлять содержимым хранилища и при необходимости использовать информацию для работы с ресурсами.

Вы сами формируете оценки эффективности для нас: продажи, кол-во заявок, другое
Мы работаем в рамках ваших бюджетов на прогнозируемый результат

Кэширование на сервере

Кэширование на сервере

Такое программное обеспечение, как eAccelerator/xCache/ZendOptimizer для PHP, mod_perl для perl, mod_python для python и др., могут кэшировать серверные скрипты в скомпилированном состоянии, существенно ускоряя загрузку нашего сайта. Кроме этого, стоит найти профилирующий инструмент для используемого языка программирования, чтобы установить, на что же тратятся ресурсы CPU. Если удастся устранить причину больших нагрузок на процессор, то страницы будут отдаваться быстрее и появится возможность выдавать больше трафика при меньшем числе машин.

Если на сайте при создании страницы выполняется много запросов к базе данных или какие-либо другие тяжелые вычисления, стоит рассмотреть добавление кэширования на стороне сервера для медленных операций. Большинство людей начинают с записи кэша в локальную память или на локальный диск, однако эта логика перестает работать, если система расширяется до кластера веб-серверов (каждый со своим локальным диском и локальной памятью).

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

Похожие главы из других книг

Глава 3. Кэширование

Глава 3. Кэширование 3.1. Expires, Cache-Control и сброс кэша Кэширование играет одну из основных ролей в быстродействии сайтов и сравнительно просто настраивается на стороне сервера. Веб-разработчики часто сталкиваются с кэшированием, ибо браузеры и проксирующие серверы, пытаясь

3.4. Кэширование в iPhone

3.4. Кэширование в iPhone На MacWorld’2008 Steve Jobs анонсировал, что Apple уже продала на текущий момент 4 миллиона iPhone, что составляет по 20 тысяч iPhone каждый день. В докладе Net Applications говорится, что общая доля пользователей Интернета с iPhone поднялась до 0,12% в декабре 2007 года, обогнав, в

Балансировка на сервере

Балансировка на сервере Другим популярным подходом для балансировки запросов является создание одного выделенного сервера, который отвечает за распределение запросов. Примерами таких серверов могут быть специальное оборудование или программные решения, например

7.7. Кэширование в JavaScript

7.7. Кэширование в JavaScript Очень часто в JavaScript используют глобальные объекты и переменные для чтения каких-либо параметров (или вызова определенных методов). Почти всегда этого можно избежать, если кэшировать объект из глобальной области видимости в локальную — все

Развертывание на сервере

Развертывание на сервере Для выполнения упражнений, предлагаемых в этой книге, необходимо иметь доступ к серверной части служб SharePoint 3.0, которая может быть установлена на одном или нескольких серверах. Сервер должен соответствовать следующим требованиям.1 Операционная

4. Кэширование.

4. Кэширование. Здесь сложнее. Об этом мне самому нужно почитать и полапать руками. Идея, как можно догадаться, в том, что если при обращении к умному указателю объект отсутствует в памяти, он считывается с диска. Проблемы самые очевидные в том, когда его снова отгружать на

12.14.4 Запись о сервере имен

12.14.4 Запись о сервере имен Запись о сервере имен (Name Server — NS) идентифицирует сервер для домена. Если имеются подзоны, необходимы и элементы для дочерних серверов имен подзон, чтобы сервер с более высоким уровнем мог использовать указатели на серверы низшего уровня. Записи

Кэширование

Кэширование В переводе с английского языка слово «cache» означает «тайник». Тайником в нашем случае является специальная системная папка, в которую компьютер записывает все документы, полученные из Интернета. И когда вы будете запрашивать какую-либо веб-страницу вторично,

Как зарегистрироваться на сервере

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

12.2.1. Samba на сервере

12.2.1. Samba на сервере Из п.6.3 вы узнали, как использовать пакет Samba (www.samba.org) для просмотра общих ресурсов сети Windows. В этом параграфе я объясню, как настроить сервер Samba, чтобы открыть общий доступ к ресурсам компьютера под управлением Linux.С помощью Samba вы сможете;? предоставлять

13.4.1. Настройка кэширования на DNS-сервере

13.4.1. Настройка кэширования на DNS-сервере Для того, чтобы насладиться такой возможностью, следует в блок options файла named.conf добавить следующие параметры:forward first;forwarders < 81.3.165.35; 81.3.150.2;>;Директива forwarders задает заключенный в фигурные скобки список IP-адресов DNS-серверов, которым

Память на сервере (все платформы)

Память на сервере (все платформы) Оценка памяти сервера включает множество факторов.* Работа сервера Firebird. Сервер Firebird осуществляет эффективное использование ресурсов сервера. Суперсервер (Superserver) после старта использует приблизительно 2 Мбайта памяти. Классический

ЧАСТЬ VII. Программирование на сервере.

ЧАСТЬ VII. Программирование на сервере.

7.5.4. Обработка на сервере

7.5.4. Обработка на сервере HTML-файлы могут обрабатываться прямо на сервере (так же, как выполняются файлы PHP). С одной стороны, это удобно, потому что код PHP можно будет вставлять в файлы с расширением htm, с другой стороны, HTML-файлы далеко небезопасны, и если хакер сможет их

9.6. Кэширование браузером

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

Кэширование в SVR4

Кэширование в SVR4 Центральной концепцией в архитектуре виртуальной памяти SVR4 является отображение файлов. При этом подходе все адресное пространство может быть представлено набором отображений различных файлов в память. Действительно, в страницы памяти, содержащие

Как ускорить загрузку сайта: Часть 6 — кэшированние страниц

Продолжение.
Начало поста Ускоряем сайт на WordPress читайте на этой странице.

13. Не происходит кэширования в браузерах пользователей:

Как происходит ускорение загрузки сайта при помощи кэширования в браузерах?
Все страницы одного сайта содержат похожие элементы, (шапка, сайтбар, фоновые картинки, футер).
Когда пользователь переходит на новую страницу, его браузер повторно загружает одни и те же элементы и на этот процесс уходит время. Если браузеры посетителей будут сохранять у себя в памяти эти повторявшиеся элементы (кешировать), то загрузка сайта будет происходить намного быстрее.
При кэшировании браузером, ускорение загрузки сайта происходит только при повторном его посещении. То есть при первом посещении в браузере пользователей происходит кэширование, а при повторном посещении загрузка основных элементов будет происходить не с сервера, а из кеша браузера.
Чтобы в браузерах посетителей происходило кэширование, нужно указать Web серверу, на котором хостится ваш сайт, чтобы он отдавал браузерам команды кешировать статические элементы сайта.
Сделать это мы можем при помощи инструмента удаленного управления Web сервером — файла .htaccess.
(Если вы не знаете, где находится файл .htaccess, прочитайте статью сначала).
Откройте файл .htaccess и добавьте в него приведенный ниже код.

# кеширование в браузере на стороне пользователя ExpiresActive On ExpiresDefault “access 7 days” ExpiresByType application/javascript “access plus 1 year” ExpiresByType text/javascript “access plus 1 year” ExpiresByType text/css “access plus 1 year” ExpiresByType text/html “access plus 7 day” ExpiresByType text/x-javascript “access 1 year” ExpiresByType image/gif “access plus 1 year” ExpiresByType image/jpeg “access plus 1 year” ExpiresByType image/png “access plus 1 year” ExpiresByType image/jpg “access plus 1 year” ExpiresByType image/x-icon “access 1 year” ExpiresByType application/x-shockwave-flash “access 1 year” # Cache-Control # 30 дней Header set Cache-Control “max-age=2592000, public” # 30 дней Header set Cache-Control “max-age=2592000, public” # 2 дня Header set Cache-Control “max-age=172800, public, must-revalidate” # 1 день Header set Cache-Control “max-age=172800, private, must-revalidate” # использование кеша браузеров FileETag MTime Size ExpiresActive on ExpiresDefault “access plus 1 year” #Запрет отдачи HTTP-заголовков Vary браузерам семейства MSIE BrowserMatch “MSIE” force-no-vary BrowserMatch “Mozilla/4.[0-9]<2>” force-no-vary

Код состоит из нескольких частей, каждая из которых работает с разными модулями сервера Apache, а последний вариант предназначен исключительно для браузера IE.
В любом из приведенных вариантов кода предусмотрена проверка на доступность нужного модуля на web сервере вашего хостинга и, только в случае его обнаружения, будет выполняться код. Т.е. никаких ошибок этот способ увеличения скорости загрузки сайта в работу вашего сайта вносить не должен.

Примечание: описанный способ будет работать только на Web серверах под управлением Apache, но это, как правило, 99 всех Web серверов.
После того, как вы внесли изменения в файл .htaccess и сохранили их, еще раз откройте в FireFox страницу вашего сайта и обновите данные, собранные Page Speed, нажав на кнопку «Refresh Analysis»
Красный маркер возле пункта «Используйте кэш браузера» должен смениться зеленой птичкой.
Если изменений в Page Speed не произощло, напишите вашему хостеру.
Возможно на вашем сервере статические обьекты кешируются по умолчанию, а Page Speed по какой то причине этого не видит.
В любом случае этот вопрос лучше обсудить с хостером.
Продолжение поста Ускоряем сайт на WordPress читайте дальше.

Как использовать кеш браузера пользователей для ускорения сайта (заголовки Last-Modified, ETag, Expires, Cache-Control)

Здравствуйте, уважаемые читатели блога Goldbusinessnet.com. Продолжаю цикл статей, которые касаются мероприятий по оптимизации, и сегодня настал черед для настройки использования в этих целях кэша браузера со стороны пользователей, что является очередным шагом выполнения рекомендаций Google Page Speed по ускорению сайта.

Каждое действие, позволяющее приблизиться к этой цели, будет плюсом в продвижении веб-ресурса, а потому не поленитесь хотя бы взглянуть на материалы, где я давал описания оптимизации картинок, объединения изображений в спрайты, а также сокращения CSS и скриптов, что, несомненно, вам поможет в реализации общей задачи.

Мастер Йода рекомендует:  Курс по Bootstrap 10 бесплатных уроков по основам

В продолжение я постараюсь предоставить внятные инструкции по настройке кэширования в браузере путем внедрения специального кода в замечательный файл .htaccess. Правда, это не всем и не всегда может помочь, но обо всем чуть ниже.

Рекомендация PageSpeed — используйте кэш браузера

Думаю, каждый из вас представляет себе, что такое кэширование, хотя бы в общих чертах. На всякий случай объясню вкратце. Допустим, читатель открывает в окне браузера страницу вашего ресурса, все составляющие которой (содержание, стили, скрипты и т.п.) загружаются с сервера хостинга, что занимает определенное время.

Предположим, у нас есть возможность запустить механизм, который позволит сохранить копии элементов страниц прямо в web-обозревателе того пользователя, который их посещает. Тогда при каждом следующем обращении все эти элементы будут браться прямо из кеша браузера (что это такое и как его очистить?) посетителя, то есть из специальной папки, которая располагается на жестком диске его компьютера.

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

Пару-тройку лет назад я рассказывал об оптимизации одного из своих проектов на основании анализа Пейдж Спид, осуществленного посредством расширения (сейчас доступен только онлайн сервис), которое давало более детальную картину.

Тогда после процедуры gzip сжатия файлов CSS, JS, HTML следующим по приоритету советом была как раз необходимость использования кэша браузера:

После того, как мне удалось включить кэширование в браузере пользователей, картина в окне Page Speed стала немного более привлекательной (проблема переместилась из желтой в зеленую зону), хотя и остались в списке некоторые элементы, подгружаемые со сторонних ресурсов (но повлиять на их оптимизацию нет возможности):

У моего теперешнего хостера кэширование включено, поэтому при анализе этого блога в упомянутом чуть выше online сервисе Pagespeed отразились опять же только внешние элементы, которые мне не подвластны (Граватар, контекстная реклама, Яндекс Метрика, Гугл Аналитикс):

Далее мы и разберем уже конкретные практические шаги, нужные для выполнения рекомендации «Используйте кеш браузера», чтобы исправить создавшееся положение. Надеюсь, они дадут вам возможность все же настроить кеширование в браузерах должным образом.

Настройка кеширования в браузере пользователей в целях увеличения скорости сайта

Помните, в начале поста я обмолвился, что предлагаемый вариант не являются стопроцентно универсальным и подойдет не всем? К сожалению, это так. Дело в том, что этот метод годится только для серверов, управляемых ПО Apache (коих, правда, подавляющее большинство).

Более того, описанные ниже телодвижения дадут результат только в том случае, ежели у вас работает Апач в чистом виде. Если используется связка Apache + nginx, то настраивать придется последний, и в этом случае владельцам сайтов на разделенном виртуальном хостинге без помощи не обойтись. Так что придется обратиться к хостеру (впрочем, тоже вариант).

Итак, производить настройку выдачи страниц из кеша мы будем путем указания специальных директив, которые прописываются в файле .htaccess, являющемся ничем иным как средством удаленного администрирования сервером, где расположен ваш проект.

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

Находится .htaccess обычно в корневой директории (папке public_html или htdocs) вашего сайта. Для начала проверьте его наличие, подсоединившись к удаленному серверу, где хостится ваш проект, посредством ФТП-соединения (тут у меня разобран по косточкам менеджер Файлзилла). Если вы файла .htaccess в корне не наблюдаете, то попробуйте из верхнего меню FileZilla выбрать «Сервер» — «Принудительно отображать скрытые файлы»:

Если и в этом случае он не появится (что, впрочем, маловероятно), примените замечательный редактор Нотепад плюс плюс и создайте в нем такой файл:

Далее необходимо, воспользовавшись все тем же Notepad++, вписать в .htaccess последующий ниже код, который содержит директивы для управления сайтом применительно к возможности кеширования его статических элементов в браузерах посетителей.

Начиная с этого места я решил немного углубиться в суть вопроса. Те, кто теоретически уже подкованы в достаточной мере, могут просто пропустить несколько последующих абзацев и сразу скопировать нужные коды, которые последуют ниже.

Если говорить конкретно, то посредством конфигурационного файла .htaccess мы должны дать команду браузерам пользователей при следующих посещениях ими сайта подгружать статические элементы страниц уже из папки кэша, расположенной на компьютере, а не напрямую с сервера, что и даст так нужный нам выигрыш в скорости загрузки.

В целях решения этой задачи нужно включить в ответ сервера соответствующие HTTP заголовки, в которых будет содержаться необходимая информация. Поговорим об этом подробнее.

Во-первых, необходимо обеспечить своевременное обновление веб-обозревателями кэшируемых объектов в интересах пользователей, которые будут получать в этом случае актуальный контент. Это можно сделать, используя заголовки Last-Modified и ETag (одновременно их оба нет нужды выводить, об этом недвусмысленно говорит сам Гугл).

На практике это означает, что при отправке браузером GET запроса (в данной статье вы найдете подробности о взаимодействии сервера и клиентских приложений) он получит HTTP ответ с кодом состояния 304 (без загрузки оттуда контента), если запрашиваемый ресурс не был изменен. Этот ответ означает, что можно загрузить контент из кеша.

И только в случае изменения содержание объекта будет отправлено для его отображения с сервера в составе ответа 200 (ОК). Подобная схема гарантирует максимальную экономию времени загрузки и одновременно актуальность отображаемой информации.

Во-вторых, нужно обязательно указать, на протяжении какого периода браузер должен хранить в кеше те или иные ресурсы. С этой целью можно использовать Expires либо Cache-Control с параметром max-age. Вывод этих заголовков инициируется с помощью модулей соответственно mod_expires и mod_headers, которые в том числе содержат названия объектов, к которым и будет применены правила хранения их в кеше.

Вопрос в том, какие из файлов и на какое время следует кешировать в том или ином случае. Главное, добиться взвешенного результата, заключающегося в том, чтобы максимально увеличить скорость сайта за счет кеширования при условии получения юзерами актуальной информации.

В первую очередь, это весьма распространенные статические объекты, подлежащие хранению в кеше (скрипты, файлы стилей CSS, изображения с расширениями .png, .jpg, .gif и другие).

Эти вводные, а также тот факт, что мы в качестве инструмента используем .htaccess, работающий на огромном множестве серверов Апач, позволит составить директиву, содержащую необходимый минимум правил, подходящий многим ресурсам, работающим на разных CMS.

Что важно, в большинстве своем предложенный ниже код вполне достаточен для того, чтобы создать условия, при которых Pagespeed больше не будет предъявлять претензий, а, значит, он обеспечит ускорение загрузки страниц в необходимом объеме.

Итак, на основании выше сказанного нам нужно обеспечить вывод одного из заголовков Last-Modified и ETag, а также одного из пары Expires либо Cache-Control: max-age. Для наглядности и расширения диапазона рассмотрим различные варианты.

Вариации кодов для управления кешем с использованием заголовков Last-Modified, Expires и Cache-Control

Если на вашем хостинге уже настроен вывод того же Last-Modified, то пол-дела сделано (к слову, проверить наличие этого важного заголовка можно с помощью онлайн сервисов, включая в их список инструмент для проверки ответа сервера от Яндекса). Если же нет, то сделать это весьма несложно, прописав в том же незаменимом .htaccess пару строк:

Правда, работать этот метод будет опять же при условии наличия «чистого Апача» (но ведь как раз этот случай мы и рассматриваем). Будем считать, что заголовок Last-Modified, в качестве значения которого, кстати, будет выводится дата последнего изменения, настроен.

Теперь настала очередь Cache-Control с параметром max-age, в качестве значения которого будет прописан срок хранения в кеше каждого конкретного статического объекта. На сцену выходит модуль mod headers, код которого и следует вставить в .htaccess:

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

Время сохранения кеша определяется с помощью параметра max-age, его значение выставляется в секундах. Благодаря комментариям (которые, к слову, вы можете спокойно удалить), стоящим после символа решетки «#», основа этой конструкции, думаю, понятна.

Однако, вместо mod headers вполне можно воспользоваться модулем mod expires, выводящим заголовок Expires (который, по мнению самого Гугла является предпочтительнее, поскольку имеет более широкую поддержку). При этом фрагмент кода для его включения будет таким:

Точкой отсчета срока годности кэша в случае использования заголовка Expires является дата первой загрузки. Причем, в отличие от Cache-Control, где временной период определяется только в секундах, здесь он может указываться в любом временном формате, включая year (год).

Для того, чтобы убедиться в этом, посмотрите на участок кода, касающийся изображений. Там я специально указал время в различных единицах исчисления: 1 month (месяц), 4 weeks (недели), 30 days (дни), 43829 minutes (минуты), 2592000 seconds (секунды).

Понятно, что в месяце и в году может быть различное количество дней, недель, минут и секунд, но это не принципиально, поскольку используются средние значения. Кстати, для JS, файлов CSS и изображений рекомендуется ставить временной период не менее недели, но не более года. При этом по факту в качестве значения заголовка Expires в ответе сервера будет указана дата предполагаемого срока завершения периода кеширования данной версии объекта.

В дополнение к упомянутым модулям полезно задействовать еще и mod setenvif. Дело в том, что веб-обозреватели семейства Microsoft Internet Explorer и некоторые версии Мазилы корректно не воспринимают в ответе сервера HTTP заголовок Vary, который также вносит свою важную лепту в управление кэшированием. Этот модуль как раз позволяет решить эту проблему, исключая Vary из состава ответа сервера:

В итоге мы получаем два конечных варианта настройки кеширования, которые вы можете проверить, вставив поочередно в .htaccess (оба одновременно использовать не рекомендую):

Еще раз напоминаю, что несмотря на наличие контейнера IfModule, который обеспечивает безопасность редактирования, не лишним будет каждый раз при изменении .htaccess делать резервную копию исходного варианта файла (можно просто скопировать его содержание и сохранить на компьютере), чтобы вас не застиг врасплох форс-мажор в той или иной вариации.

Код формирования заголовков Etag и Expires для настройки кэша

На случай, ежели предложенные выше директивы вдруг не сработают (даже если на вашем хостинге установлен «чистый» Апач), разберем другой случай, а именно, когда в качестве инструментов управления кэшированием выступает пара входящих в разряд обязательных заголовков Etag и Expires. Как вы помните, оба отвечает за своевременность выдачи файлов из кеша, инициируя проверку на актуальность текущей версии.

Но если в качестве значения Expires отображается дата последнего изменения, то в ETag используется тот или иной уникальный идентификатор ресурса (чаще в этой роли выступает версия файла). Для активации ETag требуется лишь ввести в тот же .htaccess одну строчку:

Ну а затем применить уже известный нам модуль mod expires. Можно добавить и mod setenvif, который, как я уже сказал выше, запрещает формирование заголовков Vary для определенной группы веб-браузеров, чтобы гарантировать образование кеша с их стороны:

Здесь использован комплекс с минимумом типов задействованных объектов, но зато наиболее востребованных (CSS, JavaScript и изображения), который также должен быть достаточным, чтобы обеспечить максимальную эффективность в ускорении сайта. При желании к комплекту «jpg|jpeg|gif|png|ico|css|js» можно добавить другие виды файлов.

Кроме того, в приведенном выше примере кода для всех файлов действует один и тот же период «жизни» кеша, равный одному году («access plus 1 year»), который является рекомендуемым со стороны Гугла. Но можно для каждой группы объектов указать свой временной отрезок по примеру содержания модулей mod_expires и mod_headers из предыдущего раздела статьи.

Проверка наличия нужных заголовков в ответе сервера

После того, как вы вставите код в файл .htaccess, можно проверить, находятся ли необходимые заголовки в составе ответа сервера. Для этой цели можно воспользоваться каким-нибудь онлайн сервисом, например, Checkmy.ru, где в качестве клиента (User Agent), посылающего HTTP-запрос на сервер, выбираем любой браузер, а также вводим URL ресурса (для примера я взял путь до изображения, используемого в одной из статей блога):

После нажатия кнопки «Отправить запрос», через несколько секунд появится результат:

Как видите, в моем случае присутствуют все четыре заголовка. Я говорил, что обязательно должны выводится по одному из пар «Last-Modified — ETag» и «Expires — Cache-Control», остальные излишни. При этом полный комплект, насколько можно судить, не причинит вреда.

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

Ведь если в ответе сервера будет присутствовать nginx, то настраивать нужно будет именно его (у меня это сделал провайдер), а файл конфигурации .htaccess будет здесь бесполезен. В таком случае, как я уже отмечал, придется задействовать помощь службы поддержки, если, конечно, ваш тариф хостинга и недостаточные знания не позволят самостоятельно решить вопрос.

Далее советую для закрепления материала обратиться к видео и посмотреть последовательно 6 уроков (один из которых посвящен настройке кеширования в браузерах), в которых подробно рассмотрены все наиболее важные аспекты ускорения сайта WP:

Кэшируем свой сайт

Частная коллекция качественных материалов для тех, кто делает сайты

  • Фотошоп-мастер2000+ уроков по фотошопу
  • Фото-монстр300+ уроков для фотографов
  • Видео-смайл200+ уроков по видеообработке
  • Жизнь в стиле «Кайдзен» Техники и приемы для гармоничной и сбалансированной жизни

В этом разделе помещены уроки по PHP скриптам, которые Вы сможете использовать на своих ресурсах.

Фильтрация данных с помощью zend-filter

Когда речь идёт о безопасности веб-сайта, то фраза «фильтруйте всё, экранируйте всё» всегда будет актуальна. Сегодня поговорим о фильтрации данных.

Мастер Йода рекомендует:  STL стандартная библиотека шаблонов С++

Контекстное экранирование с помощью zend-escaper

Обеспечение безопасности веб-сайта — это не только защита от SQL инъекций, но и протекция от межсайтового скриптинга (XSS), межсайтовой подделки запросов (CSRF) и от других видов атак. В частности, вам нужно очень осторожно подходить к формированию HTML, CSS и JavaScript кода.

Подключение Zend модулей к Expressive

Expressive 2 поддерживает возможность подключения других ZF компонент по специальной схеме. Не всем нравится данное решение. В этой статье мы расскажем как улучшили процесс подключение нескольких модулей.

Совет: отправка информации в Google Analytics через API

Предположим, что вам необходимо отправить какую-то информацию в Google Analytics из серверного скрипта. Как это сделать. Ответ в этой заметке.

Подборка PHP песочниц

Подборка из нескольких видов PHP песочниц. На некоторых вы в режиме online сможете потестить свой код, но есть так же решения, которые можно внедрить на свой сайт.

Совет: активация отображения всех ошибок в PHP

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

Агент

PHP парсер юзер агента с поддержкой Laravel, работающий на базе библиотеки Mobile Detect.

HTTP-кеширование


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

Проблема не обязательно в том, что эти ресурсы велики или что они неоптимизированы, а в том, что многим веб-приложениям нужно извлекать их при каждом обновлении страницы. Если бы пользователи могли тратить меньше времени на загрузку вашего великолепного изображения героя Unsplash и больше времени на рендеринг HTML и анализ JavaScript, они бы столкнулись с более быстрым приложением.

К счастью, HTTP предлагает мощное решение: кэширование . В этом посте объясняется, как HTTP может дать указание браузерам повторно использовать дорогие ресурсы, экономя пропускную способность и время. Мы начнем с обзора концепций кэширования, а затем опишем, как эволюционировал механизм кэширования HTTP между HTTP / 1.0 и HTTP / 1.1.

Основы кэширования

В своей простейшей форме кеш просто позволяет системе удерживать ресурс, если он знает, что указанный ресурс вряд ли изменится в течение определенного периода времени. До истечения этого периода времени ресурс считается свежим , а после этого считается устаревшим . Эти два термина имеют ключевое значение для понимания кэширования.

Идеальный кеш позволил бы клиенту, такому как браузер, как можно дольше удерживать ресурс, прежде чем выбросить его для более новой версии, когда это необходимо. Легко сказать, но это одна из «двух сложных проблем» в информатике.

Для того чтобы кэш функционировал, вам нужен способ указать, как долго ресурс будет свежим, что является невыполнимой задачей для сервера, поскольку он не может с абсолютной уверенностью предсказать, когда (если вообще когда-либо) будет обновлен ресурс. Этими знаниями обладаете только вы, как разработчик.

Как это сделать? HTTP предлагает два основных средства, первое из которых мы сейчас рассмотрим.

Expires и истоки кеширования HTTP

Expires был введен в HTTP / 1.0 , и, вместе с Pragma , Last-Modified и If-Modified-Since , первую систему кэширования , состоящей протокола HTTP. Это самый простой из имеющихся в вашем распоряжении заголовков кэширования HTTP, указывающий дату, когда данный ресурс устареет:

По истечении указанного срока Expires браузер попытается повторно получить указанный ресурс. До этого браузер может свободно удерживать ресурс и использовать его по своему усмотрению.

Повторная проверка с Last-Modified и If-Modified-Since

Помните, как мы упоминали, что идеальный кеш будет загружать новый ресурс только тогда, когда он будет уверен на 100%? Один из способов добиться этого — позволить браузерам опрашивать серверы в зависимости от того, действительно ли такой ресурс доступен. Но как браузер может указать, какая версия ресурса у него в настоящее время?

Введите If-Modified-Since. Расширяя наш пример выше, представьте, что браузер хотел получить image.jpeg 15 апреля, на следующий день после даты, указанной в Expires заголовке. Вы заметите, что приведенный выше фрагмент кода содержит Last-Modified заголовок, который указывает, когда сервер в последний раз полагал, что изображение было обновлено.

Учитывая, что браузер уже имеет image.jpeg в своем кэше, он может сообщить серверу, что у него уже есть копия изображения, которое было изменено в последний раз 12 апреля:

Если изображение изменилось, сервер просто ответит полным ответом, содержащим новое изображение. В противном случае он может ответить 304 Not Modified :

После получения такого ответа браузер может выпустить свою кэшированную копию. Этот результат является выигрышным как для сервера, так и для клиента: сервер гарантирует, что используется самая последняя версия ресурса, и клиенту не нужно повторно загружать образ.

cache-control и эволюция HTTP-кеширования

Ограничения Expires привели к появлению cache-control в HTTP/1.1, что значительно увеличило гибкость, с которой разработчики могли кэшировать ресурсы. Вместо того, чтобы строго полагаться на даты, cache-control принимает ряд директив, пару из которых мы обсудим сейчас, а остальные сворачиваются в дискуссии о повторной проверке, безопасности и многом другом.

Директива max-age

Думайте о max-age директиве как о более простой альтернативе Expires . Если вы хотите указать, что ресурс истекает в течение одного дня, вы можете ответить следующим заголовком cache-control :

Обратите внимание, что max-age относится ко времени запроса, поэтому таймер начинает отсчитывать время, когда ресурс входит в кеш. Вы можете спросить: «Зачем переходить на секунды по датам?»

У Марка Ноттингема есть хорошее объяснение , и он подчеркивает простоту, работы с max-age . Учтите следующее:

Мало того, что может быть трудно сопоставить дату Expires с вашим местным часовым поясом, многие реализации сервера просто испортили формат даты, что привело к путанице. max-age будучи простым целым числом, представляющим секунды с момента генерации ответа, гораздо проще использовать.

Самая длинная продолжительность, которую может поддерживать директива max-age , составляет год, который удовлетворяет большинству вариантов использования. Но если вы сообщаете браузеру, что определенный ресурс никогда не изменится, вы также можете использовать более новую директиву immutable , которая выполняет именно это. Имейте в виду, что его применение не является полностью совместимым в разных браузерах, поэтому стоит добавить ее вместе с ним max-age .

Повторная проверка с Etag и If-None-Match

HTTP / 1.1 также представил новую стратегию переаттестации для дополнения If-Modified-Since , сосредоточенную вокруг того, что называют «тегами сущностей».

Вы можете рассматривать теги сущностей как способ, с помощью которого серверы могут однозначно идентифицировать версию ресурса с помощью буквенно-цифрового идентификатора, указанного в заголовке ответа ETag :

Если клиент хочет сообщить серверу, что у него есть конкретная версия ресурса, он предоставляет заголовок запроса If-None-Match при следующем запросе ресурса:

Если последняя версия ресурса не соответствует тегу сущности «abc», сервер ответит новой версией. В противном случае он ответит 304 Not Modified .

Как вы, наверное, догадались, «abc» — это слишком простой идентификатор, который можно использовать для ресурса. Как бы вы гарантировали, что определенный тег сущности соответствует одной версии ресурса, а не другой?

Именно эта конкретная проблема приводит к тому, что популярные хранилища, такие как S3, используют алгоритмы хеширования, например, md5 для создания тегов сущностей. Используя теги сущностей, привязанные к фактическому дайджесту байтов, составляющих ресурсы, вы получаете идентификатор, уникальный для этого файла.

Вы можете указать директиву must-revalidate внутри cache-control чтобы информировать клиентов о том, что они должны использовать механизм проверки, будь то теги сущностей или If-Modified-Since , прежде чем выпускать устаревшую копию ресурса из кэша (в случае, если сервер недоступен).

Обеспечение конфиденциальности кэша с помощью private и public

До этого момента мы фокусировались на кеше, который существует в вашем браузере, который кэширует ресурсы по мере их загрузки. Но реальность такова, что ресурсы часто проходят через один или несколько промежуточных или «общих» кэшей, прежде чем они попадают в ваш браузер. Это могут быть кеши, используемые вашим интернет-провайдером или корпоративным ИТ-отделом.

До того, как HTTPS получил широкое распространение, многие промежуточные кэши стали использовать ресурсы в случае, если другой пользователь может найти это полезным. Не нужно много воображения, чтобы увидеть, это может быть не так.

Чтобы смягчить это, в HTTP / 1.1 были введены директивы public и private в cache-control , которые, хотя и несовершенны, позволяют указывать такие общие кэши, если вы не хотели, чтобы они хранили копию ресурса.

Эти директивы все еще полезны. Если вы используете компьютер с несколькими людьми, а ваш браузер совместно использует кеш между ними, существует вероятность, что он может поделиться с ними загруженными ресурсами. Если ресурс указывает директиву private , то браузер должен сделать все возможное, чтобы гарантировать, что только вы, пользователь, который его загрузил, может использовать его повторно.

Подавление кэширования с помощью no-cache и no-store

HTTP / 1.1 исправил недостаточность заголовка Pragma в HTTP / 1.0 и предоставил веб-разработчикам средства, с помощью которых можно полностью отключить кэширование.

Первая директива, no-cache заставляет кеш повторно проверять ресурс перед повторным использованием. В отличие от этого must-revalidate , no-cache означает, что браузер значительно обновляется во всех случаях, а не только тогда, когда ресурс устарел.

Вторая директива, no-store это молоток: она сигнализирует, что ресурс ни в коем случае не должен входить в кеш.

Указание специфичных для запроса ограничений кэширования

Что если в качестве клиента вы захотите запросить ресурс, который будет обновлен хотя бы в течение определенного периода времени? Хорошая новость заключается в том, что cache-control это не только инструмент для серверов, задающий ограничения кэширования для клиентов, но и доступный для клиентов, чтобы они могли получить ресурс, который соответствует определенным требованиям к кэшированию.

Директивы max-age , no-cache и no-store все они могут быть использованы в запросах клиента. Их значение имеет тенденцию быть обратным тому, что это означает для клиента; например, указание заголовка max-age в запросе говорит любым промежуточным серверам, что они не могут использовать кэшированные ответы старше, чем продолжительность, указанная в директиве.

В дополнение к указанным выше директивам, в cache-control в вашем распоряжении четыре директивы только для запроса.

min-fresh — позволяет клиентам запрашивать ресурсы, которые будут обновлены, по крайней мере, в течение определенного периода в секундах:

Директива max-stale сообщает любым промежуточным серверам кэша, что клиент готов принять несвежий ответ , который не был несвежим больше , чем определенный период времени в секундах:

Директива no-transform говорит промежуточным серверам, что клиент не хочет какой — либо версии ресурса, указанного кэша , возможно, изменен. Это применимо в случаях, когда кэш, такой как Cloudflare, мог применять сжатие gzip .

И, наконец, директива only-if-cached сообщает промежуточным кэшам, что клиент хочет получить только кэшированный ответ, и что в противном случае ему не следует связываться с сервером для получения свежей копии. Если кеш не может удовлетворить запрос, он должен вернуть ответ 504 Gateway Timeout .

Vary и согласованные с сервером ответы

Наша последняя тема посвящена тому, как браузеры на самом деле идентифицируют ресурсы, и как согласование сервера влияет на ситуацию.

На высоком уровне кэш браузера действительно просто смотрит на URL и метод, хотя практически все кешируемые запросы являются запросами GET, практическая реальность такова, что URL, как правило, достаточно, чтобы браузеры идентифицировали ресурсы.

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

Для этого кэши обращают пристальное внимание на то, какие заголовки сервер использует для согласования соответствующего ответа, который передается клиенту через заголовок Vary . Например, представьте, что мы сделали следующий запрос на изображение:

Заголовок Accept-Encoding указывает на то, что серверу разрешается возвращать ресурс с gzip версией, если он способен делать это. Если сервер принимает этот заголовок во внимание при решении, какой ответ отправить нам, он перечислит его в заголовке Vary , добавленном к его ответу:

Конечным результатом этого должно быть то, что кеш должен использовать не только значение URL для кеширования ответа, но и что он должен также использовать значение заголовка запроса Accept-Encoding для дальнейшей квалификации ключа кеша. Таким образом, если бы другой запрос был сделан с другим значением для Accept-Encoding заголовка, например deflate , его ответ не заменил бы указанный запрос gzip .

Заключение

Кэширование — это удивительно мощный способ повысить производительность вашего приложения, и я рекомендую углубиться в полное руководство MDN по управлению кэшем, если вы хотите изучить его многочисленные закоулки. Я надеюсь, что этот пост дал вам повод для беспокойства по поводу HTTP-кэширования, и если вы заметили ошибку в этом посте, будь то фактическая или синтаксическая, дайте мне знать в комментариях ниже!

Веб-кэширование страниц на примере покупки молока в магазине

Дата публикации: 2020-07-16

От автора: если вы когда-либо покупали молоко в супермаркете, вы можете понять кеширование веб страниц на стороне сервера и на стороне браузера. Если вы являетесь активным пользователем Интернета (вероятно, так и есть), вы много раз использовали кеширование. Но, возможно, вы не знаете, когда и как оно работает своей магией за кулисами.

С точки зрения разработчика, кеширование упрощает создание высокопроизводительных веб-приложений и веб-серверов. Вместо того, чтобы постоянно оптимизировать серверы, которые перегружены тысячами запросов, разработчики могут внедрять протоколы кэширования, чтобы сделать жизнь намного проще.

Поскольку кеширование может сделать разницу между 1 секундой, чтобы загрузить страницу и 2 секунды, воздействие может ощущаться немного … недоумение. Но это необходимо, если вы хотите обрабатывать большой объем пользователей.

После использования кеширования в прошлом веб-приложении я понял, что должен быть лучший способ объяснить это, чем просто пройти через терминологию. Я заметил, что он очень хорошо выровнялся по пути молока с фермы к вашему холодильнику, поэтому я подумал, что это лучший способ объяснить это.

Мастер Йода рекомендует:  Levi's и Google выпустили в продажу «умную» куртку

Чтобы понять это руководство, вам просто нужно знать об основах веб-серверов. Приступим!

Как создать сайт самому?

Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

Как бы выглядел Интернет без кеширования?

Прежде чем мы займемся кэшированием, давайте подумаем о том, как будет выглядеть Интернет без кеширования. Представьте себе на мгновение, что вы живете в 1700-х или 1800-х годах в сельской местности. У вас есть ферма, и нет холодильника. У вас есть несколько коров на вашей ферме, но их молоко не так ценно, так как оно быстро испортится.

Быстрое прерывание: некоторые культуры до сих пор не имеют доступа к холодильной технике. Они либо будут пить сырое молоко непосредственно из вымени коров, либо смешать молоко с зернами и дать ему бродить. Интересно.

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

Кроме того, вы даже не можете думать о добавлении коров и расширении своей операции, так как у вас есть такое ограниченное распространение. Только другие члены вашей деревни могут купить ваше молоко. У вас есть определенные пределы.

Без кэширования вы ограничены вычислительной мощностью ваших серверов. Кэширование используется для загрузки статических активов, например:

Статические файлы HTML

Сервер по умолчанию должен отправить новый ответ для каждого входящего запроса. Но запрос на загрузку страницы может фактически означать 4 отдельных запроса — по одному от каждой из вышеперечисленных категорий. Когда вы принимаете во внимание большие файлы изображений, ваши серверы могут стать перегруженными пользователями по всему миру. Затем пользователи будут испытывать медленное время загрузки, так как они ждут загрузки своей страницы.

В идеале вы хотели бы уменьшить спрос на своих серверах, сохранив ответы на общие запросы. Вашему серверу не нужно будет обрабатывать каждый новый индивидуальный запрос, но вместо этого ваш кеш может доставить немедленный ответ. Вы всегда можете заплатить за большее количество серверов, но это может привести к неконтролируемым расходам.

Что такое кеширование на стороне сервера?

Вернемся к сценарию нашей фермы. Знаете, что облегчит работу успешной молочной фермы? Супермаркет с холодильником!

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

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

Как и в супермаркете, кеш-сервер будет обрабатывать популярные запросы и доставлять контент намного быстрее и надежнее.

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

У вас, вероятно, есть куча вопросов вроде:

Как создать сайт самому?

Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

Что определяет «популярный» запрос?

Как долго прокси кэширует ответы?

Для этого потребуется более подробное руководство по настройке кеширования, но пока вы должны знать об одной важной концепции, называемой свежестью. Прокси-сервер кэширования будет иметь разные файлы, которые были кэшированы в разное время, и ему нужно решить, должен ли он еще обслуживать эти файлы. Это будет зависеть от вашей политики кэширования.

Это также работает так же, как молоко в супермаркете. Менеджер супермаркета должен решить, как долго они будут держать ваше молоко, прежде чем выбросить его. Кэширующие прокси измеряют их успех с помощью коэффициента попадания в кеш — процент содержимого, который может быть подан через сервер кеширования.

Что такое CDN?

До сих пор есть один продуктовый магазин, продающий ваше молоко. Хотя это большое улучшение, вы по-прежнему не можете получить свое молоко людям за пределами этого местного магазина. Вам нужно будет добавить больше магазинов, если вы хотите увеличить свою работу.

Итак, скажем, вы начинаете раздавать свое молоко в больше супермаркетов. Теперь вы можете удовлетворить клиентов в гораздо большем географическом диапазоне. Это похоже на сеть доставки контента или CDN. CDN — это серия прокси-серверов (как мы обсуждали выше), расположенных по всему миру.

Как конечный пользователь, вы, вероятно, чувствуете, что высокоскоростной интернет позволяет большинству сайтов загружаться очень быстро. Однако это происходит только потому, что они используют CDN для доставки статических файлов с высокой скоростью!

Если вы находитесь в Англии, и вы пытаетесь загрузить файл, кэшированный на сервере в Вирджинии, вы будете испытывать некоторую задержку, так как исходный сигнал может путешествовать так быстро по тысячам километров кабеля. Локальный прокси-сервер кэширования в Великобритании позволит загружать сайт быстрее.

Таким образом, ваши серверы могут отправлять копию статических активов на каждый из этих прокси-серверов в вашей сети CDN, и они могут обрабатывать локальные запросы до тех пор, пока активы перестанут быть «свежими». Некоторые распространенные поставщики CDN включают Rackspace, Akamai и Amazon Web Services.

Как насчет кеширования браузера?

Теперь люди по всей стране (или миру) могут принести домой холодное молоко с вашей фермы. Есть только одна проблема — у них нет способа хранить ее в своих домах. Вашим клиентам все еще нужно выпить молоко довольно быстро после того, как они его купят, а затем вернуться в продуктовый магазин для большего. Таким образом, эта система по-прежнему не обслуживает клиентов особенно хорошо.

С холодильником вы можете хранить молоко на месте и избегать поездки в супермаркет. В терминах кеширования мы говорим о совершенно другом месте для хранения статических активов, поскольку оно находится на стороне клиента или на том же компьютере, что и браузер. Наш прокси-сервер находился в удаленном месте.

Это отлично подходит для сайтов, таких как Facebook или Amazon, которые вы часто посещаете. Это также отлично подходит для их серверных расходов, поскольку они могут сократить количество запросов, которые им нужно обрабатывать.

Одна из ключевых замечаний — мы НЕ говорим, что молоко волшебным образом приходит в ваш холодильник! Вы все равно должны сделать этот первоначальный запрос, который достигает либо сервера, либо прокси-сервера. После этого вы можете кэшировать некоторые файлы локально.

Как ваш браузер знает, когда запрашивать новые файлы с сервера? В противном случае вы никогда не испытаете обновленные версии этих локальных файлов.

Ну, точно так же, как производители молока поставили дату на упаковке своего молока, серверы добавят какой-то идентификатор в заголовок ответа HTTP. На самом деле существует 4 отдельных системы кэширования HTTP. Вышеупомянутый сценарий очень похож на метод «срок годности». Некоторые другие методы по-прежнему требуют, чтобы ваш браузер проверял сервер перед отправкой кэшированного файла.

Когда начать использовать кеширование

Предположим, что вы создаете свое первое веб-приложение. Пока у вас нет тысяч пользователей, вам, вероятно, не нужно будет беспокоиться о кешировании протоколов, поскольку стоимость сервера по-прежнему будет низкой. Однако при масштабировании вам нужно будет реализовать кэширование, если вы хотите, чтобы приложение быстро загружалось.

Например, Heroku — отличный инструмент для развертывания вашего первого веб-приложения. Но для этого требуется использовать отдельный сервис для реализации кэширования, например CloudFront от Amazon или CloudFlare. Это займет больше времени, чтобы учиться.

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

Обычно это связано с некоторым протоколом кэширования на стороне браузера. Чтобы обойти кеш браузера и запрашивать новые ресурсы с сервера, вы можете использовать Cmd + Shift + R на Mac или Ctrl + Shift + R на ПК.

Автор: Kevin Kononenko

Редакция: Команда webformyself.

Как создать сайт самому?

Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

Настройка сжатия и кэширования через .htaccess

Включить кэширование .htaccess для статических файлов возможно на виртуальном хостинге Linux в Plesk и cPanel. Чтобы управлять настройками кэширования, используйте модуль expires. Как настроить кэширование в ISPmanager?

Mod_expires — модуль, подсказывающий вашему браузеру, какие статические файлы нужно кэшировать. Время хранения данных в кэше можно устанавливать в следующих значениях:

Настройка кэширования:

Настройка expires: 1. Для настройки кэширования сайта .htaccess файл должен находиться в корневой директории вашего сайта. Если у вас нет этого файла воспользуйтесь справкой: У меня нет файла .htaccess, что делать?.

Добавьте в файл .htaccess строки следующего вида:

Настройка сжатия

На серверах виртуального хостинга сжатие .htaccess для статических файлов включено по умолчанию. Статические файлы обрабатываются веб-сервером Nginx, доступа к настройке которого нет.

Проверить наличие сжатия можно при помощи ресурса.

Если вам критична настройка сжатия, рекомендуем приобрести VPS сервер.

Не работает кэширование .htaccess

Если после указанных настроек кэширование .htaccess не работает или у вас возникли сложности, обратитесь в техническую поддержку.

Виртуализация KVM, почасовая оплата, резервные копии, готовые шаблоны, 10 доступных ОС на выбор!

Кэшируем свой сайт

Не знаю где клиент этого начитался но настаивает на включении кеширования для сайта. Сайт действительно тяжелой, так как есть много картинок которые просто нет возможности уменьшит. Пока посещалка чуть более 1к и все летает, но планируется ее увеличить до 3-5к и возможно клиент прав и сайт начнет тормозить и без кеширования просто не обойтись.

Сайт WP на не сложном хостинге с ISP. Насколько я знаю кеширование в ISP включается в вкладке «WWW домены» и тд. Но какой там стоит ставить уровень сжатия? и период дней часов и тд. Достаточно ли будет этих действий или придется еще где с бубном ходить?

Инфы в ПС по этому делу много, но в основном она уже не актуальна или просто вода. Так что буду всем очень благодарен за советы.

И какие подводные камни стоит ожидать от включения подобного кешировани?

Не знаю где клиент этого начитался но настаивает на включении кеширования для сайта. Сайт действительно тяжелой, так как есть много картинок которые просто нет возможности уменьшит. Пока посещалка чуть более 1к и все летает, но планируется ее увеличить до 3-5к и возможно клиент прав и сайт начнет тормозить и без кеширования просто не обойтись.

Сайт WP на не сложном хостинге с ISP. Насколько я знаю кеширование в ISP включается в вкладке «WWW домены» и тд. Но какой там стоит ставить уровень сжатия? и период дней часов и тд. Достаточно ли будет этих действий или придется еще где с бубном ходить?

Инфы в ПС по этому делу много, но в основном она уже не актуальна или просто вода. Так что буду всем очень благодарен за советы.

И какие подводные камни стоит ожидать от включения подобного кешировани?

Кеширование еще настраивается плагинами в WP
W3Total Cache
WP Fast cache
попробуйте поставить , настроить

Хуже это не сделает точно, только лучше , загрузка страницы улучшится

Запрет кэширования страницы на HTML, PHP, htaccess

Порой, бывает необходимо запрещать браузеру кэшировать страницу, так как информация на ней обновляется каждый раз. Это может быть генерация данных, соответственно выбранным фильтрам или другой контент, который каждый раз создается по-новому. Одним словом, бывают моменты, когда необходимо запретить коварной программе кэшировать страницу. Сегодня, мы узнаем, как реализовать это разными способами, с помощью PHP или HTML или .htaccess.

Запрет кэширования страницы на HTML

Сделать это можно с помощью мета тегов. Сейчас мы разберем разные варианты запрета на кэширование.

Запрет на кэширование браузером и прокси-сервером

Запрет кэширования страницы, только браузером

Установка кэширования на определенное время, для браузера

С помощью кода ниже, мы можем сообщить браузеру, сколько хранить документ в кэше. После чего, кэш будет обновлен.

Установка кэширования на определенное время, для прокси-сервера

Практически, то же самое, что и в предыдущем коде, только указание стоит конкретно для прокси-сервера.

Запретить кэширование страницы с помощью PHP

Практически, все тоже самое, что в случае с HTML, только информацию будем выводить через header заголовки. Вот, как реализовать абсолютный запрет на кэш:

Также, можно разрешать кэшировать на определенное время. Например, разрешим кэширование только на 1 час.

Запретить кэширование страницы с помощью .htaccess

Для простоты реализации идеи, можно все сделать на уровне конфигураций сервера Apache. Перед этим, нам нужно убедиться в том, что необходимые модули находятся в рабочем состоянии. Открываем конфигурационный файл Apache и наблюдаем следующую картину:

Теперь в файле .htaccess, собственно запрещаем кэшировать выводимые данные. Как нам известно, .htaccess файл будет распространяться на директорию, в которой лежит, и на все субдиректории.

Важно заметить, что полный запрет кэширования, повышает нагрузку на сервер. Поэтому, играйтесь с этим осторожно! А лучше, установите определенное время, на которое можно кэшировать документы. Например, установим кэширование на 1 час:

Заключение

Это все известные для меня способы запрета на кэш. Если знаете что-то новенькое, просьба поделиться в комментариях. Надеюсь, статья была полезной, если это так, вас не затруднит поставить +1 и поделиться ею в социальных сетях.

Добавить комментарий
26.10.2020, 23:25 #2