Простой статический сайт WordPress, полностью работающий по https.
Nginx conf здесь: http://pastebin.com/BrP0LThT
Единственная разница до / после:
listen 443 ssl;
listen 443 ssl spdy;
Nginx 1.8.0 с SSL, без SPDY:
Ответ из файла transitions.js:
HTTP/1.1 200 OK
Server: nginx/1.8.0
Date: Sun, 28 Jun 2015 18:13:30 GMT
Content-Type: application/javascript
Last-Modified: Wed, 03 Dec 2014 14:19:08 GMT
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
ETag: W/"547f1bdc-5267"
Expires: Sun, 12 Jul 2015 18:13:30 GMT
Cache-Control: max-age=1209600
Content-Encoding: gzip
Та же настройка сервера с SPDY:
Ответ из того же файла js:
HTTP/1.1 200
cache-control: max-age=1209600
content-encoding: gzip
content-type: application/javascript
date: Sun, 28 Jun 2015 18:24:49 GMT
etag: W/"547f1bdc-5267"
expires: Sun, 12 Jul 2015 18:24:49 GMT
last-modified: Wed, 03 Dec 2014 14:19:08 GMT
server: nginx/1.8.0
Обратите внимание на то, как ответ сервера для этих файлов сильно отличается после включения SPDY.
Общее время загрузки практически такое же.
Ожидается, что он переходит от довольно диагонального водопада к прямому вертикальному перепаду, мультиплексирующемуся в полную силу.
Но все зеленые полоски TTFB на этих js, css и изображениях увеличиваются примерно до 280 мс, а синие полоски для времени загрузки контента переходят с почти нуля на более 1 с каждая.
Подробно смотрите здесь:
Все это слишком однообразно, чтобы совпадать.
iptables не предлагает никакого троттлинга. В конфиге nginx тоже ничего не изменилось, кроме включения SPDY. Поскольку это nginx 1.8.0, это тоже не ошибка tcp_nodelay. У меня нет специальных ограничивающих конфигураций в моих файлах conf или брандмауэре. keepalive_timeout - 75, а остальные параметры поддержки активности по умолчанию.
Где мне искать? Что я могу попробовать? В чем может быть проблема?
Поскольку сейчас может возникнуть проблема с пропускной способностью, одновременно загружается до 28 ресурсов, вот график использования пропускной способности. Загрузка загруженного JS происходит между 0,7 и 2 с. За исключением странного погружения в нос, пропускная способность достигает максимума (1,5 Мбит / с), поэтому, возможно, среда хостинга также имеет здесь какое-то влияние.
Я считаю, что то, что вы испытываете, согласуется с тем, как работает SPDY.
В «старом» HTTPS браузер будет посылать запросы на сервер последовательным образом, что вы и видите на своем первом снимке экрана.
Однако с SPDY все запросы отправляются одновременно, после чего сервер отвечает файлами в том порядке, который он считает оптимальным. Это то, что вы видите на втором снимке экрана - обратите внимание, что начало всех запросов происходит в один и тот же момент времени.
Порядок, в котором сервер доставляет запрошенные файлы, зависит от конфигурации сервера, но, что более важно, от приоритетов ресурсов. Идея состоит в том, чтобы отправить файлы JS и CSS заранее, чтобы сайт можно было раскрасить. После этого SPDY должен отправить изображения и другие ресурсы.
Потому что вы указываете, что время DOMContentLoaded
и load
не сильно отличается между SPDY и HTTPS, я думаю, ваш сервер работает правильно. Если вы хотите сократить время рисования, подумайте о расстановке приоритетов.
Источники и очень интересное дальнейшее чтение:
Как указано в комментариях ниже, JayMcTee обнаружил, что его конкретная ситуация была вызвана пропускной способностью - поскольку SPDY выполняет все запросы одновременно, пропускная способность будет легче заполняться, что приведет к более медленным отдельным запросам, чем при последовательном выполнении.