Почему HTTPS замедляет сайт и как это исправить?
В настоящее время трудно встретить сайт без замочка HTTPS в адресной строке. HTTPS стал стандартом, и большинство сайтов априори используют именно защищенное соединение. Этому есть несколько причин, из которых защита пользовательских данных стоит далеко не на первом месте. Это и повышение доверия посетителей, и отсутствие надписи “Не защищено” в браузерах, и польза для SEO. Но есть и недостаток - соединение по HTTPS медленнее, чем по HTTP. Это замедляет загрузку сайта, что может даже оказать обратный эффект для SEO, ведь скорость сайта является более значимым фактором ранжирования, чем наличие HTTPS. Однако используя некоторые современные технологии, этот недостаток легко исправить, о чём и поговорим в этой статье.
Почему HTTPS медленнее HTTP?
Данные по HTTPS передаются также как и по HTTP, с одной лишь разницей - перед началом передачи данных браузер и сервер устанавливают защищенное соединение по протоколу SSL/TLS. Его ещё называют SSL/TLS-рукопожатием. Во время этого рукопожатия сервер отправляет браузеру копию своего SSL-сертификата, браузер проверяет его подлинность, а затем они обмениваются ключами и задают шифрование сессии. Это происходит при каждом новом соединении, которых при загрузке сайта может потребоваться несколько. Потому данные и передаются дольше - существенно увеличивается как время ответа сервера, так и время загрузки контента.
Если говорить проще, то когда вы в браузере запрашиваете какой-то сайт, через ДНС определяется адрес его сервера, и далее от вас к этому серверу летит кусочек технической информации, потом от сервера к вам, потом от вас, к вам, от вас, к вам… и т.д. И всё это последовательно, да ещё с перерывами на обработку шифрования. Минимум 8 раз должны данные пролететь всё расстояние между вами и сервером перед тем, как вы только начнёте загружать нужную страницу. В то время как для обычного HTTP-соединения таких “перелетов” всего 4, то есть в целых 2 раза меньше!
Как же компенсировать эту разницу?
Использование CDN
Эта разница тем критичнее, чем дальше от сервера находится посетитель сайта. Ведь, например, 8 “перелетов” в пределах Москвы это не так долго, как от Москвы до Хабаровска. Поэтому первым делом желательно по максимуму сократить расстояние от вашего сервера до пользователей.
Проще всего это сделать с помощью CDN-сервиса с охватом интересующих вас регионов. CDN кэширует содержимое сайта в географически распределенной сети своих серверов. И посетитель, где бы он ни находился, будет устанавливать соединение именно с ближайшим CDN-сервером.
Важно только выбрать CDN, который кэширует страницы сайта целиком, а не только статический контент, иначе нужного эффекта не будет.
Протокол TLS 1.3
С ним до получения данных требуется преодолеть уже не 8, а 6 расстояний до сервера.
А, например, когда вы просмотрели первую страницу сайта и переходите к следующей - то при наличии кэширования HTTPS-сессий - соединение может не создаваться с нуля, а восстановиться по ускоренной процедуре. И в TLS 1.3 входит опция 0-RTT, с которой такое восстановление потребует преодолеть всего 4 расстояния - совсем как для HTTP.
Ну, а для посетителей с поддержкой TCP Fast Open выходит ещё на 2 меньше – и по установке, и по восстановлению.
ECDSA-сертификаты
Рекомендуется использовать одновременно два SSL-сертификата:
- Первый – стандартный RSA. У большинства сайтов по умолчанию используется именно он. Но для современных браузеров он менее эффективен, поэтому стоит использовать его исключительно для полной совместимости со старыми версиями браузеров.
- А основной сертификат - с современным алгоритмом подписи ECDSA. С ним снижаются основные задержки на обработку ключей в процессе соединения, а сам сертификат компактнее по объёму и быстрее передаётся.
Протокол HTTP/2
Это самая мощная оптимизация HTTPS, поэтому остановлюсь на ней подробнее.
Когда браузер загрузил HTML-страницу, он анализирует, какие ссылки на ней есть, и начинает загружать по ним скрипты, картинки и прочее. Берёт ссылку на первую картинку, посылает серверу и стоит, ждёт, пока ссылка долетит до сервера, сервер сообразит и отправит саму картинку. Дождался, отправляет ссылку на вторую картинку и также стоит ждёт.
На самом деле, браузер чуть умнее, и знает, что так простаивать нехорошо, а чтобы изменить ситуацию нужна многопоточность. То есть просто запросить много-много картинок сразу.
В старом HTTP для этого браузер должен был создать ещё несколько соединений с сервером. А я уже писал выше, как это долго и затратно - создавать соединения. Начало многих загрузок сильно откладывается. Да ещё и количество соединений к одному домену в большинстве браузеров ограничено всего до 6 штук, что часто просто недостаточно для полноценного использования интернет-канала. Именно из-за этого ограничения ранее был популярен вынос картинок на отдельный поддомен. А сейчас от такого больше вреда, чем пользы.
С приходом HTTP/2 ситуация кардинально изменилась. Потому что у HTTP/2 есть мультиплексирование! Это та же многопоточность, только на все потоки используется теперь одно соединение, - то, что и так уже было создано при загрузке самой HTML-страницы. Ну, а самих потоков легко может быть даже более сотни.
Преимущество от этого получают все сайты, а для сайтов с большим количеством картинок и других файлов - разница колоссальная.
Но это не всё. На скорость очень сильно влияет правильная последовательность загрузки элементов страницы. Например, чтобы отобразить верхнюю часть страницы, которую посетитель увидит первой, обычно нужны CSS-файлы, некоторые картинки и скрипты. А какая-нибудь иконка из нижней части и все другие файлы потребуются позже. В соответствии с этим браузер определяет приоритет каждого файла. В старом HTTP браузер мог только менять последовательность, в которой он запрашивает файлы с сервера. А в HTTP/2 есть поддержка приоритетов со стороны хостинга. То есть даже если уже запрошено сто низко приоритетных картинок, и появился запрос на какой-нибудь важный шрифт, то он сможет загрузиться быстрее.
И заодно HTTP/2 немного снижает объём передаваемых данных и приносит другие маленькие преимущества.
Технология OCSP Stapling
Некоторые браузеры проверяют достоверность сертификата с помощью запроса к центру сертификации. А с помощью расширения OCSP Stapling сервер сразу посылает браузеру все необходимые данные вместе с сертификатом, и таким образом задержки на дополнительный запрос исключаются.
Внедряем все технологии с помощью одного сервиса
Для внедрения каждой из этих технологий (кроме CDN), необходимо произвести определенные настройки на вашем веб-сервере. Важно произвести их правильно, чтобы всё работало как задумано и без ошибок. Обычно подобными задачами занимается программист или системный администратор.
Но можно совместить всё в одном - подключить CDN с уже встроенным пакетом оптимизаций. Такое комплексное решение я нашел в CDN-сервисе Web Support Revolution. У них много серверов по всему миру, и что важнее всего, хороший охват русскоязычного интернета, - кэширующие сервера есть даже в самых отдаленных регионах России, а также на Украине и в Беларуси. Это гарантирует кратчайший маршрут передачи данных для любого посетителя сайта. Ну а непосредственно HTTPS-оптимизации у них включены во все тарифы. С профессиональной настройкой под ключ. И даже не только те, что я описал, но и некоторые другие, например дополнительно они задают приоритеты алгоритмов шифрования для разных устройств, - чтобы для каждого типа устройств использовался наиболее быстрый алгоритм. Для мобильных устройств, где мощность процессоров достаточно низкая, это очень кстати.
У них же вы можете бесплатно выпустить оба вида SSL-сертификатов (от Let’s Encrypt) - и RSA, и ECDSA.
И кстати, когда речь шла о CDN, я забыл упомянуть, что данные сервисы не только сокращают расстояние до пользователя, но ещё и выполняют всю обработку SSL-шифрования, в результате чего снижается нагрузка на ваш сервер, и он может быстрее выполнять все запросы.
Как итог, по заявлению представителей Web Support Revolution, сайты по HTTPS у них в большинстве случаев загружаются даже быстрее, чем обычные сайты по HTTP. К слову, это заявление легко проверить, так как действует манибэк в течение 30 дней - за это время можно вернуть все деньги, если результаты оптимизации не сойдутся с ожиданиями.