Новый атрибут Loading для тега IMG и LazyLoad

lazy load

Новый атрибут Loading для тега IMG и LazyLoad

Содержание

Тезис 1 — об обновлении систем сканирования

Цитата:

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

Реальность

В настоящий момент Google ничего не обновил. И тем более сейчас он не будет обновляться параллельно с браузером.

Фактически есть только:

  1. Одно  заявление Google  о том, что процесс якобы запущен и находится на стадии тестирования.  https://webmasters.googleblog.com/2019/05/the-new-evergreen-googlebot.html 
  1. Update от 07.08.2019 

Второе заявление о подключении новой версии к ресурсам тестирования типа мобайл френдли и т.д.

https://webmasters.googleblog.com/2019/08/evergreen-googlebot-in-testing-tools.html

Никакого отношения к индексации это не имеет

  1. Факт того, что 99% проектов не видят никаких изменений в технологии сканирования страницы, а значит перехода с 41 версии не произошло.
  1. Информация,  от людей имеющих отношение к инсайдерам

Сообщение в блоге WebMaster-ов породила массу слухов и высосанных из пальца новостей. 

Причина тому, неоднозначность самого заявления из которого, например, совершенно непонятно о чем идет речь — о первой стадии индексирования, или о стадии когда проходит индексирование с использованием JS логики.  

Изменение первой фазы интересно той категории людей которые верстают страницы используя технологии, которые не понимает 41 версия.  

Изменение второй фазы  ждут те несчастные SEO специалисты, которые пытаются что-то сделать с проектами, где рендеринг происходит на стороне клиента (Angular, React, Vue и т.д.)

На текущий момент,  нет ни одного подтвержденного случая использования ботом версии старше 41. Проверяется это не по UserAgent, но по тем технологиям которые бот использует при индексации. Например CSS Variables или Grid.

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

Итог

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

Официальные заявления носят неоднозначный расплывчатый характер. 

update : В системах тестирования (проверка структурированных данных, проверка микроразметки) действительно появился рендер 70+ версии. Но к индексатору это не имеет никакого отношения.   

Аналитика которую можно смело не читать

Никакого изменения в ближайшее время, связанного с первой фазой индексирования НЕ БУДЕТ.  А это 90% всей индексации.

Замена 41 версии на 70+ произведет взрыв ядерной бомбы и потрясет весь индекс, что является очень большим риском. 

А теперь вспомним, как при меньших рисках поступал Google. 

Например Mobile First Index, ввод которого продолжался больше  двух лет и до сих пор не закончен. 

При этом, у него была подушка безопасности — а именно сам по себе Mobile Index существовал уже до этого, и изменился только приоритет. То есть в условиях намного более безопасных для Google как для компании, запуск технологии шел более двух лет. 

Конечно я могу ошибаться, и это было бы логично, вести параллельный индекс c 2016 года — с момента появления CSS Variables. Которые позволили крутить индексатором и в хвост и в гриву тем, кто понимает что делает.  

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

Особое мнение одного уважаемого мной человека

Сильным преувеличением следует считать факт того, что введение новой версии потрясет весь индекс. По простой причине — большая часть сайтов не использует возможности недоступные 41 версии хрома. А это значит, что позиции проектов серьезно не изменятся.

Я с этим отчасти согласен, но тезис дает больше вопросов чем ответов. 

Чем тогда продиктована такая серьезная задержка (4 года) с переходом?

Тезис 2 — Движок рендеринга входит в систему сканирования сайтов 

Как работает сканирование

Сканирование сайтов происходит в два этапа:

  1. Первый, связан с привычным всем алгоритмом сканирования, работающим с момента запуска гугла. А именно попытка понять для чего страница, анализируя только HTML код, и прочие внешние факторы.  За все время эволюции этой фазы, к ней был добавлен добавлен только крайне примитивный способ определения — видим ли блок или нет. Никакого полноценного рендера страниц в этой фазе нет.
  1. Второй этап, это как раз этап с полноценным рендером и выполнением JS кода.  Именно обновления его и ждут Angular React и прочие проекты с Client Based системой формирования страниц. 

