Как стать автором
Обновить

Комментарии 19

В http/1.0 и http/1.1 для каждого отдельного файла создаётся отдельное соединение

Это наброс на вентилятор
HTTP 1.1 использует коннекшины повторно
HTTP/1.1 defaults to the use of «persistent connections», allowing
multiple requests and responses to be carried over a single
connection. The «close» connection option is used to signal that a
connection will not persist after the current request/response. HTTP
implementations SHOULD support persistent connections.
Справедливое замечание, но тем не менее при использовании http/2 соединений создаётся меньше.

Не все так однозначно. У меня было такое, что по http 1.1 картинка из теста https://http2.akamai.com/demo загружалась быстрее, чем по http 2.

На счёт количества соединений всё однозначно, их меньше в http/2. На счёт скорости загрузки страницы могли сыграть роль разного рода факторы. К примеру:
— наличие отсутствие ssl и его конфигурирование
— поддержка конкретным браузером http/2 и корректность его работы на нём. Например раньше всё было не на столько гладко, а сейчас я ставлю http/2 на все сайты с ssl.

Посмотрел ссылочку, разница и правда в пользу http/1.1, только есть одно «но», обрати внимания картинки в http/2 в данном тесте грузятся не параллельно, а последовательно. Вполне естественно что если контент грузится последовательно то на скорость загрузки будет влиять количество потоков, а в http/1.1 их больше. Тот кто делал этот тест хотел чтобы http/2 проиграл. Если бы картинки грузились параллельно то http/1.1 был бы медленнее.

В этом тесте всегда включен https.
Http2 мультиплексирует несколько логических запросов/ответов в один tcp connection.
Есть один stream, внутри него несколько запросов и ответов.

Я вижу что он включен всегда, я первую часть комментария не адресовал конкретно этому тесту.

Вот скрин того как грузятся картинки с одного из подконтрольных мною сайтов. Загрузка идёт в одном потоке и начинается одновременно.
image

А вот скрин того как грузятся картинки в этом тесте.
image
Тут видно что хоть и поток так же один, но картинки грузятся последовательно. При такой подаче контента http/2 проиграет, но таким образом не подаётся контент нигде среди тех сайтов с которыми я работал. Поэтому я и сказал что тут явно хотели чтобы http/2 проиграл. Не знаю что это за сайт, но на нём даже настройка ssl проведена не совсем верно, промежуточный сертификат имеет не безопасную подпись.

P.S. Конечно в каждом конкретном случае требуется индивидуальный подход к настройке, но могу сказать что в большинстве случаев http/2 будет показывать результаты лучше. Хотя как видно из теста исключения всё же есть, но чтобы учесть все индивидуальные случаи статьи тут не достаточно, сразу книгу надо писать.
тут видно что хоть и поток так же один, но картинки грузятся последовательно
Параллельно? Можно, например, четные байты от одной, нечетные — от другой. Но быстрее суммарная загрузка вряд-ли отработает (но TCP congestion control, возможно, потратит меньше служебных данных!)

Я не знаю, где на Ваших картинках можно посмотреть детали про tcp, я плохо понял, что там все должны увидеть в плане анализа tcp. Если у h2 или http/1.1 подвести мышку к ячейке из столбца waterfall, то видно момент «Queued at» и «Started at» у разных спрайтов разное в пределах одного протокола. Но никаких указаний на используемый tcp stream я не вижу, научите меня, пожалуйста, где смотреть тут! Обычно я для просмотра такой информации использую wireshark

Есть интересное письмо на тему http2 в varnish cache (объясняют, почему не хотят имплементить http2. Уже заимплементили)

По моей статистике этого теста, по http2 картинки грузятся быстрее. Попробуйте использовать другие устройства, другого провайдера, думаю, Вы измените мнение, что «тут явно хотели чтобы http/2 проиграл».

Есть видео, где akamai рекламирует свою реализацию http2 push (я не уверен, что push может помочь http2 начать выигрывать у http1 ещё больше)

Производительность сайта зависит от многих факторов, включая режим работы MIMO.

На всякий случай, вот rfc7540.html. Вдруг я неправ.
>> Параллельно? Можно, например, четные байты от одной, нечетные — от другой. Но быстрее суммарная загрузка вряд-ли отработает (но TCP congestion control, возможно, потратит меньше служебных данных!)

Именно параллельно.

>> Я не знаю, где на Ваших картинках можно посмотреть детали про tcp, я плохо понял, что там все должны увидеть в плане анализа tcp. Если у h2 или http/1.1 подвести мышку к ячейке из столбца waterfall, то видно момент «Queued at» и «Started at» у разных спрайтов разное в пределах одного протокола. Но никаких указаний на используемый tcp stream я не вижу, научите меня, пожалуйста, где смотреть тут! Обычно я для просмотра такой информации использую wireshark

