Tags

Перевод Пришло время ленивой загрузки закадровых ltiframegt

26.07.2020 16:05:43 |

Автор: admin

Нативная отложенная загрузка для изображений была добавлена в Chrome 76 через атрибут loading, а затем пришла и в Firefox. Мы рады сообщить, что встроенная отложенная загрузка для iframe теперь стандартизирована и также поддерживается в браузерах на основе Chrome и Chromium.

<iframe src="http://personeltest.ru/aways/example.com"        loading="lazy"        width="600"        height="400"></iframe>

Встроенная lazy-loading загрузка iframe откладывает загрузку закадровых элементов iframe до тех пор, пока пользователь не прокрутит их рядом. Это сохраняет данные, ускоряет загрузку других частей страницы и уменьшает использование памяти.

Это Демо показывает вставки отложенной загрузки видео:

Почему следует загружать iframes отложено?

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

Основываясь на исследованиях Chrome по автоматической отложенной загрузке закадровых iframe для пользователей Data Saver, было установлено, что отсрочивание загрузки фреймов может привести к 2-3% экономии данных, к 1-2% сокращению значения First Contentful Paint на средних значениях и 2% к первой задержке ввода (FID) улучшения на 95-м процентиле.

Как работает нативная отложенная загрузка для фреймов?

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

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

*auto в настоящее время является нестандартизированным значением, но по умолчанию именно это значение использует Chrome. Корпорация Chrome намерена внести предложение по этому значению в таблицу стандартов.

Использование атрибута loading в iframes работает следующим образом:

<!-- Отложенная загрузка iframe --><iframe src="http://personeltest.ru/aways/example.com"         loading="lazy"         width="600"         height="400"></iframe><!-- Загрузка iframe по готовности --><iframe src="http://personeltest.ru/aways/example.com"         width="600"         height="400"></iframe><!-- или используйте loading="eager" что бы выйти из автоматического lazy-loading режима в Lite Mode --><iframe src="http://personeltest.ru/aways/example.com"         loading="eager"         width="600"         height="400"></iframe>

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

Если вам нужно динамически создавать iframe через JavaScript, то для элемента также поддерживается установка iframe.loading = 'lazy':

var iframe = document.createElement('iframe');iframe.src = 'https://example.com';iframe.loading = 'lazy';document.body.appendChild(iframe);

Специфичное для iframe поведение с отложенной загрузкой

Атрибут loading влияет на фреймы иначе, чем на изображения, в зависимости от того, скрыт ли фрейм. (Скрытые элементы iframe часто используются в аналитических или коммуникационных целях.)

Chrome использует следующие критерии для определения того, является ли iframe скрытым:

Ширина и высота iframe составляет 4 пикселя или меньше.
Если установлено значение display: none или visibility: hidden фрейм также является скрытым
iframe размещается вне экрана с использованием отрицательного положения X или Y
критерий скрытности применяется как к loading = lazy, так и к loading = auto.

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

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

Какое влияние мы можем увидеть от отложенных загрузок встраиваемых в iframe?

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

Загрузка видео YouTube с отложенной загрузкой (экономит ~ 500 КБ при начальной загрузке страницы):

<iframe src="http://personeltest.ru/aways/www.youtube.com/embed/YJGCZCaIZkQ"        loading="lazy"         width="560"         height="315"         frameborder="0"         allow="accelerometer; autoplay;         encrypted-media; gyroscope;         picture-in-picture"         allowfullscreen></iframe>

Немного юмора

Когда мы переключились на отложенную загрузку iframe с YouTube для сайта Chrome.com, мы сэкономили 10 секунд от того значения, как скоро наши страницы станут интерактивными на мобильных устройствах. На этом этапе я обнаружил внутреннюю ошибку YouTube, чтобы обсудить добавление loading = lazy к его встраиваемому коду.

Если вы ищете более эффективные способы загрузки встраиваемого YouTube контента, вас может заинтересовать компонент YouTube lite.

Вставка в Instagram с отложенной загрузкой (экономит> 100 КБ в разархивированном виде при начальной загрузке):

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

Загрузка Spotify с отложенной загрузкой (экономит 514 КБ при начальной загрузке)

<iframe src="http://personeltest.ru/aways/open.spotify.com/embed/album/1DFixLWuPkv3KT3TnV35m3"         loading="lazy"        width="300"         height="380"         frameborder="0"         allowtransparency="true"         allow="encrypted-media"></iframe>

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

Нативная загрузка социальных плагинов Facebook

