Обновленный PageSpeed Insights

Активно проталкивают jpeg 2000

Посмотрел - да это фигня полная - он даже не открывается у меня

Активно проталкивают WebP и AMP - свое, родное.

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

С новым PageSpeed Insights все предельно ясно.

Концепция сейчас какая? Правильно, Mobile First Index. Потому они и стресс-тестят сайты на эмуляции крайне слабой связи и на базе не самого нового смартфона.

И тут давайте по честному: топовые смартфоны у меньшинства. Связь тоже не айс в подавляющем большинстве случаем ВО ВСЕМ МИРЕ (а Гугл - глобальная система, не Москва и не Нью-Йорк, помним об этом).

Конечно, смешно, что качество связи, используемое в тесте, рассчитано на жителей лесных районов Танзании, пользующих смарты не моложе Nexus 5 (для эмуляции в DevTools Хрома в закладке Network выставьте качество связи Slow 3G и потом в Audits запустите тест Perfomance - почти оно). Но это реальность, как средняя температура по больнице.

Далее, что смотрит Гугл.

А смотрит он не СКОРОСТЬ ЗАГРУЗКИ файлов, как было совсем недавно, для этого есть теперь всего один производный показатель - Speed Index, и то косвенно связанный, так как отражает только полноту отрисованности картинки на экране (смотрим скриншоты в их отчете, все встает на свои места).

Важна СКОРОСТЬ ВЫХОДА вашего сайта В РАБОЧИЙ РЕЖИМ. То есть когда он полностью отрисован и все критичные для его функционирования элементы загружены и инициированы. И посетитель может уже с ним взаимодействовать.

А это нынче JS. Он не только грузится, он еще парсится и инициируется JS-движком браузера, на это часто времени уходит больше, чем на загрузку, в разы. О чем в отчетах (Диагностика) много, читайте.

Картинки тяжелые также занимают время основного потока. На их загрузку и растеризацию-отрисовку с ресайзами движком и т.п. тяжелыми операциями.

Сторонние виджеты (Facebook c 3...6 Мб загружаемого JS для вывода кнопки лайков - этожужас!) тоже сильно грузят. Опять же, тратится время как на выкачивание (да еще и с неэффективным сжатием и временем кеширования), так и на интерпретацию и исполнение JS движком.

Итого - выводите весь этот хлам из основного потока разбора и построения страницы.

В идеале по собственными сайтовым скриптам - не грузить разом все JS библиотеки и скрипты (тем более комбайненные в один файл), а для каждой страницы подгружать только тот набор функций, которые нужны ТОЛЬКО ДЛЯ ДАННОЙ СТРАНИЦЫ. То же самое относится и к CSS, хотя и менее критично, тут достаточно грузить необходимое для отрисовки страницы сразу в head, остальное догружать асинхронно с кешированием в догонку (и потом на остальных страницах ничего вообще грузиться не будет, из кеша по 304 возьмется).

Тут очень помогла бы модульная структура EcmaScript6, с генерацией конечного кода под конкретную страницу по правилам. Но таких решений из коробки для популярных CMS тупо нет, плагины тоже под это никто в своем уме не адаптирует, поддержка нативная браузерами хромает. В общем все сложно.

Да и на виртуальном хостинге без доступа к ОС мало чего понастроишь.

А ведь нужно еще реализовать server push и включить ssl/https + http/2 для оптимизации потоков отдачи контента браузеру. Все это существенно распараллеливает и ускоряет загрузку => браузер может быстрее перейти к разбору нагруженного в него. И выгода от HTTPS здесь не в пресловутой безопасности, а именно в работающем под ним HTTP/2.

Мысли о CDN упираются в тот факт, что все более-менее навороченные функции оптимизации начинаются от "очень дорого" на том же CloudFlare. И Rocket, и оптимизация картинок, и Server push, и прочие полезные навороты - от 200 у.е. в месяц + набегающим итогом поработное - большинство наворотов идет вне пакета, а на основе расхода ресурсов. И так на всех CDN.

И да, для CDN первична отдача контента по геопризнаку, остальные вопросы - это косвенные проекты, реализованы они зачастую весьма спорно и сомнительно. Геораздача - да. Секьюрность - ну... тоже да.

А вот скорость работы сайта... Много громких слов в описаниях, но когда дело доходит до тестирования рализации, выглядит все весьма не радужно. Оптимизация самого сайта - это не зона работы CDN. Точка.

