Используйте кэш браузера для следующих ресурсов wordpress – Настраиваем кеш браузера для Google Page Speed

Содержание

WordPress Super Cache — используем кеш браузера для ускорения сайта.

Зачем использовать кэш браузера?

Кэширование важно для оптимизации веб-сайта, созданного на WordPress, поскольку оно увеличивает скорость загрузки страниц. Посетителям сайта не понравится его долгая загрузка, в результате чего они могут просто покинуть ваш сайт, не дождавшись информации, тем самым увеличивая количество отказов. Такие поведенческие параметры плохо отражаются на ранжировании сайта поисковыми системами, которые понижают его позиции в поисковой выдаче. Чтобы этого не произошло, подключите плагин WordPress Super Cache, который автоматически выполнит работу по кэшированию страниц.

Описание и возможности плагина

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

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

Что еще умеет делать WordPress Super Cache плагин:

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

www.ipipe.ru

включить кэш браузера, включить сжатие

Гугл плохого не посоветует — с помощью утилиты PageSpeed Insights от Google можно не только оценить скорость загрузки вашего сайта, но и получить конкретные рекомендации по устранению недостатков.

Проверим это на практике — запускаем тест от Google:

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

 

Делаем резервную копию файла .htaccess для WordPress и прописываем в него следующие строки:

  • для использования кэша браузера:
# Включаем кэш в браузерах посетителей
<ifModule mod_headers.c>
# Все html и htm файлы будут храниться в кэше браузера один день
<FilesMatch "\.(html|htm)$">
Header set Cache-Control "max-age=43200"
</FilesMatch>
# Все css, javascript и текстовые файлы будут храниться в кэше браузера одну неделю
<FilesMatch "\.(js|css|txt)$">
Header set Cache-Control "max-age=604800"
</FilesMatch>
# Все флэш файлы и изображения будут храниться в кэше браузера один месяц
<FilesMatch "\.(flv|swf|ico|gif|jpg|jpeg|png)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>
# Отключаем кеширование php и других служебных файлов
<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
Header unset Cache-Control
</FilesMatch>
</IfModule>

# Включаем кэш в браузерах посетителей <ifModule mod_headers.c> # Все html и htm файлы будут храниться в кэше браузера один день <FilesMatch «\.(html|htm)$»> Header set Cache-Control «max-age=43200″ </FilesMatch> # Все css, javascript и текстовые файлы будут храниться в кэше браузера одну неделю <FilesMatch «\.(js|css|txt)$»> Header set Cache-Control «max-age=604800″ </FilesMatch> # Все флэш файлы и изображения будут храниться в кэше браузера один месяц <FilesMatch «\.(flv|swf|ico|gif|jpg|jpeg|png)$»> Header set Cache-Control «max-age=2592000″ </FilesMatch> # Отключаем кеширование php и других служебных файлов <FilesMatch «\.(pl|php|cgi|spl|scgi|fcgi)$»> Header unset Cache-Control </FilesMatch> </IfModule>

  • для включения сжатия:
# сжатие text, html, javascript, css, xml:
<ifModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/css text/javascript application/javascript application/x-javascript
</ifModule>

# сжатие text, html, javascript, css, xml: <ifModule mod_deflate.c> AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/css text/javascript application/javascript application/x-javascript </ifModule>


В результате имеем:
 
 
Буквально за несколько минут мы подняли рейтинг нашего сайта в глазах Google на 10 баллов.

P.S. У меня несколько хостингов и везде данный прием работал. Но попробовав на beget.ru я не увидел увеличения скорости загрузки (и прирост баллов).

Пичалька скажете вы, а вот и нет — хостинг Бегет решает данные проблемы на стороне сервера (то есть на своей стороне) и вам нет необходимости править файл .htaccess.
Так что я могу со спокойной душой рекомендовать недорогой хостинг beget.ru для ваших сайтов.

Кстати, все его сервера, даже начального уровня, работают на SSD-дисках.

