Спасибо за статью!
Добавлю свои 5 копеек: поддержка браузерами формата — в основном это Chromium-подобные браузеры и Android: http://caniuse.com/#feat=webp, что больше половины трафика.
Перевели больше 10 сайтов на HTTP/2, никаких проблем с индексацией нет. На счет склейки зеркал (установки основного зеркала в Вебмастере) есть задержка. Оставьте 301 редирект с HTTP на HTTPS и подождите примерно месяц, основной адрес обновится. Также полезно добавить HTTPS версию как отдельный сайт (у Гугла то же самое). На время перехода может снизиться трафик, после переиндексации все восстановится.
А зачем 2?
Это ж ссылка на один и тот же файл по нормальному.
Я не специалист по Apparmor — у меня заработало так, можете поэкспериментировать.
А если размер БД таблиц порядка ТБ? Сервер не ляжет?
Думаю, ляжет. По крайней мере, нужно не надеяться на нормальную работу сервера в это время. Время апгрейда таблиц будет зависеть от количества изменений для каждой таблицы.
Обратите внимание, что это TCP-соединения. А значит, для получения данных на полной скорости каждому соединению нужно пройти процесс TCP Slow Start, время которого зависит от величины RTT. Поэтому использование одного соединения в HTTP/2 и даёт прирост скорости, особенно на каналах с большим RTT.
Про небольшие интернет-магазины: подавляющее большинство можно ускорить в 2-3 раза без использования CDN (оптимизация кеширования, картинок, JS). Не надо микроскопом забивать гвозди.
Интересно, как вы обходите случаи, где ресурс формируется с учетом браузера пользователя (например: Google Fonts). Также нужно как-то отслеживать, нет ли обновлений ресурса на сервере-источнике (например, какой-нибудь JS-API социальных сетей).
По-моему все ровно наоборот. Первый раз слышу о дороговизне отдачи либ с хостинга… Трафика они требуют совсем чуть с учетом сжатия и правильного кеширования.
Вообще зачем нужен CDN: для географической близости к пользователю и разгрузки каналов сервера, то есть как раз для средних и крупных коммерческих сайтов.
Здесь нужно смотреть, какая CDN и какой выигрыш от использования. Если это коммерческий сервис, в котором вы уверены, можно грузить прямо с него и не думать — риск будет небольшим. А вот если нет — лучше будет со своего сервера. Недавний пример из практики: CDN для ускорения Битрикса (встроенная фича, на основе CDNVideo) положила сайт (пришлось отключить).
Inline CSS — это уже очень тонкая оптимизация. По-моему, так стоит делать только, если основной CSS в сжатом виде весит больше 10 кб. Если меньше, то скорее всего HTML и этот CSS уложатся в первые 10 TCP-пакетов (15 кб), то есть загрузка этой части будет достаточно быстрая.
Согласен, лучше глазами смотреть при хорошо тормознутой сети. В этом плане даже Speed Index не спасает — он тоже считает пиксели и не учитывает работоспособность интерфейса.
Объясните пожалуйста как перенос скрипта вниз страницы уменьшит скачиваемые трафик?
Общий трафик никак, трафик до начала рендеринга страницы: на размер ресурса.
Вам не кажется, что вы себе противоречите?
Для мобильного пользователя как раз перерисовка и повторное вычисление всех стилей будет очень даже ощутимо.
Я думаю, что перерисовка и вычисление стилей будет быстрее выполнения JS-кода и тем более быстрее сети (особенно мобильной). Это как общее правило. А на самом деле нужно тестировать в реальных условиях (на устройстве, с ограничением скорости сети).
Добавлю свои 5 копеек: поддержка браузерами формата — в основном это Chromium-подобные браузеры и Android: http://caniuse.com/#feat=webp, что больше половины трафика.
Я не специалист по Apparmor — у меня заработало так, можете поэкспериментировать.
Думаю, ляжет. По крайней мере, нужно не надеяться на нормальную работу сервера в это время. Время апгрейда таблиц будет зависеть от количества изменений для каждой таблицы.
Вообще зачем нужен CDN: для географической близости к пользователю и разгрузки каналов сервера, то есть как раз для средних и крупных коммерческих сайтов.
Общий трафик никак, трафик до начала рендеринга страницы: на размер ресурса.
Я думаю, что перерисовка и вычисление стилей будет быстрее выполнения JS-кода и тем более быстрее сети (особенно мобильной). Это как общее правило. А на самом деле нужно тестировать в реальных условиях (на устройстве, с ограничением скорости сети).