Социальные плагины Facebook позволяют разработчикам встраивать контент Facebook в свои веб-страницы. Предлагается несколько таких плагинов, таких как встроенные записи, фотографии, видео, комментарии Самым популярным является плагин Мне нравится кнопка, которая показывает количество понравившихся страниц. По умолчанию встраивание плагина Like в веб-страницу (с использованием FB JSSDK) потребляет ~ 215 КБ ресурсов, из которых 197 КБ JavaScript. Во многих случаях плагин может появляться в конце статьи или ближе к концу страницы, поэтому загрузка его по умолчанию, когда он находится за кадром видимости пользователя, может быть неоптимальной.

Благодаря инженеру Стояну Стефанову (Stoyan Stefanov) все социальные плагины Facebook теперь поддерживают нативную загрузку iframe. Разработчики, которые выбирают, так называемую, ленивую загрузку через конфигурацию отложенных данных плагинов, теперь смогут избежать её загрузки до тех пор, пока пользователь не прокрутит рядом с элементом. Это позволяет встраивать все ещё полностью рабочий функционал для пользователей, которые нуждаются в этом, но в то же время предлагает сохранить данные для тех, кто не прокручивает всю страницу вниз. Мы надеемся, что это первая из многих встраиваемых систем, которая будет исследовать нативную загрузку iframe на производстве.

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

Они, конечно, могут. В Chrome 77 в Хром добавлена поддержка автоматической отложенной загрузки закадровых изображений и фреймов, когда пользователь выбрал облегченный режим Lite Mode (режим сохранения данных) в Chrome для Android.

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

Геолокация может определять, какой процент их трафика поступает от пользователей облегченного режима, проверяя свойство navigator.connection.saveData, которое является частью API NetworkInformation.

Могу я обеспечить отложенную загрузку для фреймов кросс-браузерно? Да

Нативная отложенная загрузка iframe может применяться как прогрессивное улучшение. Браузеры, поддерживающие loading=lazy для iframes, будут загружать iframe с отложенной загрузкой, в то время как атрибут загрузки будет безопасно игнорироваться в браузерах, которые его ещё не поддерживают.

Также можно лениво загружать закадровые iframes с помощью библиотеки JavaScript lazysizes. Это может быть оправдано, если вы:

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

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

<script src="lazysizes.min.js" async></script><iframe frameborder="0"    class="lazyload"    allowfullscreen=""    width="600"    height="400"    data-src="http://personeltest.ru/aways/www.youtube.com/embed/ZfV-aYdU4uE"></iframe>

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