Удачи вам и профита.

siteask.ru

Как сделать кэширование в браузере для wordpress сайта ? – info-effect.ru

На чтение 2 мин. Опубликовано

Привет !

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

Плагин – 

Browser Caching with .htaccess, вы сможете установить прямо из админ-панели wordpress. Перейдите по вкладке: Плагины – Добавить новый, введите название плагина в форму поиска, нажмите Enter, установите и активируйте открывшийся плагин.

 

 

Чтобы настроить плагин, перейдите по вкладке: Инструменты – Browser Caching.

 

 

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

 

 

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

 

 

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

 

Чтобы активировать кэширование в браузере, нажмите на кнопку – activate Browser Caching.

 

 

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

 

– You are now using BROWSER CACHING ! – Сейчас вы используете браузер кэширование !

 

 

Вот и всё, можете забыть про слово кэш, теперь это не ваша забота. Если остались вопросы, напишите комментарий. До новых встреч !

 

info-effect.ru

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


Читая данную статью вы узнаете про то как устранить пункт: используйте кэш браузера от нашего друга гула по PageSpeed Insights. Рассматривать проблему будем на примере одного знакомого мне блога.

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

  1. Устраняем проблему “не указан срок действия” и добавляем нужные директивы в .htaccess.
  2. Ставим плагин для кэширования граватаров NIX Gravatar Cache.
  3. Плагин для кэширования всего сайта.

Правильно используем кэш браузера и устраняем проблему «не указан срок действия»

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

Сейчас рассмотрим три шага, которые состоят в следующем:

  • Скачать .htaccess.
  • Внести директивы в него.
  • Разборка значений строчек.

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

Переходим к рамке 2, тут указаны замечания для следующих ресурсов, в основном это css, js и изображения. Разберемся, что это за срок действия. Дело в том, когда посетитель заходит на сайт, то его браузер скачивает себе файлы (это мы уже и так знаем из определения выше). Чтобы знать сколько хранить эти файлы у себя в памяти и нужно указывать это время.

Шаг 1. Скачиваем .htaccess

Первым шагом надо скачать .htaccess, все делаетя быстро, через менеджер FTP. В начале нужно будет узнать, на чем работает ваш сервер, точнее его обеспечение. Оно должно быть Apache (95% работают именно на нем, но проверить стоит).

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

Дальше, заходим в корневой каталог сайта (через FTP, я использую FileZilla) в папку pablic_html, там находится весь движок вордпресс. Здесь в идеале располагается файл .htaccess, он стандартный от Apache. Он регулирует загрузку и доступы, если его нет то создаем его. Будем его рассматривать в более тематических статьях, пока что нам надо сделать кэширование.

Шаг 2. Вносим mod-header в файл

Вторым шагом будем вносить директивы mod-header в .htaccess. Если он есть, то просто вставляем до закрывающего тега #endwordpress, вот этот код.

<ifModule mod_headers.c>
<FilesMatch "\.(html|htm)$">
Header set Cache-Control "max-age=43200"
</FilesMatch>
<FilesMatch "\.(js|css|txt)$">
Header set Cache-Control "max-age=604800"
</FilesMatch>
<FilesMatch "\.(flv|swf|ico|gif|jpg|jpeg|png)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>
<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
Header unset Cache-Control
</FilesMatch>
</IfModule>

Если же сделан по новой, то вставляем вот это и закидываем его в корневой каталог.

# BEGIN WordPress
<ifModule mod_headers.c>
<FilesMatch "\.(html|htm)$">
Header set Cache-Control "max-age=43200"
</FilesMatch>
<FilesMatch "\.(js|css|txt)$">
Header set Cache-Control "max-age=604800"
</FilesMatch>
<FilesMatch "\.(flv|swf|ico|gif|jpg|jpeg|png)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>
<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
Header unset Cache-Control
</FilesMatch>
</IfModule>
# END WordPress

Разбор строчек кода, за что они отвечают

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

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

