Framehole: лазейка PageSpeed ​​6.0 для легкого идеального счета

Каждый хороший веб-разработчик знает, что PageSpeed ​​Insights от Google и Lighthouse с открытым исходным кодом, используемые за кулисами, являются самыми современными инструментами, помогающими определить относительную производительность веб-сайта. Они также предлагают ключевые идеи о том, какие изменения вы можете внести, чтобы улучшить эту воспринимаемую скорость. PageSpeed ​​стал золотым стандартом измерения скорости и скорости в Интернете.

Нет ничего плохого в том, что сами Google теперь отслеживают этот показатель PageSpeed ​​для каждого веб-сайта и используют его в качестве одного из многих входных данных, чтобы определить, кто попадает в верхнюю часть результатов поиска, а кто сослан в чистилище на 10-й странице.

Целая индустрия и многие миллионы долларов переходят из рук в руки только для того, чтобы оптимизировать и улучшить этот показатель в надежде приблизиться к недостижимому идеальному результату 100. Новейший выпуск PageSpeed/Lighthouse 6.0 включает в себя новый набор предпочтительных показателей для разработчиков во всем мире. для оптимизации. Эти новые метрики: самая большая отрисовка содержимого (LCP), совокупное смещение макета (CLS) и общее время блокировки (TBT). У Google есть целая статья, объясняющая эти новые «Web Vitals», которая отлично справляется с подробным описанием того, как они измеряются.

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

TLDR: PageSpeed ​​больше не учитывает влияние на скорость сторонних встраиваний, таких как YouTube и реклама.

Если вам просто нужна суть, ответ заключается в том, что последние изменения Google придают большой вес самой крупной содержательной краске. Это измерение того, сколько времени требуется для появления самого большого элемента на экране при загрузке веб-сайта. Это хороший показатель восприятия пользователем скорости загрузки. Проблема в том, что Largest Contentful Paint не учитывает какой-либо встроенный контент, даже если этот контент технически квалифицируется как самый большой элемент в верхней части сгиба.

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

Например, это может показаться абсурдным, хотя и не маловероятным, учитывая, насколько важным стал показатель PageSpeed. Мы улучшаем показатель PageSpeed ​​веб-сайта с 60 до 100, просто создавая iframe для исходной медленной версии веб-сайта. Быстрые команды только для подтверждения результатов находятся здесь, но читайте ниже, чтобы увидеть, как пользователь, оптимизирующий свою оценку, продвигается к нашему окончательному решению Framehole.

 # Verify you have the new Lighthouse 6.0 installed npm install -g lighthouse # This one should have a score somewhere around 60 :( lighthouse https://webvitalsfail.b-cdn.net/ --view # Instantly to 100 lighthouse https://webvitalsfail.b-cdn.net/anything-100.html --view

Танец кошек v1 - Ссылка

Это простой пример веб-сайта, показывающий типичную промо-страницу для нашего мобильного приложения «Танец кошек». Он включает в себя очень крутой анимированный gif для демонстрации танцующих кошек, которые вы получаете, установив наше готовое к печати приложение на свой телефон. Теперь давайте проверим оценку Lighthouse 6.0 для этого веб-сайта:

Вау, 60 баллов — это больно для таких успешных людей, как мы. Как этот простой сайт мог быть таким медленным, если верить Google? Давайте сосредоточимся на «Самой большой отрисовке контента», поскольку это одна из новых метрик, представленных в этой версии.

Это очень полезно, так как рекомендует использовать видео для анимированного контента и показывает нам, что элемент Largest Contentful Paint — это анимированный gif наших танцующих кошек. Круто, давайте перейдем к:

Танец кошек v2 - Ссылка

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

Ну, это, безусловно, движется в правильном направлении. Мы улучшили результат на 14 баллов, просто переключившись на mp4 для анимации наших замечательных танцующих кошек. Переход от LCP со 104,9 с к 9,9 с, безусловно, является существенным улучшением. Но нас не устраивает оценка 74. Это как оценка «С», а мы — группа отличников.

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