<iframe frameborder="0"  class="lazyload"    loading="lazy"    allowfullscreen=""    width="600"    height="400"    data-src="http://personeltest.ru/aways/www.youtube.com/embed/ZfV-aYdU4uE"></iframe><script>  if ('loading' in HTMLIFrameElement.prototype) {    const iframes = document.querySelectorAll('iframe[loading="lazy"]');    iframes.forEach(iframe => {      iframe.src = iframe.dataset.src;    });  } else {    // Dynamically import the LazySizes library    const script = document.createElement('script');    script.src =      'https://cdnjs.cloudflare.com/ajax/libs/lazysizes/5.2.2/lazysizes.min.js';    document.body.appendChild(script);  }</script>

Вывод

Поддержка встроенных iframe с отложенной загрузкой значительно упрощает повышение производительности ваших веб-страниц. Если у вас есть какие-либо отзывы о lazy-loading загрузке встроенного iframe, не стесняйтесь отправлять сообщения в Chromium Bug Tracker.

Благодарности Addy Osmani за статью. Если вас интересует более глубокое погружение в тег iframe предлагаю вашему вниманию статью Исчерпывающий путеводитель по тегу iframe

Подробнее..

Категории: Html , Разработка веб-сайтов , Google chrome , Iframe , Lazy , Loading , Lazy loading , Tags , Save data

CloudWatch и Lambda, или Как я перестал бояться и полюбил AWS

23.04.2021 14:18:12 |

Автор: admin

Облачные провайдеры это реактор, где вместо обогащённого урана используется твой кошелёк. В позапрошлом году наша компания начала активно применять облака и мы в полной мере ощутили это на себе: несколько команд разрабатывали отдельные продукты, и для большинства тестов запускались виртуальные мощности в AWS. Мы с коллегами получили сертификаты от Amazon, и это, вместе с наглядностью происходящего, Free Tier и Soft Limitами, создавало ложное чувство спокойствия за свой бюджет. А когда этому чувству поддаёшься, получаешь локальный Чернобыль.

После нескольких превышений бюджета и встреч с начальством из-за забытых виртуалок мне надоело оправдываться, и я решил предотвратить лишние расходы, тем более что было известно, сколько можно потратить. Я использовал связку CloudWatch и Lambda и этот способ себя оправдал.

Почему настройка оповещений это плацебо

Первый способ, на который указывает сам AWS это настройка бюджетов AWS Budgets и оповещений из них. Да, здесь есть очевидные плюсы: это решение очень легко настроить, а сервис предупреждает в случае превышения текущего или прогнозируемого бюджета. С сентября 2020 г. он даже научился прогнозировать потребление и отправку событий в Amazon SNS.

Но объективно это просто ещё одна загорающаяся лампочка: оповещение может прийти на почту в середине ночи, а узнаёшь об этом только в понедельник утром. К тому же, по умолчанию AWS Budgets ничего не делает после того как заметил превышение. Он отлично подходит для контроля конкретных задач (например, отмеряет скорость расходования средств на проде), но среагирует слишком поздно, если у нас рядом будут работать запущенные по ошибке или безымянные виртуальные машины. Не подойдёт.

Как взять под контроль облачный ядерный реактор

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

Я решил, что нужно где-то разместить логику реагирования и дёргать за различные API в облаке. Проще всего это сделать в AWS Lambda, так как Serverless может работать бесплатно, логика реагирования оформляется как на NodeJS, так и на Python, а простота API-вызовов из облака и ролевая модель доступа сокращают время на тестирование такого решения.

Но как тогда нам собирать информацию о запущенных инстансах и их потреблении? Зная время работы и цену инстанса в час, можно соотнести потребление с нашим бюджетом. Цены инстансов статическая и общедоступная информация. Тут главный вопрос как давно стартовал инстанс?

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

Какие есть инструменты для контроля трат на AWS

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

Cost Explorer даёт подробную разбивку по сервисам, но единственное, что он показывает, это сколько аккаунт уже успел потратить. Ничего не знает про запущенные в данный момент виртуальные мощности, но с его помощью можно оптимизировать траты.
Budgets внутри Cost Explorer. С сентября 2020 г. он научился определять Usage в часах, но всё ещё не даёт ответа, как идентифицировать забытые сущности.
CloudTrail мощный инструмент для контроля всего, что происходит в облаке. С его помощью можно раскрывать все сущности, совершившие любое действие, и узнавать точное время. Главный его недостаток для мой задачи он собирает вообще всю информацию в массивные лог-файлы, без конкретного объяснения в какой момент он заканчивает один файл и начинает другой. Писать целый парсер среди множества файлов под одну задачу это как из пушки по воробьям.
CloudWatch отличный инструмент, чтобы мониторить состояние уже запущенных инстансов, но информация о запусках находится только в CloudTrail. Кроме сбора информации, умеет запускать события по расписанию.

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

Накопление данных Lambda + S3

Так как сложные варианты мне не подошли, я остановился на простом: решил накапливать знание о времени работы каждого инстанса самостоятельно, благо хранение файлов это тривиальная задача для Lambda + S3.

Для упрощения тестирования и читаемости кода разобьём задачу между несколькими Lambda:

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

Оркестратором простой цепочки Lambda я сделал Step Functions, который может запускаться по расписанию из CloudWatch.

Пример решения

Файлы для Proof of Concept вы можете найти по ссылке на GitHub, а ниже я распишу, что делает этот код. В жизни он дорабатывался под нужды команд и использовался до тех пор, пока мы не обучили достаточное количество сотрудников соблюдать правила работы с облаком.

Что тут происходит?

Каждые 5 минут CloudWatch отправляет заготовленный вызов в Step Functions, который управляет последовательным запуском четырёх Lambda-функций. Каждая Lambda-функция исполняет код на JavaScript (версии Node.js 10.x), использует сервисы EC2, Config или S3, и завершает свою работу передачей JSON в следующую Lambda. Исполнение скрипта завершается записью логов в CloudWatch Logs.

Как это работает?

CloudWatch Event > Step Function > 4 Lambda functions > CloudWatch Logs

Get List of Working Instances получает список работающих инстансов и передает его через JSON в следующую Lambda-функцию
Update Budget Usage делает много вещей, но главное обновляет данные файла в S3-хранилище.
Terminate Instances выключает инстансы, которые превышают бюджет или нас не устраивают.

Как устанавливать?

После размещения кода и настройки ролей в Lambda-функциях необходимо составить схему работы через Step Functions, а также привязать событие CloudWatch Event Rule, которое будет запускать систему каждые 5 минут.

Как бы я подошёл к этой проблеме сейчас

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

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

Если бы я сейчас начал заново решать проблему избыточного времени работы, то в S3 вместо файла бюджета оказался бы файл с договорённостями по использованию тегов. Lambda вместо оценки времени работы немедленно выключала бы все мощности, не подходящие по тегам. А контроль за расходами перешёл бы в связку AWS Budget и SNS с той же Lambda, управляющей их отключением.