Плагин для кэширования граватаров NIX Gravatar Cache

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

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

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

Первая галочка включен или выключен, и второй сколько хранить кэш.

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

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

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

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

Подведем итог, что мы узнали и какой порядок действий

  1. Узнали на чем работает сайт (apache, nginx и тому подобное).
  2. Научились закачивать .htaccess на компьютер.
  3. Отредактировали файл доступов.
  4. Смогли закинуть обратно на сервер.
  5. Поставили плагин nix gravatar cache.

P.S. Если что-то не получилось то смело пишите комментарии, отвечу и помогу.

Источник

wpsovet.ru

Кэш браузера | .htaccess

  • htaccess кэширование сохраняет содержимое веб-страницы на локальном компьютере, когда пользователь посещает ее;
  • Использование кэша браузера – веб-мастер дает указания браузерам, как следует рассматривать ресурсы.

Когда браузер отображает веб-страницу, он должен загрузить логотип, CSS файл и другие ресурсы:


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

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

  • Измените заголовки запроса ресурсов, чтобы использовать кэширование;
  • Оптимизируйте свою стратегию кэширования.

Для большинства людей единственный способ кэширования сайта htaccess заключается в том, чтобы добавить код в файл .htaccess на веб-сервере.

Файл .htaccess контролирует многие важные настройки для вашего сайта.

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

## EXPIRES CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType text/html "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 1 month"
</IfModule>
## EXPIRES CACHING ##

Сохраните файл .htaccess, а затем обновите веб-страницу.

В приведенном выше коде заданы промежутки времени. Например, 1 year (1 год) или 1 month (1 месяц). Они связаны с типами файлов. Приведенный выше код устанавливает, что .jpg файлы (изображения) следует кэшировать в течение года.

Если бы вы хотели изменить это, чтобы и JPG изображения кэшировались в течение месяца, то вы бы просто заменили «1 год» на «1 месяц«. Указанные выше значения кэширования через htaccess оптимальны для большинства веб-страниц.

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

Возможно, что метод Expires не сработает на вашем сервере, в этом случае вы возможно захотите попробовать использовать Cache-Control.

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

Пример использования в файле .htaccess:

# 1 Month for most static assets
<filesMatch ".(css|jpg|jpeg|png|gif|js|ico)$">
Header set Cache-Control "max-age=2592000, public"
</filesMatch>

Приведенный выше код устанавливает заголовок Cache-Control в зависимости от типа файла.

Рассмотрим упомянутую выше строку кода кэширования в браузере htaccess:

# 1 Month for most static assets

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

<FilesMatch ". (CSS | JPG | JPEG | PNG | GIF | JS | ICO) $">

Упомянутая выше строка говорит, что, «если файл будет одним из этих типов, то мы сделаем что-то с ним… »

Самое важное в этой строке то, что в ней перечислены различные типы файлов (CSS, JS, JPEG, PNG и т.д.) и что инструкции кэширования следует применять к этим типам файлов. Например, если вы не хотите, чтобы JPG файлы кэшировались в течение указанного периода времени, можете удалить «JPG«. Если вы хотите добавить HTML, то нужно в этой строке указать «HTML«:

Header set Cache-Control "max-age=2592000, public"

В упомянутой выше строке установлены фактические заголовки и значения:

  • Часть «Header set Cache-Control» — устанавливает заголовок;
  • Переменная «max-age=2592000» – указывает, сколько времени займет процесс кэширования (в секундах). В этом случае мы осуществляем кэширование в течение одного месяца (2592000) секунд;
  • Часть «public» сообщает о том, что это общедоступно.

Эта строка кэширования через htaccess закрывает оператор и заканчивает блок кода.

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

Получение нового (некэшируемого) файлового ресурса возможно при наличии уникального имени. Например, если файл CSS назван «main.css», то вместо этого мы могли бы назвать его «main_1.css». В следующий раз, когда мы поменяем его имя, мы можем назвать файл «main_2.css». Это полезно для файлов, которые периодически изменяются.

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

