Рассмотрим процесс миграции вебсайта на WordPress с сервиса Cloudflare на локальное кеширование с использованием Apache .htaccess и плагина WP Super Cache.

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

Проблематика: блокировка Cloudflare в РФ

В связи с массовыми блокировками IP-адресов Cloudflare со стороны Роскомнадзора, многие российские пользователи испытывают проблемы с доступом к сайтам, использующим данный CDN-сервис. Это создает существенные сложности как для владельцев сайтов, так и для их посетителей. Решением проблемы является переход на альтернативные методы кеширования и защиты сайта.

Массовые блокировки Cloudflare в России: что происходит?

Контекст

• проблема с блокировкой Cloudflare в РФ
• необходимость получить ту же скорость сайта но через классический хостинг
• используется хостинг Бегет с Apache & .htaccess
• за основу берем плагин WP SuperCache

Процесс

Отключаем режим Proxy Cloudflare для сайта

Для отключения режима проксирования в Cloudflare необходимо перейти в раздел DNS и изменить статус записей с оранжевого облака (Proxied) на серое (DNS only). После этого все запросы будут идти напрямую на сервер хостинга, минуя CDN Cloudflare.

Подключаем SSL сертификат Бегет вместо CF

После отключения Cloudflare необходимо установить SSL-сертификат от хостинга Бегет. Для этого перейдите в панель управления хостингом, найдите раздел «SSL-сертификаты» и активируйте бесплатный Let’s Encrypt сертификат для вашего домена. После активации сертификата все соединения с сайтом будут защищены через HTTPS протокол.

Процесс выпуска сертификата может занять 5-10 минут.

Пока сертификат выпускается — приходится наблюдать ошибку на сайте:

Кеш страниц на базе WP Super Cache + Apache .htaccess

Для настройки кеширования страниц используем плагин WP Super Cache. Это популярное решение для WordPress, которое генерирует статические HTML-файлы из динамического содержимого сайта. Правильная настройка плагина в сочетании с директивами Apache в файле .htaccess позволяет значительно ускорить загрузку страниц и снизить нагрузку на сервер.

---

Пример в моем кейсе:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
#If you serve pages from behind a proxy you may want to change 'RewriteCond %{HTTPS} on' to something more sensible
AddDefaultCharset UTF-8
RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} ^$
# RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{HTTPS} on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html.gz -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html.gz" [L]

RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} ^$
# RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{HTTPS} !on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html.gz -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html.gz" [L]

RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} ^$
# RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTPS} on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html" [L]

RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} ^$
# RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTPS} !on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html" [L]
</IfModule>

# BEGIN WordPress Multisite
# Using subdomain network type: https://wordpress.org/documentation/article/htaccess/#multisite

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]

# END WordPress Multisite

Тонкая конфигурация кеширования страниц

Базовые опции нам дает плагин из коробки. Однако у любого более менее реального сайта есть своя специфика и требуется более тонкая настройка логики кеширования.

В моем случае это 2 составляющие:

• мне нужно все страницы делать публичными и на месяц, за исключением нескольких роутов
• все исключенные страницы могут быть приватными и должны учитываться в плагине кеширования WP Super Cache

Сниппет конфигурации который реализует эту логику и размещается в дочерней теме или по вкусу:

<?php

namespace App;

CacheConfig::init();

class CacheConfig
{
    private static $routesForExclude = ['my', 'checkout', 'cart', 'test', 'lms', 'wp-json'];

    public static function init()
    {
        add_action('init', function () {

            if (is_admin()) {
                return;
            }

            add_action('wp', [__CLASS__, 'unset_user'], 111);
            add_action('wp', [__CLASS__, 'wp_super_cache_config'], 99);
        });
    }

    /**
     * Config for support plugin WP Super Cache
     * 
     * @return void
     */
    public static function wp_super_cache_config()
    {
        global $cache_rejected_uri;
        $cache_rejected_uri = array_merge((array) $cache_rejected_uri, self::$routesForExclude);
    }

    /**
     * Make all pages as public and cache for 33 days
     *
     * @return void
     */
    public static function unset_user()
    {
        global $wp;

        if (! is_user_logged_in()) {
            return;
        }

        if (isset($wp->query_vars['rest_route'])) {
            return;
        }

        if (self::if_url_starts_with(self::$routesForExclude)) {
            return;
        }

        wp_set_current_user(0);

        header('Cache-Control: public, max-age='.(33 * DAY_IN_SECONDS));
    }

    public static function if_url_starts_with($words)
    {
        global $wp;

        foreach ($words as $word) {
            if (strpos($wp->request, $word) === 0) {
                return true;
            }
        }

        return false;
    }
}

Проверяем TTFB

Смотрим тайминг ответа сервера — 103 мс. Это нас устраивает. Значит что ответ пошел из кеша минуя PHP & MySQL. Что и требовалось получить.

Замер CWVs PageSpeed в среднем для сайта

Отчеты по CWVs делаются на сайте автоматически через плагин SiteKit от Google.

Для мобильных устройств:

Для десктопа:

Итого

99% страниц отдаются из кеша, минуя сервера PHP & MySQL. Тем самым обеспечивая скорость на уровне 100-200 мс TTFB. Попутно снижая нагрузку на сервера в 5-10х раз.

Что хорошо как с точки зрения UX (пользователям нравятся быстрые сайты), так и с точки зрения SEO (поисковики также обращают на это внимание при ранжировании ответов).

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