Комментарии 15
Админку гораздо проще защитить поставив пароль на директорию. Большое количество плагинов, не есть хорошо. Для сжатия тоже лучше использовать средства Апач (автор указал пример). К сожалению, WP и Postgresql так и не подружили, работает опять же только через плагины
Сокрытие url - плохая и неэффективная практика. Гораздо эффективнее - бан айпишников по ряду критериев (BL + GeoIP + вручную). Автор не упомянул очччень важный момент. Он не связан напрямую с собственно скоростью, но очень важен для работы ресурса в целом. Нужно банить роботов, причем не в файле роботс, а прям в правилах нгинкса. Я всегда первым делом добавляю такую строку:
для апача
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (bingbot|AhrefsBot|SemrushBot|PetalBot|MJ12bot|Detectify|dotbot|Riddler|LinkpadBot|BLEXBot|FlipboardProxy|aiHitBot|trovitBot|BUbiNG|MauiBot) [NC]
RewriteRule .* - [F]
</IfModule>для нгинкса
if ($http_user_agent ~* SeopultContentAnalyzer|SeekportBot|DataForSeoBot|Barkrowler|BLEXBot|SemrushBot|MJ12bot|AhrefsBot|bingbot|DotBot|PetalBot|LinkpadBot|SputnikBot|statdom.ru|MegaIndex.ru|WebDataStats|Jooblebot|Baiduspider|BackupLand|NetcraftSurveyAgent|openstat.ru) {
return 444;
}Еще неплохая практика - перенос всей статики на другой домен. Чтобы при каждом запросе не отправлялись никакие там куки и прочая. Т.е. вся папка uploads живет просто на другом домене - это тоже снижает мусор при общении клиента с сервером.
HTTP/2 поддерживает сжатие заголовков (а сжатию кук посвящён аж целый отдельный раздел в спецификации), поэтому может случайно оказаться, что перенос статики на другой домен наоборот всё замедлит, потому что браузеру придётся тратить время на установку нового соединения
Браузер можно уведомить о необходимости подключения к другому домену.
Но успеет ли браузер подключиться достаточно быстро даже с таким уведомлением — вопрос неочевидный. Было бы интересно посмотреть какие-нибудь бенчмарки, особенно на больших пингах
вы говорите про сжатие куки в http2, но автор комментария выше говорит что куки вообще не нужны на статику
написал ниже, поддомен позволяет вынести статику на отдельный сервер, например с более широким каналом, кешированием или cdn
достаточно быстро подключиться - вы о чем? подключений на страницах происходит уйма, сторонние скрипты, аналитика, да и keep-alive существует, и цепочка сертификатов и другие настройки ssl для более быстрого повторного подключения. без подключений нет интернета, в конце концов, ничего критического в дополнительном домене я не вижу, а плюсы существенные.
Куки конечно не нужны, но приведёт ли избавление от них к ускорению — всё ещё неочевидно без бенчмарков.
На своих сайтах я не использую ни сторонние скрипты, ни аналитику, а в роли кэширующего CDN выступает Cloudflare — то есть как минимум в моей личной ситуации плюсов от дополнительного домена не видно
Другой домен (поддомен) можно вынести на отдельный сервер для раздачи статики, или на cdn
Чем выше CPU процессора на хостинге
подскажите, от уровня мирового океана считать? :)
WP все пишет в одну таблицу, wp_ posts , когда таблица становится больше 2-3 ггб, все встает колом, ни добавление памяти, не ресурсов ЦП не добавляет производительности. Если мне не изменяет память, WP не индексирует поиск. В общем, все нарастает, как снежная лавина
Шутка была про забытое слово скорость
Да, вп пишет посты в одну таблицу, но не все данные. Чаще начинает тормозить от таблиц с мета и терм данными.
Есть способы решения и данных проблем - кастомные таблицы, партиционирование, репликации, кеширование
WP с коробки не предназначен для хайлоада и большого обьема данных, но есть способы поддерживать приемлимую производительность и на многогигабайтной БД
Как ускорить сайт на WordPress за 15 шагов