Данная публикация представляет собой перевод статьи «Leverage browser caching» , подготовленной дружной командой проекта Интернет-технологии.ру

www.internet-technologies.ru

Как включить кэш браузера | SEO Маяк

Всем привет! Сегодня на seo-mayak.com я продолжу разбирать рекомендации PageSpeed по ускорению загрузки сайта и расскажу, как включить кэш браузера на стороне посетителя Вашего сайта.

Многие веб-мастера используют для кэширования данных различные кэш-плагины. Самые популярные из них: W3 Total Cache, WP Super Cache и Hyper Cache.

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

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

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

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

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

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

Модули Apache: mod_headers и mod_expires

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

Данные модули не входят в стандартную сборку Apache и необходимо уточнить в службе поддержки хостинга, установлены ли mod_headers и mod_expires на сервере. Если таковые имеются, то можно приступать к написанию директив.

Модули mod_headers и mod_expires способны встраивать в ответ сервера специальные заголовки Cache-Control или Expires, которые укажут браузеру на стороне посетителя, какие файлы и на какое время надо кэшировать.

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

Скажу больше. Заголовок Expires начал работать с версии протокола HTTP/1.0, а заголовок Cache-Control был принят на вооружение с выходом протокола HTTP/1.1.

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

Вот такие дела. Я понимаю, что новичкам очень сложно усвоить данный материал, ведь я сам когда-то был «зеленым», но уверен, что при наличии желания можно разобраться в любом вопросе и если Вы дочитаете статью до конца, то думаю многое прояснится.

Для начала давайте разберемся с директивами, предназначенными для модуля mod_headers.

Директивы кэширования для модуля mod_headers

Вот такой код надо вставить в файл .htaccess. Во избежание лишних вопросов, вставляем перед строчкой # END WordPress:

# Включаем кэш в браузерах посетителей
<ifModule mod_headers.c>
    # Все html и htm файлы будут храниться в кэше браузера один день
    <FilesMatch "\.(html|htm)$">
        Header set Cache-Control "max-age=43200"
    </FilesMatch>
    # Все css, javascript и текстовые файлы будут храниться в кэше браузера одну неделю
    <FilesMatch "\.(js|css|txt)$">
        Header set Cache-Control "max-age=604800"
    </FilesMatch>
    # Все флэш файлы и изображения будут храниться в кэше браузера один месяц
    <FilesMatch "\.(flv|swf|ico|gif|jpg|jpeg|png)$">
        Header set Cache-Control "max-age=2592000"
    </FilesMatch>
    # Отключаем кеширование php и других служебных файлов
    <FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
        Header unset Cache-Control
    </FilesMatch>
</IfModule>

Теперь я немного поясню, что означают те или иные директивы.

<ifModule …>…</IfModule> — это своего рода контейнер, который заключает в себя директивы, предназначенные для того или иного модуля Apache и заодно проверяет наличие оного. Если модуль не найден, то директивы игнорируются.

В данном случаи мы обращаемся к модулю mod_headers, исходный файл которого носит название mod_headers.c, где «.с» — расширение файла.

<FilesMatch «…»>…</FilesMatch> — блочная директива, указывающая серверу на файлы с конкретными расширениями, на которые будут распространятся указанные в директиве правила. В кавычках, прописываются регулярные выражения, например «\.(html|htm)$», с помощью которых можно сгруппировать файлы с необходимыми расширениями.

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

Header — директива, влияющая на отправку HTTP заголовка со стороны сервера в сеть. Данная директива может принять следующие аргументы: set, append, add, unset и echo. Все аргументы я думаю описывать вовсе не обязательно, кто хочет знать больше, читайте документацию. Рассмотрим лишь те аргументы, которые используются в нашем коде.

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

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

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

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

Директивы кэширования для модуля mod_expires

При обращении к модулю mod_expires через файл .htaccess, мы будем использовать уже другие директивы (кроме ifModule), которые выглядят следующим образом:

<ifModule mod_expires.c>
    ExpiresActive On
    #по умолчанию кеш в 5 секунд
    ExpiresDefault "access plus 5 seconds"
    # Включаем кэширование изображений и флэш на месяц
    ExpiresByType image/x-icon "access plus 1 month"
    ExpiresByType image/jpeg "access plus 4 weeks"
    ExpiresByType image/png "access plus 30 days"
    ExpiresByType image/gif "access plus 43829 minutes"
    ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
    # Включаем кэширование css, javascript и текстовых файлов на одну неделю
    ExpiresByType text/css "access plus 604800 seconds"
    ExpiresByType text/javascript "access plus 604800 seconds"
    ExpiresByType application/javascript "access plus 604800 seconds"
    ExpiresByType application/x-javascript "access plus 604800 seconds"
    # Включаем кэширование html и htm файлов на один день
    ExpiresByType text/html "access plus 43200 seconds"
    # Включаем кэширование xml файлов на десять минут
    ExpiresByType application/xhtml+xml "access plus 600 seconds"
</ifModule>

С контейнером ifModule я думаю должно быть все понятно.

ExpiresActive — данная директива активирует или блокирует кэширование на стороне браузера пользователя.

on — активировать

off — блокировать

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

В директивах для модуля mod_expires синтаксис временного интервала гораздо гибче, чем для модуля mod_headers, где время задается только в секундах.

Для модуля mod_expires время можно устанавливать в следующий исчислениях:

years — лет или year — один год
months — месяцев или month — одни месяц
weeks — недель или week — одна неделя
days — дней или day — один день
hours — часов или hour один час
minutes — минут или minute — одна минута
seconds — секунд

Перед временным интервалом прописывается несколько дополнительных слов, например:

"access plus 1 month"

access — основное слово (основа). В переводе с англ. — доступ;

plus — ключевое слово (ключ), после которого должно следовать числовое значение.

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

ExpiresByType — директива, задающая временной интервал кэширования для определенных типов файлов. Достоинством данной директивы является то, что она отменяет время кэша по умолчанию, для указанных типов файлов, установленного директивой ExpiresDefault.

Также обязательно через слеш указывается тип файлов, например: image/jpegtext/html или application/x-javascript. Все типы файлов можно посмотреть здесь.

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

Конечно в  будущем я не обойду вниманием и эти темы, так что подписывайтесь на обновления блога, будет интересно!

До встречи!

С уважением, Виталий Кириллов

« Оптимизация WordPress. Нагрузка на сервер и как ее снизить
« PageSpeed — реальное ускорение сайта
« Как включить gzip сжатие и кратно ускорить сайт
« Как сократить CSS и ускорить загрузку сайта

seo-mayak.com

бенчмаркинг 18 плагинов / REG.RU corporate blog / Habr

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

Небольшая ремарка о кэшировании


Google недавно объявил, что все mobile-friendly сайты (а скорость — это путь к тому, чтобы быть «friendly») получают существенное преимущество в поисковой выдаче, начиная с 21 апреля. Возможно, вы уже видели тег «mobile friendly» в поисковой выдаче. И в Google Page Insights первая же панель адаптирована под мобильные устройства, а не под десктопы. Намерения Google ясны, и звучат громко для любого SEO-специалиста или вебмастера. Сейчас важно работать над производительностью как десктопной, так и мобильной версии сайта, что мы и попробовали отобразить в бенчмаркинге.

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

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

Подробности теста


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

Для того, чтобы сделать тестируемый пустой сайт максимально приближенным к реальности, использовалась тема Novelty от Tesla Themes. Тестируемую страницу сайта оформили с использованием графики и текста, был добавлен сайдбар и некоторые плагины (вывод новостей, фид из Twitter/Instagram). Теперь у нас страница, загрузка которой занимает относительно много времени. Да, в качестве хостинга использовался вот этот WordPress хостинг.

