Как раз наоборот - замер PageSpeed для большинства сайтов неактуален, так как тест производится из Европы, с большими задержками до России. Использовать троттлинг в DevTools также никто не запрещает, там есть и по сети и по CPU.
С серверной стороной понятно. А клиентскую производительность тестировали? В конечном итоге клиентская часть может вносить больше тормозов, чем серверная для пользователя.
Если уж говорить про приоритезацию запросов, стоит вспомнить про буферизацию ответа на многих уровнях веб-сервера и ОС. Часто приоритеты могут не работать просто из-за большого размера буфера, который ждёт отправки.
Читаю и не покидает ощущение, что я где-то всё уже видел. И действительно, это грубый рерайт нашей старой статьи про CDN: www.methodlab.ru/articles/cdn_uskorenie_saita#cont.
Некрасиво воровать контент.
Открою масонскую тайну — первый, третий и четвертый тип CDN это одно и то же.
Четвертый и пятый отличаются не принципиально, добавляется преобразование контента во время транзита (сюда же и «защита от копирования», которое вы почему-то не указали), по сути это отдельный вид услуг, непосредственно к CDN не относящийся. Т.е. вы тут намешали разные классификации (по бесплатности, по доп.услугам, по контенту), которые могут комбинирваться с друг другом (а не противопоставляться).
Согласен, здесь скорее не чистая классификация CDN как систем, а их сценариев использования со стороны потребителя.
С чего это expires устаревший?
Может быть полезно знать, что в cache-control можно указать перевалидацию только для прокси tools.ietf.org/html/rfc7234#section-5.2.2.7.
При наличии cache-control с max-age заголовок expires игнорируется. Устаревший он потому, что появился раньше и сейчас заменяется cache-control. MDN и RFC
Это вообще про что? Расшифрование какого трафика? Более того, CDN может зашифровывать трафик.
Трафика между origin и хостом CDN. Он сначала будет расшифрован на узле CDN, потом заново зашифрован и отправлен в браузер пользователя. Но узел CDN имеет доступ к открытому тексту (HTML, например).
В данном случае использование HTTP/2 не поможет — задержка останется ровно такой же (только будет создано не 6 коннектов, а один). Насчет нормального DNS-сервера — вообще у CF «самый быстрый в мире» DNS — или вы про резолвер?
Как раз понятно: браузер одновременно инициирует несколько соединений (это HTTP 1.1), при этом никаких тикетов или кэша сессий на этот момент нет, поэтому полный хэндшейк.
В DNS-запросе никакой катастрофы нет — это 2RTT, в идеале было бы 1RTT (150 мс).
Для первых ресурсов это не поможет. Для тех, которые внизу ватерфола — да. Первые ресурсы и так запускаются на загрузку браузером как можно раньше, то есть браузер увидит эти хинты почти одновременно с обнаружением их в HTML.
Так загрузка с холодным браузером (без кэша и подключения) и есть самый критичный момент в скорости, который нужно тестировать.
Задержки вызваны тем, что используется частичная загрузка с CDN (в данном случае с самодельного и без HTTP/2), но картинку это никак не меняет. Избежать этих задержек можно было загрузкой всего контента с одного домена по HTTP/2.
Понятно. Интересно было бы как контрольный образец взять какой-нибудь lowend (Xeon E3) физический сервер в ваших бенчмарках — например, для тех, кто планирует переезд в облака или обратно.
Что вы имеете в виду под «обслуживать»? По чипкору я так понимаю это тот же селектел, но ограничены методы оплаты и конфигурации на десктопных процах (еще меньше трафика, чем в обычном Селектеле), не думаю, что там есть какая-то разница в уровне услуг…
Если интересно, недавно запилил собственный бенчмарк с PHP-FPM, Apache mod_php и Nginx Unit. Спойлер: результаты отличаются от этой статьи. Видео бенчмарка
Как правило, саботаж выражается в полном отказе от коммуникаций, а не предъявлении требований и замечаний. С замечаниями хоть как-то можно работать, а с полным отрицанием — сложнее.
Да, мы обычно и работаем с компаниями, для которых разработка ПО это не бизнес. В этом случае либо собственные разработчики в офисе/на удалёнке или тоже аутсорс. То есть часто встречаются две аутсорс команды: новая (приглашённая) и старая (которая поддерживает проект).
Наверное такое бывает. Но, если воспользоваться простой логикой, то владельцу проекта намного проще вложить деньги в собственную команду (есть доверие, опыт взаимодействия и т.д.) То есть, приглашение второй команды обычно означает неспособность решить задачу, а это перевешивает риск и проблемы поиска.
Как раз наоборот - замер PageSpeed для большинства сайтов неактуален, так как тест производится из Европы, с большими задержками до России. Использовать троттлинг в DevTools также никто не запрещает, там есть и по сети и по CPU.
Если уж говорить про приоритезацию запросов, стоит вспомнить про буферизацию ответа на многих уровнях веб-сервера и ОС. Часто приоритеты могут не работать просто из-за большого размера буфера, который ждёт отправки.
Некрасиво воровать контент.
Согласен, здесь скорее не чистая классификация CDN как систем, а их сценариев использования со стороны потребителя.
При наличии cache-control с max-age заголовок expires игнорируется. Устаревший он потому, что появился раньше и сейчас заменяется cache-control. MDN и RFC
Трафика между origin и хостом CDN. Он сначала будет расшифрован на узле CDN, потом заново зашифрован и отправлен в браузер пользователя. Но узел CDN имеет доступ к открытому тексту (HTML, например).
В DNS-запросе никакой катастрофы нет — это 2RTT, в идеале было бы 1RTT (150 мс).
Задержки вызваны тем, что используется частичная загрузка с CDN (в данном случае с самодельного и без HTTP/2), но картинку это никак не меняет. Избежать этих задержек можно было загрузкой всего контента с одного домена по HTTP/2.
Видео бенчмарка
По шрифтам добавьте woff и eot
Бывает и не редко, именно о таких случаях и идёт речь в статье.
Так это тоже зависит от команды, которая говорит: «закладываем часы на рефакторинг, иначе проект умрёт».