Ирония заключается в том, что вторая фаза, даже получив обновленный движок рендера, который позволит корректно формировать отображения описанных выше сайтов, наступает ОЧЕНЬ РЕДКО. На небольших проектах, из тысячи страниц, наблюдать этого бота удается чуть ли не раз в месяц.  А проекты за сотни тысяч страниц, наверное не видят его никогда.

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

Чтобы это увидеть наглядно, воспользуйтесь chrome в headless режиме и замерьте потребялемые ресурсы. 

Или простым опытом:

  1. Создать страницу, в теле которой будет одна единственная фраза.
  1. В страницу добавить JS код, который по событию DOM Ready производит полную замену исходной фразы на совершенно другую. 
  1. Отправить страницу в индекс.
  1. Наблюдать изменения в поиске по заданной фразе 

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

Итог

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

В силу того, что у Google не хватает ресурсов даже для оперативной обработки Медиа материалов (Изображения, Видео), ждать изменений в сторону полноценного  рендера можно только обладая изрядной долей оптимизма. 

Тезис 3 — Теперь поисковые оптимизаторы имеют возможность использовать на сайтах новый атрибут loading для ускорения загрузки страниц. 

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

LazyLoad, как и реализация его через атрибут loading, не влияет на ускорение загрузки страниц.

Современная парадигма тестирования производительности страниц, не связана с объемом трафика, который будет потрбелять устройство посетителя, во время посещения страницы.  

Чтобы убедиться в этом,  проведите простой эксперимент:

  1. Создать html страницу содержимое которой будет какой-нибудь текст.
  1. В страницу  встроить изображение  посредством тега <img>.   В атрибут src указать URL на изображение большого объема, например  в 20МБ. Позиционировать изображение так, чтобы оно оказалось за пределами первой области видимости.

Например position:absolute; top:10000px;

  1. Запустить PageSpeed и посмотреть результат в баллах.

Результат будет не менее 99 баллов, вне зависимости от того, какого объема изображение будет добавлено. Что прямо указывает на несущественность для метрики, общего объема потребляемого трафика. 

Почему? 

Страницы с высоким баллом, это страницы, которые  дают возможность посетителю, ознакомиться с контентом в условиях когда:

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

Зачем же тогда нужен LazyLoad? 

Современные проекты давно ушли за рамки простого текста.  Они содержат массу JavaScript логики, которая напрямую может зависеть от  того — загружены ресурсы, нужные для отображения первого экрана, или нет.  Загрузка этих ресурсов, может напрямую зависеть от ресурсов не связанных с первой областью отображения.

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

То есть LazyLoad нужен для случаев, когда выстраивание логики работы проекта невозможно без получения события window.load, то есть события загрузки всех ресурсов. 

Именно в этих случаях 20мб изображение отложит инициализацию работы скриптов на время,  необходимое для его(изображения) загрузки. 

И наоборот, если логика не завязана на подобные события, то LazyLoad не будет иметь какого-либо влияние на производительность. 

Итог

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

Важное замечание

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

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

Тезис 4 — Сторонние решения для LazyLoad не могут обеспечить нужного функционала, и создают массу проблем.

Цитата:

Ранее для реализации ленивой загрузки на практике требовалось использовать сторонние решения. Минусы таких решений в следующем — увеличивается размер сайта из-за использования дополнительных скриптов; Возрастает сложность поддержки, не поддерживается индексация поисковой системой.

Разберем заявленные минусы.

Увеличение размера сайта

Код, обеспечивающий минимально необходимый функционал для работы LazyLoad, сейчас занимает не более 2 килобайт текста в несжатом виде. В сжатом виде — около 700 байт.

Решайте сами, 700 байт это достаточный объем для того, чтобы обозначить это как существенный минус?

Сложность поддержки

Из-за простоты реализации такого кода,  у проекта больше шансов получить проблемы от своей верстки при выходе новой версии браузера, чем от современных реализаций LazyLoad.

Не поддерживается индексация поисковой системой

Откуда ноги растут

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