Плагины, которые тестировались:

  • AIO Cache
  • Alpha Cache
  • Bodi0’s Easy Cache
  • Cachify
  • Flexicache
  • Gator Cache
  • Hyper Cache
  • Hyper Cache Extended
  • Lite Cache
  • Next Level Cache
  • Really Static
  • Super Static Cache
  • W3 Total Cache
  • Wordfence Falcon
  • WP Fast Cache
  • WP Fastest Cache
  • WP Rocket
  • WP Super Cache
  • WP-Cache.Com
  • Zen Cache (formerly Quick Cache)

Остались ещё:

Brutal Cache — просто не работал;Batcache — плагин с зависимостью от Memcache, что не использовалось в текущем тесте.Autoptimize и Widget Cache также остались за бортом, поскольку они являются поддержкой для других плагинов, это не совсем самостоятельные плагины.

Хостинг и инструменты бенчмаркинга


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

В качестве инструментов использовались сервисы, предлагаемые Google, GTMetrix и Yahoo. Благодаря этому стало возможным тестировать не только скорость загрузки страниц, но и другие факторы, среди которых:

  • оптимизация изображений;
  • временная задержка сервера;
  • минификация и оптимизация js- и css-кода;
  • использование кэширования в браузере;
  • размещение скриптов;
  • использование CDN, распараллеливания/доменного шардинга;
  • использование Gzip-сжатия;
  • количество HTTP-запросов.

Google PageSpeed Insights


Сервис PageSpeed Insight проверяет сайт как с точки зрения десктопного ПК, так и со стороны мобильного устройства, выдавая оценку по 100-балльной шкале. Page Speed Insights прост в использовании, но предоставляет относительно сырой результат, который не даёт полного понимания того, что может быть улучшено. Даже несмотря на то, что инструмент даёт представление о некоторых вещах, которые Google может находить важными, информация, предоставляемая GTMetrix и Yahoo, намного полнее.

При этом Google во время оценки не принимает во внимание CDN, поэтому в некоторых случаях оценка занижена.

GTMetrix и YSlow


GTMetrix и YSlow основаны на руководстве по повышению производительности ресурса от Yahoo, оценка также выводится по 100-балльной шкале. Эти инструменты гораздо более изощрены в плане проведения измерений. PageSpeed Insight даёт всего несколько подсказок о том, что может быть улучшено, в то время как GTMetrix YSlow работают с не менее чем 50 различными метриками. GTMetrix также предлагает диаграмму-водопад, препарируя процесс загрузки, а также весьма продвинутую историю загрузки. Если вы хотите понять, как повысить производительность вашего ресурса, это один из лучших инструментов.

Тайминг


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

ApacheBench


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

Стоит отметить, что использование Nginx несколько снижает различие между работой сайта с плагинами/без плагинов. По этому поводу можно спорить, но в случае использования Nginx зафиксирована двукратная разница по сравнению с Apache.

Pingdom


Pingdom — хорошо известный сервис для мониторинга и тестирования. С каждым плагином проводилось 20 тестов, с фиксацией лучшего результата. Отметим, что сервер был расположен в Швеции (Стокгольм), а сервер Pingdom — в Нидерландах (Амстердам).

Webwait


Webwait — простой, но очень полезный инструмент. Основная задача сервиса — показать, за какое время полностью загрузится страница именно в вашем браузере. Таким образом, это не серверный инструмент, сервис запускается локально. Webwait загружает страницу снова и снова, а затем показывает средний результат. В нашем случае был выбран способ загрузки через Ethernet, браузер Opera. Каждая страница загружалась 101 раз с получением среднего и медианного времени загрузки.

Итак, с описанием всё, теперь приступим непосредственно к тестам.

Google, GTMetrix и Yslow


