Что на самом деле влияет на результат Google PageSpeed Insights и к чему приведет выполнение всех его рекомендаций

Статья написана с целью помощи в спорах о зеленой зоне PageSpeed между клиентами и разработчиками, которые порождаются как минимум некорректной трактовкой результатов сервиса. Я постарался кратко и наглядно изложить суть.


Для начала развею миф о том, что оценка сервиса — это скорость загрузки.


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


Результаты продемонстрирую на примере анализа сайта midapro.shop
В ходе проверок сайта обратил внимание на очень интересный момент.


Сервис выдает все время разные результаты. Посмотрим на скриншоты ниже.



Через полминуты, запустил тест снова, ничего не меняя на сайте.



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



Проведем тест еще раз.



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


Но пойдем дальше, проверим, что скажет сам браузер о скорости загрузки.


Согласно данным в “Инспекторе разработчика” в браузере,
сайт прогрузился за 2.3 секунды, за 3.3 секунды завершилась загрузка всей страницы:



При том, что на странице 4 слайдера, крупные баннера и легкая анимация.


Посмотрим подробные данные от pagespeed.



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



Однако для мобильной версии, он насчитал 8.7 секунд.



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


Далее перейдем к рекомендациям. Что советует сделать гугл, чтоб уменьшить скорость загрузки?



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


Скриншоты сайта до изменений и после.



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


Посмотрим как изменился результат после выполнения рекомендаций.



Стало конечно лучше, грузиться то теперь нечему, кроме картинок.


Но есть рекомендации и по ним.



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



Как видно первый формат, не поддерживает ни один браузер, кроме Safari.
Второй формат не поддерживает вообще никто.
Третий формат не поддерживается в Safari.


О выводах судить только вам, лично у меня цензурных слов на эту рекомендацию вряд ли хватит.


Далее гугл рекомендует снова что-то удалить..



… при этом еще ниже в разделе “Успешные аудиты” он говорит, что код CSS и JS оптимален и все лишнее удалено.



Это уже противоречие самому себе в открытом виде.


Под конец я вернул сайт в изначальное состояние и провел тест в четвертый раз:



На что похожи эти результаты снова сказать сложно… что-то между 2 и 3 тестом.


По тестированию скорости загрузки используя секундомер, через 3G, скорость загрузки сайта составляла 3 секунды.


Вывод


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


Зеленая зона возможна при отказе от использования cms(движка/админки сайта), при отказе от использования видео, особенно youtube, и использования множества больших изображений.


Ну и напоследок, протестируем сайт компании Google.


