Что вы делаете чтобы получить хороший балл на google page speed, и нужно ли вообще заботиться об этом?

Question

[integoneo]

Я в первый раз загрузил свою верстку на хостинг и получил плохой балл на Google page speed (хостинг - бесплатный). Хотелось бы иметь хороший балл.



В сборку у меня входили:

• Минификатор Uglify js
  
• Минификатор CSS - Clean css
  
• Imagemin
  
• gulp-webp и функция, которая меняет фоновые изображения формата jpg и png на webp, если браузер является webkit
  

Возможно мне стоит изменить сборку? Что я могу сделать что бы получить хороший балл? И нужно ли мне думать об этом, пока я еще новичок во фронтенде?

Comments

[smilingcheater]

Вы уверены, что у вас корректно работает функция подмены webp? Открыл через хром, вижу в сетевых запросах что сначала стягивается /img/service2.png, затем после срабатывания скрипта стягивается ещё и /img/service2.webp
Могу порекомендовать либо подменять на стороне сервера, либо использовать тег picture с перечислением разным источников source type="image/webp" и source type="image/png" например - браузер сам разберётся что грузить.

[smilingcheater]

Ещё считаю спорным решением добавлять в футер интерактивную яндекс-карту. Она не мало весит, и выполняет значительный объём JS. На каждой странице, даже на тех где пользователь до футера не долистает. Либо поставить статику, либо хотя бы добавить lazy-загрузку.

Answer 1

[Алексей Уколов]

Что я могу сделать что бы получить хороший балл?

Там ниже на странице есть список конкретных рекомендаций и пояснений.

И нужно ли мне думать об этом, пока я еще новичок во фронтенде?

Нужно, но не очень усиленно. Многие вещи проще сделать на старте проекта, а для этого о них нужно знать. Если вы потратите сейчас пару часов на разбор каждой рекомендации Лайтхауса, вы довольно сильно поднимете свой уровень в этом вопросе.

В реальности очень много зависит от клиента - они могут не захотеть делать нормальные изображения, отключать или откладывать загрузку сторонних скриптов (Я.Метрика + Живосайт легко могут сожрать 20 баллов сами по себе).
Но разработчик должен делать всё, что в его силах, для улучшения результата. У вас, например, ради карты в подвале грузится полмегабайта скриптов Yandex API, что блокирует сайт на 4 секунды. Разумеется, её нужно грузить лениво, когда человек реально туда доскролил.

Answer 2

[Eugene Chefranov]

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

И верстка влияет процентов 10. Остальное часть бэка и сервера.

На Wordpress я добился таких баллов:

spoiler

Comments

[Алексей Уколов]

И верстка влияет процентов 10. Остальное часть бэка и сервера.

Ну, нет. У автора, например, проблема в конских неоптимизированных картинках и тяжёлых скриптах. Это именно вёрстка. Конечно, бэкенд имеет значение, но как раз 99% проверок Лайтхауса - это фронтенд.

[integoneo]

Алексей Уколов, как мне еще оптимизировать картинки и скрипты, ведь я же уже использую imagemin и Uglify js , или этого недостаточно?

[Алексей Уколов]

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

Answer 3

[xmoonlight]

Я всегда делаю 100/100.
Разумеется, свой фреймворк.
Никаких проблем с тем, чтобы выполнить все требования, у меня не возникало.

Относительно поисковой выдачи: гугл ОЧЕНЬ ЦЕНИТ! труд вебмастеров, которые соответствуют его правилам оптимизации кода сайта и серверных настроек.

Проблема у Вас в том, что код должен быть "чистым" ДО разных минификаторов и оптимизаторов.
Тогда, они могут и не понадобиться от слов совсем+никогда... (я ими не пользуюсь вообще, т.к. не могу полностью контролировать логику исполнения минификации, да и зачем?...)

Comments

[Алексей Уколов]

А действительно, зачем полностью контролировать логику исполнения минификации?
Нет ни одной причины её, минификацию, не использовать.

[xmoonlight]

Алексей Уколов, причина есть: она нередко портит исходный код... (меняет!)

[Алексей Уколов]

За 10 лет моей профессиональной деятельности минификатор не сломал мне ни строчки.

Если минификатор портит код, это значит, что он не может его понять. А раз он не может его понять, то проблема в 99.999% случаев в коде, а не в минификаторе.

[xmoonlight]

Алексей Уколов, не спорю, но странно, что браузеры - могут, а минификатор - нет.
Поэтому, я или редко юзаю свой минификатор, или вовсе не юзаю никакой... (что чаще всего..)

[Алексей Уколов]

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

Можете привести конкретные примеры? Интересно посмотреть.

[xmoonlight]

Алексей Уколов,

потому что если у пользователя не работает страница, он винит в этом браузер, а не её разработчика.

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

Можете привести конкретные примеры? Интересно посмотреть.

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

Answer 4

[Владимир Коротенко]

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

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

Comments

[Алексей Уколов]

Всё перечисленное решается автоматической генерацией нужных картинок (ретина, webp и т.п.) из одного исходинка и использования <picture/>. Клиенты, правда, часто не готовы за это платить, но чисто технически никаких проблем.

[Владимир Коротенко]

Алексей Уколов, Клиенты если лезут в лайтспид должны быть таки готовы, или это мусор а не клиенты(С).
Что впрочем не отменяет всего этого.

[Алексей Уколов]

С чего бы это они вдруг "мусор"? Можно разбираться в технических деталях и метриках и при этом накладывать их на метрики бизнеса, чтобы понимать, что целесообразно, а что нет.
Да и не обязаны они разбираться - мы всегда предлагаем сами такое решение, объясняя плюсы и минусы.

[Владимир Коротенко]

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

Но вот так что бы заявить вот это нужно сделать, такого не бывало. Собственно к этой категории и фраза.