В один прекрасный день решил я разобраться с уведомлениями от Яндекса о медленной работе моего сайта, точнее с медленной генерацией и отдачей страниц сайта посетителям.
Самый простой способ ускорить ваш сайт — это исключить генерацию страниц каждый раз при обращении пользователя, а отдавать ему уже сгенерированную ранее. Значит, нужно как-то сгенерированную страницу положить в кеш, и при обращении к ней отдавать из него. По-умолчанию, wordress не имеет средств для кеширования сгенерированных страниц, поэтому, стоит воспользоваться каким-либо плагином. Я свой выбор остановил на плагине «WP Super Cache».
Кроме этого, можно ускорить загрузку для клиентов файлов java-скриптов и css-стилей. Из нескольких файлов css-стилей можно скомбинировать один, удалить комментарии, лишние пробелы. А ежели на сервере включено сжатие ответов (а его обязательно стоит включить, ежели это ещё не сделано), то в результате, браузеру клиента придётся загрузить только один сжатый css-файл, что ускорит его обработку и рендер страницы. С java-скриптами не всё так хорошо как с css-стилями, ибо какие-то скрипты должны грузиться в начале, а какие-то в конце, или в определённой последовательности. Но, вырезать лишние комментарии, пробелы и прочее, запаковать для уменьшения размера — это всё возможно. С этой выше описанной задачей хорошо справляется плагин «Autoptimize».
После установки и настройки этих плагинов, стоит проверить скорость генерации страниц вашего сайта через специальные сервисы. Я для этого использую «Google PageSpeed Insights» и «Webpagetest». С помощью этих двух сайтов можно получить полное представление, что и как грузится с вашего сайта в браузер клиенту.
Кроме всего вышеперечисленного, после перевода моего сайта на https, у меня появилась возможность переключить его на работу по «HTTP/2» протоколу. В данное время, все современные браузеры поддерживают его, а ежели обращение к сайту придёт со старого браузера, то оно будет обработано по «HTTP/1.0» или «HTTP/1.1» протоколу. «HTTP/2» позволяет в одном и том же соединении выполнить несколько запросов, но при этом он позволяет отправляемым запросам задать приоритет, и таким образом, запрос с более высоким приоритетом обработается быстрее. А ежели учитывать, что современные сайты содержат большое количество элементов, то использование «HTTP/2» позволяет браузеру выполнить множество запросов к серверу в рамках одного соединения, в отличие от «HTTP/1.1» или «HTTP/1.0» где на каждый элемент статики будет открыто и закрыто отдельное соединение.
Для работы с сайтом по «HTTP/2» протоколу, необходима поддержка переключения с обычного «TLS» на «HTTP/2». Для этого, имеются две реализации переключения: NPN (Next Protocol Negotiation) и ALPN (Application-Layer Protocol Negotiation). При этом первая реализация устарела и заменёна второй. А для работы второй реализации — ALPN, нужен OpenSSL версии (1.0.2 и выше), более старые поддерживают только NPN. Поддержка протокола «HTTP/2» в nginx была добавлена с версии 1.9.5. Но, помимо версии nginx, необходимо, чтобы он был собран с поддержкой openssl версии от 1.0.2+. С какой версией у вас собран nginx проверить очень просто, надо выполнить команду:
1 2 3 4 5 6 | # nginx -V nginx version: nginx/1.12.2 built by gcc 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC) built with OpenSSL 1.0.2k-fips 26 Jan 2017 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-http_geoip_module --add-module=/root/rpmbuild/BUILD/nginx-1.12.2/ngx_pagespeed-1.12.34.2-beta --add-module=/root/rpmbuild/BUILD/nginx-1.12.2/nginx-upstream-fair --add-module=/root/rpmbuild/BUILD/nginx-1.12.2/nginx-push-stream-module-master --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie' |
Как можно заметить из вывода команды, nginx у меня собран с поддержкой «built with OpenSSL 1.0.2k-fips 26 Jan 2017», а кроме этого, в нём ещё активирована поддержка протокла «HTTP/2» — «--with-http_v2_module». Ежели какой-то из этих двух строк у вас нет, или нет обеих — то вам придётся обновить/пересобрать openssl или nginx до нужной версии. Ежели обе строчки присутствуют в выводе как я показал выше, то включить «HTTP/2» для вашего сайта просто. Надо в конфигурации сайта в nginx прописать http2 следующим образом:
1 2 3 4 | server { listen 83.143.194.188:443 ssl <strong>http2</strong>; server_name www.baf.ru; |
и перезапустить nginx. Теперь надо проверить, что обращение по https поддерживает ALPN-протокол. Для этого, необходимо выполнить следующую команду:
1 2 3 4 5 6 7 8 9 10 11 | $ echo | openssl s_client -alpn h2 -connect www.baf.ru:443 | grep ALPN depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root verify return:1 depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority verify return:1 depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA verify return:1 depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = www.baf.ru verify return:1 DONE <strong>ALPN protocol: h2</strong> |
Как можно увидеть из примера выше — у меня на сайте всё в порядке. Также, настройку и поддержку сайтом протокола «HTTP/2» можно проверить через веб, на сайте — «HTTP/2 Test». В итоге должно быть так:
Кроме этого, настоятельно рекомендую ознакомиться со статьями «Как использовать preload, prefetch и preconnect для ускорения сайта» и «Предсказывающие страницы: Использование dns-prefetch, preconnect, prefetch, preload и prerender для повышения производительности страницы». В этих статьях рассказивается о ресурсных подсказках и директивах, как с их помощью оптимизировать доставку в браузер клиента шрифтов, файлов стилей, изображений, java-скриптов. Каких-либо точных рекомендаций дать я не могу, тут всё зависит от конкретного сайта, от того как он свёрстан. Но для своего сайта я сделал указал две подсказки в файле header.php используемой wordpress'ом темы:
1 2 3 | <link rel="shortcut icon" href="<?php echo get_theme_mod( 'anariel_favicon' ); ?>"> <link href='https://fonts.googleapis.com' rel='preconnect' crossorigin"> <link href='https://fonts.gstatic.com' rel='preconnect' crossorigin"> |
Теперь браузер клиента, при обращении к моему сайту будет дополнительно открывать соединения к «fonts.googleapis.com» и «fonts.gstatic.com», чтобы скачать файлы шрифтов, которые прописаны в используемой мной теме wordpress'а. Задать их можно непосредственно в коде, или в заголовках ответа при обращении к странице сайта. Я выбрал первый вариант.
Ежели теперь выполнить тест отображения сайта в браузере у клиента на Webpagestest, то для моего сайта получается такая картинка:
Как можно заметить, изображения с моего сайта теперь грузятся в одном подключении, браузер не делает отдельное подключение на каждую картинку. Ну и на мой взгляд, результат оптимизации получился очень хороший.