Сегодня я хочу рассказать почему достичь заветного значения практически невозможно на некоторых решения или это будет весьма затратно. Я разберу некоторые советы page speed и расскажу о них.
Используйте современные форматы изображений
В этом совете написано "Для изображений в форматах JPEG 2000, JPEG XR и WebP используется более эффективное сжатие, поэтому они загружаются быстрее и потребляют меньше трафика, чем изображения PNG и JPEG.". Этому совету, по моему мнению, соответствовать тяжелее всего по нескольким причинам.
Поддержка браузерами форматов JPEG 2000, JPEG XR и WebP
Для проверки используем caniuse, чтобы узнать поддержку форматов браузерами. На этом сайте мы узнаём, что JPEG 2000 поддерживается только safari (кроме версии для windows), JPEG XR для IE. С WebP всё лучше, но угадайте кто его не поддерживает?!) Правильно! Safari. Таким образом мы узнаём, что нет универсального формата и если вы захотите использовать их у себя то придётся грузить как минимум 2 формата. Это как минимум время, а как максимум вы доплатите дизайнеру, который делает вам баннеры.
Поддержка CMS
Конечно же, доплатить 500 рублей дизайнеру не такая уж большая проблема, но вот разобраться с CMS это не такая простая задача. На данный момент у меня получилось проверить поддержку на 3-х CMS:Wordpress, Bitrix, Joomla. Ни одна из них не поддерживает из «коробки» ни один из перечисленных форматов. На Wordpress есть несколько плагинов которые говорят, что делают webp, но по факту нет ни одного бесплатного плагина для этого. Кроме того, даже в этих случаях загрузить webp в тело статьи не удаётся, при сохранении поста ссылка на файл неподдерживаемого формата удаляется. В Битриксе даже модуля такого нет. Нужно писать самому, что для wordpress, что для битрикса. Это не простые доработки, требующие хороших знаний и достаточного количества времени.
Настройте эффективную кодировку изображений
Текст совета: "Оптимизированные изображения загружаются быстрее и расходуют меньше мобильных данных". Это очень хороший совет, но в действительности он будет всегда ругаться на «большие» картинки, даже если на «маскималках» пройтись по своим изображениям в wordpress'е плагином «Winsite Image Optimizer» на который есть ссылка в справке гугла (ссылка на imageoptim.com) то всё равно его недовольство останется.
Что остаётся делать? Лучше всего еще на «стадии фотошопа» сохранять файлы в минимальном качестве и делать это лучше всего через импорт, а не через «сохранить как». Разница в размере бывает колоссальной.
Устраните ресурсы, блокирующие отображение
Текст совета: "Некоторые ресурсы препятствуют загрузке контента страницы. Рекомендуем настроить загрузку необходимых ресурсов JS/CSS в первую очередь и отложить загрузку остальных ресурсов."
Этот совет крайне простой если работать с самописным сайтом, если вы знаете «что, где, когда». Но если речь идёт о CMS и использования плагинов и модулей то это сделать сложно. Например в Wordpress всё упирается в используемые плагины. Для решения этой проблемы придётся поковырять код плагинов и найти там как они подключают свои скрипты (и jquery в придачу). Далее с помощью wp_deregister_script убираем подключение скриптов из плагина и подгружаем их в нужном месте, где нам заблагорассудится.
Еще одним способом является сжатие скриптов и/или стилей в один файл. Этот способ действительно даёт много баллов по page speed, но по факту может замедлить отрисовку контента, а часть javascript не отработает.
Поэкспериментировав с этим способом, я увидел, что page speed показывает ухудшение параметра «Приблизительное время задержки при вводе», грубо говоря сайт на мобильных начинает тормозить. И чем больше сжать (слить в один файл / слить в один файл и минифицировать) файлы тем хуже эти параметры. То есть смартфону приходиться напрячься, чтобы это прочитать и исполнить.
Сократите время ответа сервера
Простой, как мне кажется совет, но не всегда зависит от web-программиста. Пройдитесь профилировщиком по вашему сайту и найдите тот код, который тормозит. Иногда бывает такое, что один и тот же код вызывается по несколько раз в одном и том же файле. Запишите результат исполнения в переменную и используйте её если это уместно. Используйте кэширование. Я стараюсь использовать memched, за него плачу своему хостеру от 30 до 120 рублей в месяц в зависимости от проекта. Думаю что это поможет вам.
Отложите загрузку скрытых изображений
Тест рекомендации "Чтобы уменьшить время до начала взаимодействия, рекомендуем использовать принцип lazy loading для скрытых изображений после того, как все важные ресурсы будут загружены".
Думаю что сделать это довольно просто и в интернете есть множество примеров как это сделать. Например есть хорошая статья на CSS-tricks. Для работы его кода, главное изменить атрибуты изображения. Это довольно просто. Lazy load — это хорошо, но +1 javascript файл.
В начале статьи я рассказал о довольно противоречивых советах, а к кончу перешёл к действенным. Да, конечно оптимизация кода это хорошо, но владельцы сайтов думают о прибыли и что данные преобразования приведут к увеличению прибыли через SEO.
Нужно понимать, что оптимизация кода сайта это только первый шаг в продвижении, а само поисковое продвижение эффективно только тех сайтов, где на продукт есть сформированный спрос.
P.S.
Не будьте параноиками, знайте, что для продвижения сайта по SEO должен быть сформированный спрос, удовлетворяйте потребности своих клиентов и тогда ваш сайт будет в ТОП.
Комментарии (13)
CoolCmd
02.01.2019 13:37Например есть хорошая статья на CSS-tricks.
кстати, в этой статье есть ошибка.
Note that we will ask JavaScript to select images that contain a lazy class. Once the image has loaded, we’ll remove the class because it no longer needs to trigger an event. And, once all the images are loaded, we remove the event listeners as well.
из-за нее даже загруженные изображения будут обнюхиваться и обработчики событий не будут удалены.
нужно заменить querySelectorAll на getElementsByClassName.
AlexTheLost
02.01.2019 13:48По моему вы извратили сущность, явлений. Плохо сделанное ПО по определению и не должно получать высоких оценок. А вы пишите как ужасно что какая то поделка на wordpress не может выйти на хорошие оценки и тем самым увеличить свой рейтин. Ну это и правильно най мой взгляд. Недавно выливал свой проект и делал анализ 99 мобильный(ещё не все закончил) 100 десктоп, все честно делал все элементы сам и думал о качестве.
Для плохих проектов должен быть объективный фильтр.
ninJo
02.01.2019 14:16Из интереса запустил аудит на свой любительский проект, сделанный на vuejs:
Best practices — 100% | Performance — 97%
По роду деятельности я даже не програмист, уж простите за хваставство =)
CB9TOIIIA
02.01.2019 16:14Меня больше всего во всех этих балах раздражает — внешние ресурсы. Счетчики метрики или рекламы там или с малым временем кеша или без него вовсе — минус 10-20 балов отдается на аналитику и т.п. ресурсы.
Denai
02.01.2019 18:09По старой системе измерений метрики откусывали 1-2 балла, сейчас вижу что из-за метрик стало 97. 10-20 Это плохие картинки как минимум, либо скрипты какие-то дикие, но не счётчики.
GreyStrannik
02.01.2019 20:00+1Есть простой понятный бизнесу бенчмаркинг: посмотреть характеристики по параметрам сайтов-конкурентов для конкретной ниши и сделать чуть лучше. Не идеально, а именно чуть лучше. Минимум затрат — максимум выигрыша.
Это в измеримых величинах. А в реальности всё зависит от того, как посетитель с поисковика использует сайт и возвращается ли с него в поиск для захода на сайты конкурентов — остальное для поисковика лишь вторичные половые признаки.
ThunderCat
04.01.2019 17:22Лучше всего еще на «стадии фотошопа» сохранять файлы в минимальном качестве и делать это лучше всего через импорт, а не через «сохранить как».
Может лучше через экспорт?
demimurych
04.01.2019 09:27Вся статья это очевидно такой троллинг.
Ведь не может же WEB разработчик расписаться в своей некомпетентности такими нелепыми аргументами. Судите сами:
Он и дизайнеру собрался платить за то что должен делать либо его(веб разработчика) код или код веб сервера, который легко может отдавать именно тот формат который поддерживает браузер.
И разобраться не смог как оптимизировать изображения, чтобы тест их принимал как примелемые
И лейзилоад, который занимает сейчас около 17 строк JS кода, у него лежит в отдельном JS файле.
Да и для CMS оказывается нужно писать какой-то особый магический код, который, о боже, отсуствует даже в Битриксе. Вся магия которого видимо в том, что и писать его не надо, он работает и так за счет пары строчек в конфигурации веб сервера.
Как справедливо говорили Выше, старый ВЕБ тест от Google, нет требовал от специалиста вообще никаких усилий. В том числе и в случаях, когда кто-то потребовал ровно 100 балов. Новый стал объективнее, но я даже боюсь подумать как он снесет крышу ВЕБ разработчикам, у которых проблемы описанные в статье, оказались нерешаемыми или решаемыми за большие деньги.
xakplant Автор
04.01.2019 11:09Вы явно читали статью «по верхам». Загрузить картинки в разных форматах это был один из вероятных способов соответствовать совету по использованию современных форматов изображений.
Про «справедливость» page speed'а. Запустите тест на разных компьютерах или в разное время на одном и том же и результат ни когда не совпадёт. Воспользуйтесь аудитом встроенным в браузер. Результат будет зависеть от времени суток, фазы луны и свистнул ли на горе рак.
Сбор всех js в один файл влияет на параметр «Приблизительное время задержки при вводе» о котором я говорил. Вы самостоятельно можете проверить. Мне кажется вы об этом даже не прочитали.
«За большие деньги...» Заказчики на таких биржах как kwork хотят заплатить 500 рублей за подобную работу. Это явно недостойная оплата за подобную работу.
ainu
Хе, я думал будет написано про новый PageSpeed (который актуален именно сейчас). На предыдущем то как раз можно было сделать 100/100 почти на любой системе, было бы время и настойчивость.
Сейчас много зависит еще и от верстки, и «джентельменский набор» critical css, сжатие+gzip, оптимизированные картинки уже не поможет.
Плохо сверстанный сайт так и останется в 70-75 баллах, а хорошо сверстанный получит 100 даже без оптимизаций. Стало важным оптимизировать пожирание яваскриптом времени процессора, стало важно время до первой интерактивности.
По поводу WebP немного не так. Не надо платить никакому дизайнеру за два формата, сервер должен сам считывать заголовок поддержки WebP и отдавать, пережимая «на лету» с сохранением в кеш. Работы на час для любого количества изображений.
dernasherbrezon
Для наколеночного блога пережимание может и сработает, но если картинки лежат в cdn то ничего не получится.
Sovigod
cloudflare уже пару лет умеет в онлайн конвертацию изображение в оптимальный формат. Но не бесплатно.
ainu
www.keycdn.com/blog/convert-to-webp-the-successor-of-jpeg KeyCDN тоже умеет. В любом случае (CDN или нет) — правильный выход всегда автосжатие, а не «платить дизайнеру за два баннера».