Танец кошек v3 - Ссылка

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

Подождите секунду, эти ребята просто гении, они подняли мой рейтинг PageSpeed ​​до 99. Должно быть, мы действительно напортачили с нашим кодированием видео, чтобы получить 76 баллов, верно?

Что-то здесь не так? В предыдущих версиях танцующие кошки всегда были самым большим элементом на экране. И глядя на скриншоты из этого теста, видно, что видео в этой версии все еще такого же размера. Так почему же утверждается, что текст нашего <h1> является самым большим элементом? Ответ находится в описании Google метрики «Самая большая содержательная отрисовка». Этот показатель включает в себя самый большой элемент, включая видео, изображения, SVG, НО НЕ IFRAMES.

Чего ждать? Это не может быть правильным. Если iframe является самым большим элементом и загружается медленно, как патока, это не имеет значения... не считается! Таким образом, iframes похожи на волшебные черные дыры производительности, в которые мы можем встраивать наши медленные или большие элементы, и они не повлияют на нашу оценку производительности. Ни за что! Давайте попробуем это.

Танец кошек v4 - Ссылка

Чтобы проверить нашу теорию, мы вернемся к нашему точному сайту версии 1 с большим анимированным gif и всем остальным. Мы внесем только одно изменение. Давайте загрузим анимированный gif в iframe и посмотрим, что произойдет с нашей оценкой PageSpeed.

Святое дерьмо... может это действительно решение? Мы просто берем любые проблемы, вызывающие снижение скорости веб-сайта, добавляем их в iframe, затем БУМ, больше никаких проблем. Я имею в виду, что мы знаем, что на самом деле это не меняет скорость загрузки, потому что это тот же файл, того же размера, только что загруженный в iframe. Точно так же, как это произошло при использовании встраивания YouTube, на самом деле это не сильно изменило скорость. Кажется, что фреймы — это просто волшебные порталы, позволяющие превзойти показатель PageSpeed ​​Score.

Но необходимость перемещать все наши медленные элементы в фреймы - это своего рода головная боль...

Cat Dance v5 - Ссылка на рамку

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

Что, если мы поместим весь сайт в iframe? Таким образом, наше решение будет отделено от фактической кодовой базы сайта. Мы могли бы даже делать такие вещи на периферии или в NGINX, полностью отделяя это от воздействия на любой существующий код.

Наша v5 — это просто страница из v1, помещенная в пустую обертку. Тот же большой анимированный gif, без оптимизации. И теперь мы перешли от 60 к 100. Это святой Грааль, и с реальным веб-сайтом не нужно ничего делать.

это глупо

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

Помните, PageSpeed ​​— это золотой стандарт веб-производительности. Google даже использует эту оценку для своего алгоритма. Если вы никогда не слышали от клиентов, что они хотят узнать, как ваш продукт влияет на их показатель PageSpeed, значит, вы недостаточно общались с клиентами. Им не все равно, потому что это волнует Google , а оценка должна что-то значить. Посмотрите, сколько слов мне понадобилось, чтобы объяснить это, и представьте, что вы говорите покупателю, что он ошибается в отношении того, что ваш продукт замедляет работу сайта, а упрощенная и понятная оценка PageSpeed ​​провозглашает, насколько вы неправы.

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

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

Если оценка совпадет с этими веб-метриками, то мы получим сеть, которая заинтересована вернуться к лоскутному сайту с огромной рекламой и сторонними встраиваниями, полностью игнорируя стоимость скорости этих элементов. Не сомневайтесь, что найдутся люди, которые реализуют iframeing всего сайта именно так, как указано в этой статье, потому что руководство хотело максимально возможного показателя PageSpeed ​​Score.

Поведение формируется тем, как мы ведем счет