Similar posts

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 73

    +3

    Основная проблема вашего сайта описана тут:


      0
      Это что-то меняет?)
        +1
        Да. Выполняем это, выполняем рекомендации, но с умом (отдаём webp всем крома сафари и IE), избавляемся от moment (или хотя бы сжимаем), убираем анимацию при появлении — если не сейчас, то завтра гугл будет снимать свои фантики за это.

        Новый Pagespeed не про скорость загрузки, как было раньше, а про скорость вообще. Не поверите, но выполнение яваскрипта (тупо компиляция без полезной нагрузки) занимает время. Особенно такого монстра, как moment. В вашем случае это 50%. Ну, и вёрстку попроще (по возможности).

        Ну и библиотеки почистить. Вот зачем на списке туфель нужен bootstrap date time picker? (это риторический вопрос).
          0
          webp тоже не обязателен. Покрутил я его, повертел. Так себе формат, разве что как прозрачный jpg годится, а нормально сделанный jpg ему не уступает (pagespeed на такой не ругается) уж на градиентах так еще и выигрывает.

          Особо бесит, что легче всего подсовывать webp через вебсервер по юзер-агенту, а если без этого, нативно, то если через picture можно задать браузеру на выбор файл, то, млять, для свойства background-image почему-то забыли сделать аналогично. Выходит толку от полумер нет никаких.

            0

            У вас правда все фото на сайтах содержат по 3 формата фотографий, как рекомендует гугл?

              0
              Такие вещи легко решаются с помощью разных imgproxy, достаточно хранить оригинал
        +7
        В рекомендации «Устраните ресурсы, блокирующие отображение» ключевым моментом, на котором нужно сконцентрироваться, является не слово «устраните», а слово «блокирующие». Т.е. вам предлагается не удалить все ваши важные файлы, а загружать их так, что они не блокировали отображение.
        Со знаниями и анализом такого уровня, как у вас, вам рановато еще писать статьи про инструменты оптимизации загрузки сайтов.
          –2
          Что так же скажется на работоспособности сайта))
          Как ни крути, итог не меняется.
            +2
            Вы удивитесь, но итог меняется. Простейший пример — это станица, у которой css подключен через тег link в секции head. После загрузки html кода страницы, во время парсинга браузер встречает тег link, понимает, что это внешний ресурс который надо загрузить и останавливает парсинг до момента, пока ваш css не будет полностью загружен. Для page speed эта ситуация — блокировка отображения. Пользователь при этом будет видеть просто белый экран и так же ждать загрузки css.
            С другой стороны, если вы уберете link из head и разместите в конце html кода простенький js, который добавляет в секцию head тот же link с теми же параметрами и с той же ссылкой на css, то работа браузера изменится — он загрузит и распарсит весь html, а только потом приступит к css, который добавлен вашим кусочком js. Это напрямую повлияет и на скорость отображения сайта и на значения, которые вам покажет page speed. Пользователь при таком подходе увидит текстовую составляющую страницы сразу же, не дожидаясь загрузки css.
            Есть и более эффективные методы работы с css. Этот пример только для наглядности.
              0
              Я прекрасно понимаю о чем вы говорите и о какой блокировке идет речь в page speed.
              Но показывать пользователю процесс подгрузки шрифтов и тд, по моему субъективному мнению, плохо, он должен увидеть окончательно сформированную страницу сайта.
              А еще можно придумать много чего, что улучшит показатель page speed, вопрос в том, как это влияет в итоге на сайт.
              Но даже это никак не перечеркивает суть статьи.
                0
                Вы уж простите, но статья в теперешнем ее виде очень поверхностна и ничего не дает сообществу. С другой стороны, если вы изобрели какую-то технику оптимизации, которая ускоряет сайт для пользователя, но плохо оценивается в page speed, это было бы интересно.
                И еще, относительно субъективного мнения. Есть метрики, например показатель отказов. Или время на сайте. Если вы говорите, что заботитесь о пользователе, то это можно легко проверить. При каком подходе показатель отказов будет меньше? По вашему или когда виден «прогресс подгрузки»? Объективное решение можно принять только с цифрами в руках. Тестируете.
                  0

                  Объективное решение можно принимать с цифрами в руках, однако вы уже решили за все сообщество о полезности статьи.
                  В статье указана цель написания, она будет полезна не всем, как и любая другая статья.
                  Если вы гоняетесь за зеленой зоной, это ваше дело, этим занимаются далеко не все, т.к. достижение зеленой зоны не всегда улучшение сайта, да и порой бесполезная трата времени.
                  Если вам не ясна цель статьи, можно просто пропустить) Кому она была полезной, сохранили и пошли дальше.
                  А по поводу показателя отказов, можно ведь поинтересоваться фидбеками от специалистов по рекламе и продвижению.
                  Мне, как пользователю сайта, не нравится предложенный вами вариант с эстетической точки зрения.
                  У каждого свои подходы к работе, успешность которой, лично я, оцениваю в прибыли клиента с его нового сайта.

                    –1
                    Ну, тут можно ставить оценку статье. На данный момент я вижу совокупную оценку статье "-1". Т.ч. да, на мой взгляд сообщество склоняется к тому, что статья бесполезна.

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

                      Статья как статья, бывали здесь и похуже. В целом понимаю автора и в некоторых моментах разделяю его негодование. Что вы скажете например на то что гугл рекомендует в PageSpeed удалить с сайта гугл аналитику?

                        0
                        И, сука, ютуб ролики, интеграцию которых сам же и разрабатывает!
                          0
                          Ага, или вот это нововведение — «Удалите неиспользуемый JS» — и как это интересно сделать когда в проекте используется (как минимум) Vue или React (и гугл/фб аналитика туда же) и да, 90% фреймворка не нужно в шапке сайта, но только пользователь прокрутит на 2 миллиметра — этот JS потребуется. Бомбардировать сервер кучей запросов объёмом на 500 байт JS'a при всем этот лейзли-лоаде и постоянных микроподгрузках? А если у пользователя фиговый интернет и пинг в районе 200? У него весь ваш сайт будет в лоадерах что его явно не порадует
                            0

                            Прочитайте, пожалуйста, что конкретно вам пишет гугл:

                              0
                              Вы про don't directly affect? А если indirectly affect это что то меняет? Или вы считаете что Google не учитывает объём скачанного и пропарсенного JS в своих метриках?
                                0

                                Ключевое слово вам даже жирным выделили.

                            0
                            Посмотрите тут — www.youtube.com/watch?v=4JS70KB9GS0
                          –1
                          Скажу, что гугл аналитику с умом надо подключать, как и любой другой сторонний скрипт. У меня не ругается.
                            +1
                            Ссылку скиньте на свой сайт, плиз. Посмотрим как он у вас «с умом» подключен. Может вы его ещё и смогли закешировать на 365 дней как того требует гугл?
                              0
                              А зачем мне вам помогать? Вы же лучше и умней меня, а я и то догадался.
                                +1
                                Хаха, ну я в принципе другой реакции и не ожидал))) Всё с вами ясно
                                  –1
                                  Классика. ))) Бесплатный совет — меньше думайте обо мне и больше о подключении аналитики. )
                          0
                          Если разработчик не фрилансер какой-то, а член команды, которая работает над развитием этой самой коммерческой деятельности, то поверьте, о ее результатах делятся еще как, что еще и в интересах этих самых деятелей)
                          Видимо мир немного шире, чем вы его себе представляете)
                            0
                            Даже если другой член команды по работе имеет доступ к таким данным клиента, то поделившись ими с коллегами он поступил минимум неэтично.
                              0
                              Вы прям знаете, кто с кем делится))
                                0
                                Про плоскую иерархию, открытость информации и акции для разработчиков вы наверное вообще не слышали. Вы случайно не в СНГ гос. структуре работаете?
                      +1
                      Боже мой, теперь я понимаю, почему стало так много сайтов, которые сначала отображают вроде годным образом контент, а потом начинаются пляски шрифтов и блоков по экрану… Пока всё не дозагрузится.
                        0
                        Ну, в новой версии page speed появилась метрика CLS (совокупное смещение макета). Ее высокое значение снижает общий результат. Т.ч. теперь на тех сайтах, что следят за технической оптимизацией, такие «пляски» прекратятся или будут сведены к минимуму.
                        0

                        link можно поместить в конец страницы без всяких is и работать будет точно так же. Link можно оставить в хеде и добавить аттр async — суть та же. В любом случае когда сайт грузит текст, потом все прыгает после загрузки стиля, — неприемлемо.
                        Со знаниями и анализом вашего уровня ещё рановато оценивать уровень других людей.

                          0
                          Вау, я поискал, но не нашел стандарта, который описывает поведения, что допустимо использовать async для стиля, только метод такой и такой 2020 метод, странно, что вы не проверяете информацию, а потом упрекаете других. Если я не прав, то пожалуйста, можете скинуть ссылку, что описанный вами метод действительно поддерживается стандартом.
                        0
                        Не скажется. Итог меняется. Просто стили становятся инлайновыми (
                          0

                          И ради чего все в итоге?)

                            0
                            При клике на ссылку всё переключается мгновенно, не дождаясь css и без «белого экрана». Скину в личку пример.
                            0

                            Все упирается в то, что сайту ни холодно, ни жарко, да есть разница, видит клиент голый текст сначала, либо видит красивую страницу. Но сайт как грузился свои 2 секунды, так и грузится, никаких 8 там нет)

                        +3
                        Думаю комментировать не нужно, что гугл рекомендует удалить жизненно важные файлы для сайта.

                        Гугл ничего подобного не рекомендует.
                        Он лишь рекомендует встроить наиболее приоритетные css/js в html, которые отвечают за первый экран, который видит пользователь зайдя на сайт/приложение, их как правило называют критическими.
                        Если перейти по ссылке рядом с рекомендацией Вы можете убедиться в этом сами.
                          0
                          рекомендует встроить наиболее приоритетные css/js в html

                          Да, но не всегда нужно следовать этой рекомендации.

                            0

                            Было бы здорово, если Вы подкрепили свой аргумент хоть одним примером.

                              0

                              Каждую страницу нужно отдельно рассматривать.
                              На сайтах (особенно на cms) как правило css/js на всех страницах одинаковы (конечно не всегда так но в большинстве случаев). И что теперь на каждой странице в html встраивать?
                              Я считаю что правильнее все такие css/js собрать в all.css и в all.js и http/2 сервер пушем отдавать. Никакого страшного замедления при первом посещении сайта от этого нет, но зато при дальнейшей навигации по сайту в клиенте уже всё закешировано будет и сайт для пользователей будет "быстрым".
                              Посмотрите как у меня:


                              https://webpagetest.org/result/200817_JE_3a7d46b4168c2d39fce1979d12de497f/

                                0
                                Собрать весь css/js в один файл не сработает в случае большого приложения, когда 200к+ js строк кода.
                                В Вашем случае это подходит, разумеется, нужно отталкиваться от проекта.
                          0
                          С изображениями тоже просак, если уже думать то можно организовать отдачу как и jpeg для сафари, так и webp для остальных, и то и то сейчас делается почти из коробки.
                            0
                            С изображениями всё ок. Есть несколько механизмов, позволяющих сделать всё средствами «из коробки», абсолютно рабочих. Начиная с того что можно разным браузерам отдавать разные страницы и заканчивая всякими srcset/picture и скриптами
                              0
                              srcset/picture

                              где вас поджидает облом, когда вы будете подключать аналогично через background-image и не найдете решения :-)
                                0

                                Оно в комментарии, на который вы ответили

                                  0
                                  Как то уже можно посовывать jpg в бекграунд если браузер не умеет в webp?
                                      0
                                      есть единственный нормальный способ решать это на серверной стороне через настройки вебсевера, речь шла о клиенте.
                                        0
                                        На стеке есть решение на js как определять поддержку webp.
                                          0
                                          Это полный изврат тянуть эту логику во фронт. У меня ресурсы в css прописаны, я че буду патчить еще js-ом css-ку? Да ну нафиг. Лучше уж таким хаком обойтись и не морочить голову, пока браузеры не разродяться.
                                          github.com/vincentorback/WebP-images-with-htaccess

                                          html5 стандартоделы внедрили поддержку обратной совместимости для img нативно, а для background-image — нет!
                                            0
                                            Это html5-стандартоделы и css-стандартоделы разные группы людей. )
                                            Пачить css js-ом не надо. Просто при сборке отдельный css для webp сделать. Есть и другие варианты, например через data-атрибуты. Можно наверно и еще что-нибудь более удобное придумать.
                                            И вы уж определитесь — речь шла о клиенте или о сервере.
                                              0
                                              о клиенте, но раз нету нативного способа, полифилы не рассматриваю как и игры с лишней обвязкой html аттрубитов, это априори уже зло. Лучше конфиг сервера задать для отдачи графики а на своей стороне просто делать дубли jpg файлов в webp. Меньше логики — всегда лучше.
                                          0
                                          Конечно, ведь в телефонах батарейки безлимитные, а интернет и процессорное время ничего не стоит. Лучше увеличивать нагрузку на всех и говорить что так им хорошо.
                                            –1
                                            picture
                                            source

                                            не жрет батарейку
                                0
                                А лучше вообще не извращаться и сделать нормальный jpg изначально (почистив из него техническую информацию типа EXIF и подобрав подходящий % качества). Никакой магии у webp нет, там сжатие за счёт неестественных искажений картинки (вместо квадратов jpg).
                                  0
                                  webp сжимает раза в 2-3 после того как пожали jpg png. Это существенно. Можете показать неестественные искажения webp?
                                    0
                                    PNG вообще lossless формат, им обычно не фото сжимают, а элементы интерфейса, чтобы не искажались.

                                    webp может и сжимает, но какой ценой?

                                    Можно визуально сравнить, например, здесь: xooyoozoo.github.io/yolo-octo-bugfixes/#pont-de-quebec-at-night&jpg=m&webp=m

                                    (Там ещё можно менять форматы для сравнения. Потребуется что-то на основе хромиума)

                                    Лично я предпочитаю равномерную деградацию изображения, а не одна часть так, а другая эдак, что и даёт искажения…

                                    Поэтому ещё и отключаю «психовизуальные» оптимизации в сжатии видео — там похожий результат.
                                      0
                                      Это глупости полные. Когда вы лично сраните jpg из фотошопа и webp именно ручками выбирая приемлимый коэфицент компрессии вы увидите, что jpg не уступает.

                                      Учитывая, что webp не умеет сжимать хорошо градиенты, например у вас небо или фон на сайте перелив плавный — он летит в топку со своими лишними десятками килобайт для отображения этого. Если бы не градиенты, его можно было бы использовать. Но большинство жмет на автомате 70% и тупо не запаривается.
                                        0
                                        Попробовал на градиенте. Webp — 2,24кб, jpg — 12,5кб. ЧЯДНТ?
                                        Заголовок спойлера
                                        image
                                          0
                                          проводите тесты, выставляя одинаковые коэфиценты сжатия, вместо визуального подбора и смотрите на размер
                                            0
                                            Там одинаковые коэффициенты — 0.75, на скрине видно.
                                            Вот оригинальная картинка
                                            Заголовок спойлера
                                            image

                                            Вот сылка на сервис — squoosh.app
                                            Попробуйте сами.
                                              0
                                              Мое сообщение выше можно прочитать двояко — виноват, я в нем указывал что коэфиценты нельзя брать за констранту. Она тут может быть только одна — ваше восприятие, при котором вы сами говорите, что изображения максимально равны по степени компрессии.

                                              1. Сжимаете в webp максимально, когда вам ниже уже не нравится результат.
                                              2. Сжимаете в MozJPeg до аналогичной степени.
                                              3. Сравниваете размер.
                                              Или же наоборот, выставляете одинаковый размер ползунками и сраниваете результат.

                                              Попробуйте в сервис закинуть это
                                              hsto.org/webt/sd/1z/uc/sd1zucxcsxgzve5ivgw8drmo5bk.png

                                              И посмотреть на центральные артефакты в webp при 0.99 которые появляются сразу.

                                              webp 0.96/ MozJpeg 91 — размер максимально сопоставим — кто победитель?
                                              очень и очень спорны преимущества webp.

                                              ps. на вашем файле выигрывает webp.
                                  +1
                                  Самое печальное, что обычно этот сервис нужен только одним ребятам — SEOшникам.
                                  Они требуют от Заказчика исполнения ВСЕХ рекомендаций этого инструмента, а если ты начинаешь примерно как автор статьи справедливо возмущаться, то… Им же только этого и нужно, похоже, т.к. на невыполнение требований гугла можно списать все неудачи SEO.
                                    0
                                    С сеошниками надо не воевать а сотрудничать. А сеошников-шаманов (особенно которые в договоре позиции гарантируют) надо избегать, как коллег и как исполнителей.
                                      0
                                      SEOшников вы не выбираете — их выбирает Заказчик. А любовь к подобным инструментам у всех SEOшников, которых я встречал.
                                      Любовь или нелюбовь тут ни при чём. Я выше всё вполне чётко написал. Если хоть где-то красненькое — всё, это из-за этого, а не из-за того что SEO не может гарантировать результат.
                                        0
                                        Ну это уже говорит об профессиональности сеошника)
                                        На фрилансе рил, каждый сеошник кидает пейдж спид, хоть и не каждый настаивает на зеленой зоне. Я работаю с сеошниками, которые дают отличные результаты, а пейджспид не кидали мне ни разу))
                                    0
                                    Разные результаты чаще всего вызваны разным временем ответа сервера, особенно при большом числе запросов, когда таких серверов становится 10-20. Ни на одном из своих сайтов не видел разброса больше 1 балла.

                                    Пост о том как попытка выполнять инструкции без понимания приводит к ухудшению ситуации
                                      0
                                      about.google/intl/ru

                                      Раз уж на то пошло, продемонстрируйте результаты самого гугла)
                                      В статье я фиксировал 31. Сейчас 40.
                                      Давайте уж без сказок, а по факту, если и писать)
                                        0
                                        35 запросов на 6 доменов по этой ссылке.
                                        Такое себе в плане стабильности.
                                        0
                                        Я так почитал комменты, у всех все так здорово, кто-то картинки в трех форматах всех грузит, кто-то разброса не видит, ну ну))) Все так идеально на словах, а президент Кореи в туалет не ходит, тоже слышали такое =)
                                        Давайте уж как-то на Землю спустимся, ибо факты говорят об обратном.
                                        +1
                                        Про не совпадение таймингов -> у серверного Insight включен троттлинг для тестов мобильной версии. На сетевую активность и на процессор.
                                        Throughput: 1.6Mbps down / 750 Kbps up. Latency: 150ms. Процессор замедляется в 4 раза.

                                        Only users with full accounts can post comments. Log in, please.