- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Добрый день
Имею сайт на html, были показатели скорости 95/100
Поставил https скорость упала на 8 пунктов
Есть ли методы разгона https?
Ну так смотрите, что именно упало, какие проблемы появились и думайте...
Ускорение сайта... через httpS
В сантиметрах или в килограммах?
Ускорение сайта... через httpS
В сантиметрах или в килограммах?
Для справки https://developers.google.com/speed/pagespeed/insights/
Для справки https://developers.google.com/speed/pagespeed/insights/
для кого эта справка? все прекрасно поняли, о чём речь. но там же и стоит, в чём проблема. вот и "ускоряйте httpS"
Sysler, если принимать во внимание механизм работы, то https никак не может быть быстрее. Если вы хотите достичь крайне высоких параметров, может быть тогда не надо использовать https?
Для начала хотя бы по документации в nginx настройте увеличенный keep-alive,ssl_session_cache и ssl_session_timeout.
HTTPS по своей природе медленнее, чем HTTP, так как к обычному HTTP протоколу добавляется еще и шифрование.
При этом само шифрование еще пол-беды, главное падение скорости происходит про установке соединения. Если при обычном протоколе клиент сразу шлет HTTP GET (или другой запрос), то при HTTPS вначале шлется запрос HTTP CONNECT, который устанавливает TCP-соединение, затем просходит обмен ключами (в спецификации SSL его называют "handshake", или "рукопожатие"). Этот обмен и приводит к основной затрате времени - как процессорного, так и реального.
Сделать можно мало что. В любом случае HTTPS будет медленней HTTP. Для того, чтобы ускорить, можно попробовать следующие идеи:
1. Использовать более мощный процессор - ну это из серии "капитан очевидность", конечно, но в данной ситуации вполне логично.
2. Можно использовать более короткий ключ асимметричного шифрования - именно ассиметричного, симметричное шифрование и так быстрое для современных процессоров. Однако, скорее всего, ключ и его размер вы приобрели у центра сертификации, так что этот вариант может требовать покупки другого ключа. Кроме того, более короткий ключ будет и более криптографически слабым. Так что этот вариант скорее теоретический.
3. Для ускорения работы сайта с реальными пользователями, используйте HTTP-заголовки кеширования, например, Expires, однако, я не уверен, что боты, которые определяют быстродействие сайта, учитывают эти заголовки.
то при HTTPS вначале шлется запрос HTTP CONNECT, который устанавливает TCP-соединение, затем просходит обмен ключами (в спецификации SSL его называют "handshake", или "рукопожатие").
Это не так. CONNECT происходит только в случае использования прокси. А про шифрование все так.
Поэтому ключевым методом становится повторное использование TLS-сессий. Или хотя бы увеличение вероятности их использования.
можно попробовать следующие идеи:
А где ж самое очевидное для
сайт на html
4. Не использовать httpS.
? ;)
Поэтому ключевым методом становится повторное использование TLS-сессий.
В HTTP 1.1 TCP-сессии повторно используются по умолчанию. Что касается длительности кеширования TCP-соединения, то это зависит не только от сервера, но и от клиента.
Можно пытаться использовать директиву KeepAliveTimeout (если сервер Апач), заголовок Keep-Alive или что-то подобное, однако, эффект надо только тестировать на реальных браузерах.
Таймаут по умолчанию обычно проверен практикой, разработчики Апача ведь не чайники, и если с их точки зрения именно этот таймаут идеальный, то что-то в этом есть.
Oliver9, речь о других сессиях TLS. Это отдельная сущность. В новом tcp-соединении могут быть использованы старые ключи симметричного шифрования от прошлого соединения.
Почитать можно, допустим, это http://ruhighload.com/post/%D0%9E%D0%BF%D1%82%D0%B8%D0%BC%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F+TLS+%D0%B2+NGINX_20160328