Все эти описанные выше манипуляции существенно разгрузят парсинговый движек браузера и выход на отрисовку и интерактивность будет максимально быстрым. А значит и bounce rate сократится! Счастливый посетитель. И вот про эту единственную цель и сделаны все эти сервисы Гугла и все эти оценки. Прямая зависимость отказов от технической оптимизации сайта. Отказы по причине убогого контента - вне зоны рассмотрения, но улучшение dwell time чисто за счет получившего быстро целевой сайт посетителя - это уже СЕРПовый сигнал. С логичными дальнейшими последствиями для сайта.

Более менее универсальных проектов именно по оптимизации быстродействия сайта в сети можно перечесть по пальцам.

Я не говорю о узкоспециализированных плагинах к конкретным CMS типа W3TC для WP или аналогах. Их много разной степени навороченности и вредоносности для оптимизируемых сайтов :) Реализованных как в виде локальных плагинов с использованием возможно установленных на хостинге консольных утилит, так и в виде гейтов к онлайн-сервисам оптимизации (как PegaSaas). Но - они НЕ универсальны и опять же требуют дополнительного функционала типа того же CDN для распределенного хранения по геопризнаку или параллелизации загрузки с разных хостов. И еще наличия определенных установленных консольных утилит оптимизации на хостинге, что далеко не всегда есть.

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

Теперь немного "рекламы" готовых решений :)

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

На данный момент реализован именно блок повышения производительности сайтов (хотя в планах автоматизация еще множества других аспектов реализации сайтов - структуры, кода, перелинковки, ЧПУ, семантической разметки и т.д.)

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

Готовы предоставить доступ для тестирования системы представителям студий, работающих на Запад и имеющих достаточно большой пул клиентов, для которых очевидна необходимость технического импрува, либо частных вебмастеров с большим количеством сайтов в Бурж. Для агентств есть возможность white label сервиса.

Для небольших индивидуальных проектов ПОКА, увы, сервис предоставлять НЕ ГОТОВЫ, не стоит и беспокоиться. Массовый сервис и поддержку мы еще не готовы оказывать.

Дорвееводов тоже просьба пока :) не суетиться, врядли дружба выйдет плодотворной.

Всех интересующихся приглашаю в личку с примерами Ваших сайтов.

Кто-нибудь пробовал загрузку рекламы, которая ниже первых двух экранов на onscroll повесить? Типа чтобы до взаимодействия ее почти не грузилось.

Я пробовал сносить всю рекламу. По мобильному + 10 баллов, на ПК как было 99-100, так и есть😂

Интересный момент у хостера Таймвеб. У них давно была услуга - оптимизация скорости загрузки сайта по PageSpeed. Они просто сделали ссылку на проверку версии для ПК, а мобильный мол не учитываем)))) жулье))

Вчера сделал эксперимент (стало интересно что он там считает), убрал все счётчики (Яндекс метрика, гугланалитикс, и прочие гуглтеги), и произошло ЧУДО. Всё в зелёной зоне. Тут как бы либо убрать весь джаваскрипт и получить условно удобный сайт, либо паплевать на эти гугл пузомерки.

sPoul, вот эта вся куча букв что Вы написали -- абсолютная бессмыслица.

1) Проводим голый эксперимент. Делаем проект своими руками на PHP + JS или кому как нравится, не пользуемся громоздкими CMS и готовыми решениями. Тестим проект -- 100/100 на бесктопе и мобиле.

2) Вешаем 1 баннер Google AdSense. Десктоп остается 88-99/100, мобила падает до 67/100.

Еще доказуха нужна?!?!??!?!?

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

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

------

Для тех кто не верит. Просто снимите рекламу AdSense + Yandex Direct, уберите со страницы цитаты из Twitter, видео воткнутое в iFrame с Youtube, шрифты с Google Fonts и отключите комменты DISQUS, Facebook или что там у Вас, и Вы просто офигеете какой реактивный у Вас сайт.

---------- Добавлено 27.12.2018 в 11:32 ----------

Ну, естественно, на своей стороне надо хотябы включить GZIP и элементарное кеширование статичного контента, а тому кто заморочится и динамичного. Оптимизацию на своей стороне никто не отменял.

---------- Добавлено 27.12.2018 в 11:34 ----------

Какие 200 у.е. в месяц????!!?!? $5 облако и и 50К трафика на обычном бложике написаном на PHP. Если нужно взаимодейтсвие с пользователем, переезжаем на тариф за 10-15-20 баксов. Если контент не требует взаимодейтсвия с пользователями, кешируем его через FastCGI на стороне NGINX и сидим на облаке за $5. Подавляющее большинство сайтов на WordPress выдают именно такой контент.

Так и не должно ничего этого на нормальном сайте быть :)

Почему вы так решили?