Требуется ли объединение ресурсов в SPDY для сокращения времени отклика?

Здесь я использую термин объединение для обозначения объединения ресурсов JS и CSS вместе для уменьшения количества HTTP-запросов. HTTP/2 в первую очередь решает основные проблемы, которые породили лучшие практики веб-разработки по объединению ресурсов (время прохождения туда и обратно, блокировка выборки ресурсов). Однако насколько SPDY, широко распространенный в настоящее время, разделяет эти характеристики с HTTP/2?

Если я использую CDN с поддержкой SPDY, например CloudFlare, есть ли смысл больше объединять ресурсы, если мне не нужно заботиться о устаревших клиентах?

Обратите внимание, что транспиляция ресурсов может выполняться отдельно от объединения, и этот вопрос в основном касается времени отклика, а не компиляции кода.


person Mikko Ohtamaa    schedule 15.05.2015    source источник


Ответы (1)


HTTP/2 (и его предшественник SPDY, который в настоящее время выводится из эксплуатации) клиенты могут выполнять большее количество одновременных запросов к серверу, чем клиенты HTTP/1.1.

Там, где HTTP/1.1 может выполнять только от 4 до 8 одновременных запросов за раз, HTTP/2 обычно может выполнять до 100.

Объединение ресурсов было в основном обходным путем для этого ограничения HTTP/1.1, и в HTTP/2 оно больше не требуется.

Единственные причины, по которым я могу придумать продолжение объединения, может заключаться в повышении эффективности сжатия ресурсов gzip (но это должно быть измерено для количественной оценки преимуществ - и они могут быть очень небольшими, если вообще есть) или для другие причины применения.

Если вас не интересуют устаревшие клиенты, в типичном случае вы можете избежать объединения ресурсов при использовании CDN с поддержкой HTTP/2.

Это должно упростить сборку вашего веб-приложения (больше нет необходимости в фазе связывания) без потери времени отклика, но единственный способ убедиться в этом — измерить ваш конкретный случай.

person sbordet    schedule 16.05.2015