Страницы сайта тестировались с использованием указанных сервисов, вот результат:
Как видим, некоторые плагины здесь просто никак не проявились — оценка такая же или очень близка к оценке, когда кэширование вообще не используется. Google дал лучшую оценку Supercache как для десктопа, так и для мобильного устройства. В GTmetrix и Yslow мы видим, что Fastest Cache Rocket впереди планеты всей. Мы склонны оценивать последние значения как более важные, поскольку Google Page Insight для оценки использует меньше факторов.

Итак, лучшими плагинами оказались WP Fastest Cache, WP Super Cache и WP Rocket Cache. Победитель — WP Super Cache с работой через мобильный девайс. Кэширование для мобильных было также включено, о нём не забыли.

Тайминг


Как уже говорилось выше, оценочные баллы являются в большей мере показателем качества кода сайта. Они дают понимание того, что можно сделать для ускорения сайта, хотя более высокая оценка у сайта вовсе не значит, что он загружается быстрее, чем другие ресурсы. И в этом ошибка — оценочные инструменты дают идеи по улучшению сайта для снижения времени загрузки, но время загрузки не принимается во внимание в достаточной степени. Вы поймете это, взглянув на скриншот из Pingdom.
Как видите, тестируемая страница получила 96 из 100 баллов, что, вероятно, лучше, чем у 99% страниц любых сайтов. Тем не менее эта страница загружается почти 35 секунд. Корректен ли результат? Сделайте вывод сами 🙂

Тайминг — важный тест, поскольку здесь проводится реальное измерение скорости загрузки страниц сайтов.

ApacheBench


Итак, тестируем наш сервер на его способность поддерживать выполнение большого количества запросов. Чем больше показатель числа запросов за секунду, тем лучше.
Без кэширования сервер показывает результат в 18 запросов за секунду. Это довольно неплохой результат, который стал возможным благодаря использованию Nginx. На каждый запрос уходит примерно 1/500 с.

Здесь мы видим, что Hyper Cache Ext, WP Fastest Cache, WP-Cache.com и WP Rocket улучшают результат на 300% по сравнению с работой без кэширования. WP Rocket — самый быстрый и WP-Cache.com занимает второе место.

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

Pingdom


Без кэширования результат — около 2,8 секунды. Использование практически любого плагина улучшает результат по крайней мере вдвое.

Webwait


Здесь показан как средний, так и медианный результат при тестировании в Webwait. Время загрузки чуть меньше, поскольку был выбран шведский сервер Webwait (помните, это браузерный, а не серверный инструмент).

Среднее время загрузки



Медианное время загрузки



Как видим, практически неизвестный WP-Cache.com работает весьма неплохо.

Не кэшированием единым


Конечно же, далеко не всё зависит от кэширования. Важную роль играют и такие факторы, как выбор Apache, Nginx и т. п., корректность настройки, тип сервера (выделенный, VPS, шаред), количество изображений и их оптимизация, HTTP-запросы. Собственно, об этих факторах на «Хабре» знают практически все, поэтому останавливаться на них мы не будем.

Вывод


У всех плагинов, которые здесь представлены, разная функциональность. Некоторые очень просты, в то время как другие можно сравнить со швейцарским ножом. Super Cache, W3 и прочие плагины зачастую используют профи, которые знакомы с CDN и прочими премудростями. Другие пользователи предпочитают работать с более простыми плагинами вроде Lite Cache и WP-Cache.com. Кстати, WP-Cache.com, как говорилось выше, малоизвестный плагин, который показал отличные результаты.

Кто победитель?


На первом месте — WP-Rocket, платный плагин, над которым работает целая команда специалистов. За установку разработчики просят $39, а за безлимитку — $199.

На втором месте — WP Super Cache. Здесь результаты почти такие же, как и у лидера.

На третьем месте — WP-cache.com, заслуженный призёр. Похоже на то, что над созданием этого плагина работали ничуть не менее способные разработчики, чем над WP-Rocket. Этот плагин очень прост в настройке, так что, если у вас нет желания заморачиваться с конфигурацией, рекомендуем именно его.

habr.com

Leave a Reply