В коде страницы, изображение (то есть тег <img>)  в атрибуте src (который должен указывать на изображение)  вместо ссылки на изображение ставят либо заглушку, либо вообще ничего. 

<img src=»img_1x1.gif» data-image=»my-image.jpg»>

Когда же изображение попадает в область видимости, JavaScript логика в атрибут SRC помещает ссылку на оригинальное изображение. В обозначенном выше примере, она лежит в атрибуте data-image

В результате, когда приходит бот в своей первой фазе индексирования, то есть тот который не исполняет JS, он получает html, внутри которого будет масса <IMG> тегов ссылающихся на 1×1 .gif картинку. 

То есть,  с точки зрения SEO,  мы получили большую проблему.

Когда это не проблема

Со времен Internet Explorer 6 версии, то есть с 1995 года, любой LazyLoad построенный на базе JavaScript логики,  мог быть реализован таким образом, что проект не испытывал никаких проблем с индексацией.

Реализовывалось это, за счет вставки тега <noscript> содержащего <img> с src атрибутом на оригинальное  изображение.

<noscript><img src=»ссылка на оригинал изображения»></noscript> 

т.к. первая фаза индексации, происходит без выполнения JS скриптов, бот подхватывает изображение размещенное в теге <noscript>

С  2014 года, когда появилась глобальная поддержка атрибута srcset у тега IMG, необходимость в noscript отпала полностью. 

Итог

Скрипт для LazyLoad, написанный с учетом потребностей поискового робота, не создает и не создавал никаких проблем в индексации. Поддержкой такого скрипта может заниматься любой человек, который не боится html разметки. Издержки на его работу, с 2014 года практически нулевые.

Тезис 5 — Атрибут loading решает все приведенные выше проблемы. 

Цитата:

Атрибут loading решает все приведенные выше проблемы. Применяя атрибут loading можно загружать данные по требованию, используя возможности движка браузера. В результате сайт будет открываться быстрее, а Googlebot проиндексирует такие изображения.

Какие проблемы на самом деле решает

Как видно из разбора Тезисов 1-4, проблем которые бы решал loading — нет.

Какие проблемы создает

Напротив, текущая реализация атрибута loading создает следующие проблемы:

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

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

Атрибут loading заставляет браузер скачивать по 2 килобайта каждого изображения где он установлен,  для того чтобы определить ширину и высоту изображения, для коррекции верстки страницы. То есть фактически, создавая ровно столько новых соединений сколько у вас изображений на странице. Что создает как лишнюю нагрузку как на сам сервер, так и на саму страницу.   

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

Атрибут loading — неуправляем. Невозможно сейчас никаким образом повлиять на его поведение. Браузер сам решает что ему делать или не делать. Логика работы с такими изображениями сейчас неуправляема, и захардкорена в коде браузера. Единственная возможность менять его поведение атрибутами lazy, eager, auto имеет смысл только в случае использования JavaScript чем перечеркивает саму суть работы атрибута.

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

Итог

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

Он ровно так же бесполезен для любого проекта, который использует корректный LazyLoad код. 

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

О поддержке браузерами

Цитата

В перспективе атрибут loading будет поддерживаться всеми популярными браузерами. Такая поддержка стала возможна по причине использования общих стандартов.

Поддержка атрибута loading будет только в браузерах, которые построены на базе Chromium. 

Никаких перспектив в поддержке этого атрибута другими браузерами — НЕТ. 

Никаких общих стандартов для этого атрибута так же НЕТ. 

Ни Safari, ни FireFox заниматься этой спецификацией в ее текущем виде не будут, в силу ее полной бесполезности. 

Справедливости ради стоит сказать, что браузеры на базе Chromium это больше 70% рынка. 

Почему вообще все это случилось

О необходимости реализации технологии LazyLoad на уровне браузера, говорилось с момента, когда была сформирована сама идея этого процесса. 

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

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

Люди бросились формировать спецификации,  писать черновики стандарта… 

В результате, был выпущен атрибут loading, разработчики которого не только проигнорировали  ВСЕ рекомендации, но и умудрились сделать так, что даже в рамках валидного html кода, атрибут не работает так, как они сами ожидали.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *