Я уже писал подробную статью по теме файла .htaccess и о многих его gzip правилах (ссылка будет ниже), – однако, вопрос скорости загрузки сайта будет ещё долго (если не всегда) будоражить умы веб мастеров!
Приходят письма с вопросами: как включить gzip сжатие, кэширование картинок в браузере пользователя и прочая.?. Приходилось ссылаться на прежнюю статью, которая достаточно объёмная, подробная – новички путаются!
И вот я решил написать ещё один коротенький пост, но уже без лирических отступлений: этакий реестрик ( в том числе и для себя), который время от времени буду пополнять современными вариантами кода ускорения сайта.
В этой статье рассмотрим несколько действительно полезных способов (строк кода), которые целесообразно поместить к себе на сервер в файл .htaccess.
правила .htaccess
Нужно понимать, что эликсира на все случаи жизни не бывает! Всякий предложенный веб разработчиком код нужно тестировать на личном сайте, и не иначе! Не исключение и правила .htaccess: многое положительное или отрицательное в скоростях загрузок сайта напрямую зависит от того хостинга, на котором физически расположен ваш сайт.
Я всегда советую потратить пару минут времени и поинтересоваться у своего хостера вопросом: включено ли сжатие gzip в режиме mod_deflate именно в вашем аккаунте? Не бойтесь показаться занудой – бойтесь не раскусить хренового хостера сразу! …кстати, вот прежняя подробная статья о файле htaccess.
Кстати же, вот ещё статья, в которой я делал подробный обзор известных хостингов, думаю, будет полезно познакомиться… а также нелишне узнать как перевести свой блог/сайт на https.
Как и говорилось выше, качество площадки – хостинга, на котором физически расположен наш сайт, играет важнейшую роль. Так что стоит посерьёзнее отнестись к выборам хостинга.
Для тех, которые владеют сайтами посерьёзнее – порталами и прочей тяжёлой техникой) рекомендую обратить внимание на эту площадку, где можно запросто арендовать сервер.
подготовим сайт к режиму gzip-сжатия
Чтоб не путаться где и как правильно добавляется код в файл .htaccess
– прописывайте строки перед:
# END WordPress
первый блок кода, и уже за ним последующие…
Подключаем (или дополнительно организуем) на нашем сервере режим mod_deflate
:
#gzip сжатие
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0678 no-gzip
BrowserMatch bMSIE gzip-only-text/html
<ifmodule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_item_include file \.js$
mod_gzip_item_include file \.css$ </IfModule>
</IfModule>
# фин gzip сжатие
Этот код стоит установить – однако – непременно проверьте его отработку ВКУПЕ с плагином кэширования, например (если установлен) WP Super Cache. В его настроечных недрах поиграйте “галочкой” в строке Сжимать файлы кэша чтобы ускорить работу. (Рекомендовано).
В любом случае от результата теста, предложенный выше код не повредит: и стоит помнить, что у нас цели улучшения скорости сайта… Так что поэкспериментируйте.
Ссылки на ресурсы, на которых легко проверить результаты сжатия даны в прежней статье: ссылка выше!
Далее, чтобы включить
Подборка вариантов Redirect 301 — на все случаи жизни сайта
кэширование в браузере на стороне пользователя
Когда-то давным-давно… каждый файл, к примеру JS, сжимали вручную и помешали (сжатый файл) в соответствующие каталоги и подкаталоги своего сервера (сайта) – теперь, эта процедура вряд ли оправдана: многое из “сжатий” выполняется в автоматическом режиме – вот почему (ну, я так всегда рекомендую) целесообразно поработать с файлом .htaccess
вкупе с плагином кэширования.
Для того чтобы перенапрвить (скажем так, чтение браузером нашего сайта) на сформированные gzip файлы – добавьте такие строки в файл .htaccess
: (в комментариях последующих строк кода дано кое-какое описание)…
# Перенаправление на gzip файлы
AddEncoding gzip .gz
<FilesMatch "\.js.gz$">
ForceType text/javascript
Header set Content-Encoding: gzip
</FilesMatch>
<FilesMatch "\.js$">
RewriteCond %{HTTP_USER_AGENT} !".*Safari.*"
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule (.*)\.js$ $1\.js.gz [L]
ForceType text/javascript
</FilesMatch>
<FilesMatch "\.css.gz$">
ForceType text/css
Header set Content-Encoding: gzip
</FilesMatch>
<FilesMatch "\.css$">
RewriteCond %{HTTP_USER_AGENT} !".*Safari.*"
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule (.*)\.css$ $1\.css.gz [L]
ForceType text/css
</FilesMatch>
# Перенаправление на gzip файлы
как включить кэш в браузерах посетителей (пользователей)
Этот код запомните, возможно, при окончательном тестировании скоростей загрузки сайта, он вам не потребуется. Хотя на некоторых площадках я его устанавливаю.
# Включаем кэш в браузерах посетителей
<ifModule mod_headers.c>
# Отключаем кеширование php и других служебных файлов
<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
Header unset Cache-Control
</FilesMatch>
</IfModule>
А вот это как раз подборка кода, для включения кэширования на стороне пользователя – отправляем команды обозревателям на кэширование наших картинок различных форматов: (попросту, чтобы ваш сайт открывался с более высокой скоростью – картинки ваших статей /документации/ будут храниться в КЭШ браузере пользователя, и при повторном открытии вашего сайта, эти фотки будут подхватываться из его кэш файла))
# кеширование в браузере на стороне пользователя
<IfModule mod_expires.c>
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"
</IfModule>
# Cache-Control
<ifModule mod_headers.c>
# 30 дней
<filesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|swf)$">
Header set Cache-Control "max-age=2592000, public"
</filesMatch>
# 30 дней
<filesMatch "\.(css|js)$">
Header set Cache-Control "max-age=2592000, public"
</filesMatch>
# 2 дня
<filesMatch "\.(xml|txt)$">
Header set Cache-Control "max-age=172800, public, must-revalidate"
</filesMatch>
# 1 день
<filesMatch "\.(html|htm|php)$">
Header set Cache-Control "max-age=172800, private, must-revalidate"
</filesMatch>
</ifModule>
Этот код даю для примера!
#Запрет отдачи HTTP-заголовков Vary браузерам семейства MSIE
<IfModule mod_setenvif.c>
BrowserMatch "MSIE" force-no-vary
BrowserMatch "Mozilla/4.[0-9]{2}" force-no-vary
</IfModule>
# кеширование в браузере на стороне пользователя
А этот код стоит добавить в ваш файл – общее усиление кэширования!
# использование кеша браузеров - Усиливаем кеширование
FileETag MTime Size
<ifmodule mod_expires.c>
<filesmatch ".(jpg|jpeg|gif|png|ico|css|js)$">
ExpiresActive on
ExpiresDefault "access plus 1 year"
</filesmatch>
</ifmodule>
защита картинок сайта – хотлинк
Если хотите запретить использование (подгрузку – хотлинк) картинок с вашего сайта, то – стоит добавить нижеследующий код:
# ЗАПРЕТИМ использовать картинки на внешних сайтах
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^https://(.+\.)?mihalica\.ru/ [NC]
RewriteCond %{HTTP_REFERER} !^$
# /images/empty.jpg ВЫВОДИМ ДРУГОЕ изображение
RewriteRule .*\.(jpe?g|gif|mp3|bmp|png)$ img/MIHALIKA.jpg [L]
Как это работает:
Если где-то на стороннем сайте админ попытается использовать ваше изображение: попросту укажет URL на вашу картинку, которая станет подгружаться на его ресурс – это ему не удастся осуществить. Если обраганизуете показанный код, в этом случае будет подгружаться какая-то сторонняя картинка, к примеру, ваш логотип MIHALIKA.jpg или что-то другое.
Хотлинк всё-таки немного скрадывает мощностей вашего сервера.
Конечно же: не забудьте поменять имя домена и имя файла изображения.
защитим в .htaccess иные файлы сервера
Вот этот код тоже весьма полезен! Даже если используется какой-то плагин защиты, типа iThemes Security почитайте о том, как настроить этот плагин, используя в том числе и код показанный ниже. Возможные конфликты в дублирование функционала iThemes Security…
#Защищаем .htaccess файл
<Files ~ "^.*\.([Hh][Tt][Aa])">
order allow,deny
deny from all
satisfy all
</Files>
#Защищаем xmlrpc.php
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>
# защита wp-config.php
<files wp-config.php>
order allow,deny
deny from all
</files>
# Защищаем .htaccess файл
# <files office-reception>
# order allow,deny
# deny from all
# </files>
Как эпилог:
…в сети много информации, исследуя которую новички путаются… спрашивают: (хотя, думаю, после этого моего поста её будет ещё болше)) ну, да ладно…
как забанить определённый ip пользователя в htaccess
Вот чудодейственный код: пропишите его на постоянное место жительство в файл чтsssss…
# ЗАПРЕТ IP
<Limit GET POST PUT>
order allow,deny
allow from all
Deny from 80.248.225.168
Deny from 176.62... ....
</LIMIT>
# ЗАПРЕТ IP
Как понимаете, вам только потребуется прописать изложенный выше код и добавить ip адреса, которые вы решили забанить.
Deny from 80.248.225.168 – добавляете в код новую строку Deny from
и прописыаете цифры – это и есть ip.
Что такое динамические и статические IP адреса.
...город веб мастеров Михалика.ru © - запросто с WordPress - ATs media squad
Online консультация по настройкам и созданию сайтов на WordPress
mihalica.ru !
БоЛШе информации хорошей и разной! Спасибки, Михаил! Утешили страждущую такой инфы душу новичка. ))
Спасибо и Вам, Софико! за коммент…
Привет! у меня такая проблема: предположим, редактирую статью… всё ок. Закрываю текстовый редактор… потом, если тут же решил ещё что-то поправить – снова открываю редактор, а статья загружается в старом редактировании (т.е. тот вариант, который был до моего последнего редактирования!!). Непойму, почему так сильно кэшируется админка.
Если к примеру обновлю страницу (просто или Ctrl f5) в этом случае загружается новый вариант. Однако!!!!!!! это неудобно. Если забудешь после загрузки СНОВА перезагрузить, то запросто можно потерять наработки! Контент можно испортить.
Подскажите, где искать причину… Админка кэшируется?
Здравствуйте!
Эта проблема, вероятно, скрывается на вашей стороне (стороне пользователя) – брузер отдаёт кэшированную страницу!
Админка не кэширунтся кэшируется на сервере. Но если после повторной перезагрузки ОК – то это говорит о том, что проблема на вашей стороне.
Попробуйте установить мой плагин NOCacheAdminca. Либо, если не поможет и если пользовались кодами из данной статьи, то попробуйте поотключать эти варианты кода: # Cache-Control
может быть бажит вариант php.
Словом, повнимательнее к файлу
.htaccess
и плагинам – их настройкам.