Оптимизация кэширования файлов и HTTP2

Наш сайт рассматривает возможность перехода на http2.

Я понимаю, что http2 делает методы оптимизации, такие как конкатенация файлов устаревшими , поскольку сервер, использующий http2, просто отправляет один запрос.

Вместо этого совет, который я вижу, заключается в том, что лучше хранить размеры файлов поменьше, чтобы их можно было кэшировать браузером.

Вероятно, это зависит от размера веб-сайта, но насколько мал должен быть файл веб-сайта, если он использует http2 и хочет сосредоточиться на кешировании?

В нашем случае наши многочисленные отдельные js и css-файлы попадают в диапазон 1kb до 180kb. Jquery и bootstrap могут быть больше. В совокупности, новая загрузка страницы на нашем сайте обычно составляет менее 900 кб.

Поэтому у меня есть два вопроса:

Являются ли эти размеры файлов достаточно маленькими для кэширования браузерами?

Если они достаточно малы для кэширования, хорошо ли вообще конкатенировать файлы для пользователей, которые используют браузеры, которые не поддерживают http2.

Было бы больно иметь большие размеры файлов в этом случае И использовать HTTP2? Таким образом, это принесет пользу пользователям, выполняющим любой протокол, потому что сайт может быть оптимизирован как для http, так и для http2.

Давайте проясним несколько вещей:

Я понимаю, что http2 делает методы оптимизации, такие как конкатенация файлов устаревшими, поскольку сервер, использующий http2, просто отправляет один запрос.

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

Однако есть аргумент счетчика, что все еще есть накладные расходы с несколькими файлами, включая их запрос, кеширование, чтение их из кеша … и т. Д. Он значительно сокращен в HTTP / 2, но не полностью ушел. Кроме того, gzipping текстовые файлы работают лучше на больших файлах, чем gzipping множество небольших файлов по отдельности. Лично, однако, я думаю, что недостатки перевешивают эти проблемы, и я думаю, что конкатенация будет вымирать, как только HTTP / 2 будет вездесущим.

Вместо этого совет, который я вижу, заключается в том, что лучше хранить размеры файлов поменьше, чтобы их можно было кэшировать браузером.

Вероятно, это зависит от размера веб-сайта, но насколько мал должен быть файл веб-сайта, если он использует http2 и хочет сосредоточиться на кешировании?

Размер файла не зависит от того, будет ли он кэшироваться или нет (если мы не говорим о действительно массивных файлах, больших, чем сам кеш). Причина, по которой разделение файлов на более мелкие куски лучше для кеширования, заключается в том, что если вы внесете какие-либо изменения, любые файлы, которые не были затронуты, все еще могут быть использованы из кеша. Если у вас есть весь ваш javascript (например) в одном большом файле .js, и вы меняете одну строку кода, тогда весь файл нужно снова загрузить – даже если он уже был в кеше.

Аналогично, если у вас есть карта спрайтов изображений, это отлично подходит для уменьшения загрузки отдельных изображений в HTTP / 1.1, но требует, чтобы весь спрайт-файл снова загружался, если вам когда-либо понадобится отредактировать его, чтобы добавить, например, дополнительное изображение. Не говоря уже о том, что все это скачено – даже для страниц, которые просто используют один из этих спрайтов изображений.

Однако, говоря все это, есть мысль о том, что говорят о пользе долгосрочного кэширования. См. Эту статью и, в частности, раздел кэширования HTTP, который показывает, что кеш браузера большинства пользователей меньше, чем вы думаете, и поэтому вряд ли ваши ресурсы будут кэшироваться очень долго. Это не означает, что кеширование не имеет значения – но более того, это полезно для просмотра на этом сеансе, а не в долгосрочной перспективе. Поэтому каждое посещение вашего сайта, скорее всего, будет загружать все ваши файлы снова, если только они не являются очень частым гостем, имеют очень большой кеш или не занимаются поиском в Интернете.

полезно ли вообще конкатенировать файлы для пользователей, которые используют браузеры, которые не поддерживают http2.

Возможно. Однако, кроме Android, поддержка браузера HTTP / 2 на самом деле очень хорошая, поэтому, скорее всего, у большинства ваших посетителей уже включен HTTP / 2.

Сказав это, нет никаких дополнительных сокращений для конкатенации файлов по HTTP / 2, которых еще нет в HTTP / 1.1. Хорошо, можно утверждать, что несколько небольших файлов можно загружать параллельно через HTTP / 2, тогда как более крупный файл нужно загружать как один запрос, но я не покупаю его, что замедляет его. Никаких доказательств этого, но кишки чувствуют, что данные все равно должны быть отправлены, так что у вас есть проблема с пропускной способностью в любом случае, иначе вы этого не сделаете. Кроме того, накладные расходы на запрос многих ресурсов, хотя и значительно сокращены в HTTP / 2, все еще существуют. Задержка по-прежнему является самой большой проблемой для большинства пользователей и сайтов, а не для полосы пропускания. Если ваши ресурсы не являются действительно огромными, я сомневаюсь, что вы заметили разницу между загрузкой 1 большого ресурса в моем браузере или теми же данными, разделенными на 10 небольших файлов, загружаемых параллельно в HTTP / 2 (хотя вы бы в HTTP / 1.1) , Не говоря уже о проблемах с gzipping, о которых говорилось выше.

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

Было бы больно иметь большие размеры файлов в этом случае И использовать HTTP2? Таким образом, это принесет пользу пользователям, выполняющим любой протокол, потому что сайт может быть оптимизирован как для http, так и для http2.

Абсолютно не повредит. Как упоминалось выше, есть (в основном) отсутствие дополнительных недостатков для конкатенации файлов по HTTP / 2, которых не было уже в HTTP / 1.1. Это просто не так необходимо по HTTP / 2 и имеет недостатки (потенциально уменьшает использование кеширования, требует шага сборки, затрудняет отладку, поскольку развернутый код не такой же, как исходный код … и т. Д.).

Используйте HTTP / 2, и вы по-прежнему увидите большие преимущества для любого сайта – кроме самых простейших сайтов, которые, скорее всего, не улучшатся, но также не будут иметь никаких негативов. И, поскольку старые браузеры могут придерживаться протокола HTTP / 1.1, для них нет недостатков. Когда, или если вы решите прекратить внедрение HTTP / 1.1, настройки производительности, такие как конкатенация, являются отдельным решением.

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

**** Редактировать Август 2016 года ****

Этот пост с изображения, сильно связанного с полосой пропускания, недавно вызвал интерес к сообществу HTTP / 2 как один из первых документированных примеров того, где HTTP / 2 был на самом деле медленнее, чем HTTP / 1.1. Это подчеркивает тот факт, что технология HTTP / 2 и понимание все еще новы и потребуют некоторой настройки для некоторых сайтов. Нет такой вещи, как бесплатный обед! Стоит прочитать, хотя стоит иметь в виду, что это экстремальный пример, и большинство сайтов гораздо сильнее влияют на производительность, проблемы с задержкой и ограничения соединения по HTTP / 1.1, а не проблемы с пропускной способностью.

  • Есть ли причина в производительности для объявления параметров метода final в Java?
  • MySQL: самый быстрый способ подсчета количества строк
  • Есть ли разница в производительности между циклами for и циклом for-each?
  • В каких сценариях замораживание объектов WPF значительно повышает производительность?
  • Студия Android занимает слишком много памяти
  • Как измерить производительность моего цикла digest's AngularJS?
  • Почему putImageData так медленно?
  • Почему я должен использовать CDN от Google для jQuery?
  • Почему Skylake намного лучше, чем Broadwell-E для однопоточной памяти?
  • Оптимизировать запрос структуры сущности
  • Рисование поэтапно в UIView (iPhone)
  • Давайте будем гением компьютера.