Как раз понятно: браузер одновременно инициирует несколько соединений (это HTTP 1.1), при этом никаких тикетов или кэша сессий на этот момент нет, поэтому полный хэндшейк.
В DNS-запросе никакой катастрофы нет — это 2RTT, в идеале было бы 1RTT (150 мс).
Для первых ресурсов это не поможет. Для тех, которые внизу ватерфола — да. Первые ресурсы и так запускаются на загрузку браузером как можно раньше, то есть браузер увидит эти хинты почти одновременно с обнаружением их в HTML.
Так загрузка с холодным браузером (без кэша и подключения) и есть самый критичный момент в скорости, который нужно тестировать.
Задержки вызваны тем, что используется частичная загрузка с CDN (в данном случае с самодельного и без HTTP/2), но картинку это никак не меняет. Избежать этих задержек можно было загрузкой всего контента с одного домена по HTTP/2.
Понятно. Интересно было бы как контрольный образец взять какой-нибудь lowend (Xeon E3) физический сервер в ваших бенчмарках — например, для тех, кто планирует переезд в облака или обратно.
Что вы имеете в виду под «обслуживать»? По чипкору я так понимаю это тот же селектел, но ограничены методы оплаты и конфигурации на десктопных процах (еще меньше трафика, чем в обычном Селектеле), не думаю, что там есть какая-то разница в уровне услуг…
Если интересно, недавно запилил собственный бенчмарк с PHP-FPM, Apache mod_php и Nginx Unit. Спойлер: результаты отличаются от этой статьи. Видео бенчмарка
Как правило, саботаж выражается в полном отказе от коммуникаций, а не предъявлении требований и замечаний. С замечаниями хоть как-то можно работать, а с полным отрицанием — сложнее.
Да, мы обычно и работаем с компаниями, для которых разработка ПО это не бизнес. В этом случае либо собственные разработчики в офисе/на удалёнке или тоже аутсорс. То есть часто встречаются две аутсорс команды: новая (приглашённая) и старая (которая поддерживает проект).
Наверное такое бывает. Но, если воспользоваться простой логикой, то владельцу проекта намного проще вложить деньги в собственную команду (есть доверие, опыт взаимодействия и т.д.) То есть, приглашение второй команды обычно означает неспособность решить задачу, а это перевешивает риск и проблемы поиска.
Да, такое может быть, но только на первом этапе — начало взаимодействия. Если проблемы возникают на этапе внедрения изменений, то это скорее всего уже саботаж.
В DNS-запросе никакой катастрофы нет — это 2RTT, в идеале было бы 1RTT (150 мс).
Задержки вызваны тем, что используется частичная загрузка с CDN (в данном случае с самодельного и без HTTP/2), но картинку это никак не меняет. Избежать этих задержек можно было загрузкой всего контента с одного домена по HTTP/2.
Видео бенчмарка
По шрифтам добавьте woff и eot
Бывает и не редко, именно о таких случаях и идёт речь в статье.
Так это тоже зависит от команды, которая говорит: «закладываем часы на рефакторинг, иначе проект умрёт».
Пожалуйста, исправьте здесь и далее по тексту на килобайтные: размеры в Nginx меряются именно байтами, а не битами.