Я смотрю на потоки которые отображены в верхней частиесли выделить промежуток потока(соединения) можно увидеть сколько файлов в этот промежуток грузилось. Так вот в тесте файлы по началу ещё грузятся параллельно, но потом переходят в последовательную загрузку. Вероятно может быть проблема в моём не шустром интернете, ну так я и акцентировал в статье внимание именно на такие устройста, слабые и с медленным инетом. Потому как на быстрых и тупые варианты будут норм)

>> Есть интересное письмо на тему http2 в varnish cache (объясняют, почему не хотят имплементить http2. Уже заимплементили)

Может меня сейчас кто-то начнёт закидывать палками, но я не использую его. Поэтому это для меня как бы не имеет значения. Я всё проворачиваю в самом nginx. Не могу сказать на сколько верно я поступаю, надо будет на днях сравнить мой способ с Varnish. Отпишу по результату сюда в комменты, если результаты будут интересными даже дополню статью.

>> По моей статистике этого теста, по http2 картинки грузятся быстрее. Попробуйте использовать другие устройства, другого провайдера, думаю, Вы измените мнение, что «тут явно хотели чтобы http/2 проиграл».

У меня слабый инет, не с проста я вообще так увлечённо занимаюсь ускорением сайтов) Всё благодаря ему)))

>> Есть видео, где akamai рекламирует свою реализацию http2 push (я не уверен, что push может помочь http2 начать выигрывать у http1 ещё больше)

К сожалению не силён в английском, по возможности уделю время изучению этой темы. У меня пока тут кой-чего поинтереснее нарисовалось. Отрабатываю новый способ кэширования.

>> Производительность сайта зависит от многих факторов, включая режим работы MIMO.
На всякий случай, вот rfc7540.html. Вдруг я неправ.

Да ты прав, просто расставляешь акценты не так как я, мы оба по своему правы) Расстановка акцентов думаю зависит от того какие у кого проекты были за плечами, я в связи со своими проектами посчитал что их лучше расставить так, у тебя видимо чуть по другому. Не суть я думаю. Да и в любом случае я же не выключаю на сайтах http/1.0 и http/1.1 вот это было бы конечно не верно. Все три протокола работают параллельно, браузер сам выбирает какой использовать)
Varnish не ставят на работу с клиентами, его рекомендуют прятать за nginx, так что абсолютно не играет роли умеет он http2 или нет, ведь с клиентом общается не он, а nginx.
Я бы добавил «Используйте активное содержимое страниц тогда и только тогда, когда это удобно в первую очередь пользователю». Не Вам, не из-за моды, а только тогда, когда будет падать юзабельность.
Я упомянул это, только не так явно.
Возможно избавиться от загрузки каких-то не нужных элементов, и по возможности отсрочить загрузку js или поместить их в конец ну или хотя бы сделать их загрузку асинхронной. CSS тоже, кстати, было бы неплохо оптимизировать.
Я имел в виду более жёстко: иногда достаточно статики. Вот совсем статики. Если по клику выскакивает (извиняюсь, плавно выплывает) здоровая форма для заполнения, может стоить редирект на отдельную страничку именно с этой формой, а не тонну js на выскакивание и собственно заполнение? Или про чат-окна «напишите нам, специалист онлайн!»: если специалист гарантированно не онлайн, потому что в локации магазина полночь, может, это окно просто не грузить?
Согласен, встречаются отдельные сайты где js столько что волосы дыбом становятся, а браузер нагружает процессор на 100% при открытии сайта. Эти проблемы должен решать грамотный верстальщик, я как уже писал в статье им не являюсь, поэтому не стал лезть в область в которой не смогу дать понятных рекомендаций, а только дал общие.
Маленькая поправка: Google PageSpeed ругается, если сайт грузится более 200мс, а не 300.
Писал на память, моя оплошность. Сейчас поправлю информацию в статье.
На самом деле для большинства маленьких сайтов, с портфолио и сайтов-визиток, смысла в этом мало, хотя и радует глаз
такие вот вещи




Есть предположение что эта оценка влияет на поисковую выдачу, так что это точно не бесполезно.
PageSpeed

Никогда не юзал для своих сайтов, но сталкивался раз 5 с клиентами, которые имели проблемыина сайтах. Не работал ajax, не так стили выводились, не грузились информеры, скирпты, картинки с удаленных.
Каждый раз решал отключением этого модуля, переписывающего файлы и названия всего, что видит.
На нормальную разборку времени не было, за анализ не платят)

Не подскажите, такие проблемы возникают при непоавильной настройке модуля или плозого кода? Или эта штука вообще запрещена доя сложных сайтов и не работает на них?

У этой штуки очень жирная документация, когда Вы её просто включаете, то врубается стандартный набор фильтров, а там кроме него ещё 2 варианта набора фильтров + можно полностью в ручную конфигурировать. То что с дефолтными настройками бывают проблема для меня это не новость. Правда достаточно редко, всё таки дефолтные расчитаны на то что они подойдут максимальному количеству сайтов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации