company_banner

Красота прогрессивных улучшений

Автор оригинала: Manuel Matuzovic
  • Перевод
Компания Nokia выпустила обновлённую версию легендарного телефона Nokia 3310 примерно 3 года назад. Я вполне мог его себе позволить (стоил он совсем недорого), поэтому я таким телефоном обзавёлся. Он оснащён двухмегапиксельной камерой и батареей, которой хватает на 30 дней (до 22 часов разговоров). Он поддерживает 2G-сети, оборудован 16 мегабайтами памяти, в нём есть классическая игра «Змейка» и браузер.


Телефоны Nokia 3310

Как создавать сайты, которые будут хорошо работать на таком телефоне?

Браузер Opera Mini


Nokia 3310 позволяет просматривать веб-сайты с использованием браузера Opera Mini. Существуют разные версии этого браузера. То, как именно он рендерит страницы, зависит от операционной системы, от устройства и от используемых настроек. Если установить этот браузер на смартфон, вы, возможно, ничего нового для себя не увидите, так как Opera Mini использует браузерный движок, который имеется в Android или iOS. У этого браузера есть одна интересная особенность. Дело в том, что он позволяет задавать разные параметры экономии трафика. Экономия может быть выключена, может выполняться в автоматическом режиме, уровень экономии может быть высоким и экстремальным. Когда страницы просматривают в экстремальном режиме экономии трафика, запросы уходят на один из прокси-серверов Opera, который загружает страницу, обрабатывает её, сжимает, а после этого отправляет пользователю. Представители Opera заявляют о том, что это снижает объём передаваемых данных вплоть до уровня в 90%. Это ограничивает интерактивные возможности страниц, так как JavaScript-код обрабатывается только сервером, а устройство лишь выводит готовую страницу.

Вот некоторые другие примечательные факты, касающиеся обработки JavaScript в Opera Mini:

  • Время выполнения всех скриптов ограничено двумя секундами.
  • Функции setInterval и setTimeout отключены.
  • Ограничено количество событий, возникновение которых может вызывать выполнение скриптов.

Opera Mini очень сильно нацелен на производительность и экономию трафика. Я предполагаю, что это — одна из причин, по которым именно этот браузер установлен на моём Nokia 3310. Правда, тот браузер, который установлен на этом телефоне, отличается от того, который установлен на моём смартфоне. Это — тот самый браузер, при описании возможностей которого на caniuse.com обычно используется красный цвет.


Opera Mini поддерживает лишь ограниченный набор возможностей CSS и JS

Вчера мне стало любопытно узнать о том, сможет ли веб-сайт, который я недавно создал, отрендериться на Nokia 3310.

Вот короткое видео, демонстрирующее сравнение вывода этого сайта в Safari на iPhone XR и в Opera Mini.

К моему удивлению, мне, чтобы сайт выглядел бы на Nokia 3310 прилично, нужно было лишь уменьшить некоторые внутренние отступы элементов и размеры шрифтов. Мне не пришлось вносить в проект особенно больших изменений, так как я, когда создаю сайты, следую принципу прогрессивных улучшений. Прогрессивные улучшения — это когда основное внимание уделяется контенту, а остальные возможности проекта улучшаются поэтапно. В этой классической статье Аарона Густафсона о прогрессивных улучшениях разъясняется порядок использования данной техники в веб-разработке.


Содержимое, презентационный уровень, клиентские скрипты

Вот что пишет об этом Аарон Густафсон: «Всё начинается с ядра, пусть это будет арахис, представляющего собой контент, оформленный в виде семантического (X)HTML-кода, обладающего широкими функциональными возможностями. На этот контент наносят слой вкуснейшего шоколадного CSS. И, наконец, добавляют JavaScript, который напоминает твёрдую оболочку конфеты, что улучшает вкус угощения (и не даёт сладостям таять в руках)».

Как я использую методологию прогрессивных улучшений


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

▍Grid-макеты


Для создания двухколоночного макета главной страницы проекта Front-end Bookmarks я использовал технологию CSS Grid. Если браузер не знает о том, что такое display: grid, то просто используется запасной вариант в виде одноколоночного макета. Обратите внимание на то, что мне не приходится использовать @supports-запросы в CSS, так как браузер попросту игнорирует свойства, которые ему непонятны.

ul {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(29rem,1fr));
  grid-gap: .7rem;
}


Страница проекта в IE11 и в Firefox

Одноколоночный макет, как видите, не идеален, но он, всё равно, достаточно хорош.

▍Поиск


Современные браузеры выводят в верхней части страницы моего проекта поле комбинированного списка, которое позволяет перемещаться по страницам, фильтровать и выбирать страницы. В своём JavaScript-коде мне хотелось использовать стрелочные функции, шаблонные литералы и прочие современные возможности языка. При этом мне не хотелось бы применять полифиллы для обеспечения поддержки этих возможностей браузерами, в которых нет их встроенной поддержки. Именно поэтому я отправляю JS-код только тем браузерам, которые понимают ES2015+. Добиваюсь я этого, добавляя к тегу <script> атрибут type=«module».

<script src="/assets/js/scripts.min.js" type="module"></script>

Браузер выполнит скрипт только в том случае, если он поддерживает ES-модули, а соответствующий браузер будет поддерживать и возможности ES2015+. Филип Уолтон представил данную методику в 2017 году, в этом материале.


Поиск в IE 11 и в Firefox

Соответствующий JS-компонент, обладающий широкими возможностями, в браузерах, не поддерживающих нужные для его работы технологии, превращается в простую форму поиска. В поле ввода заранее помещено значение site:www.frontendbookmarks.com. Если ввести сюда поисковый запрос и нажать на кнопку Search, будет вызвана поисковая система DuckDuckGo, которая выполнит поиск по заданному запросу на сайте frontendbookmarks.com. Это — не идеальное решение, но оно всё же лучше, чем ничего.

<form action="https://duckduckgo.com/" method="GET">
  <label for="search">Search on DuckDuckGo</label>
  <input id="search" name="q" value="site:www.frontendbookmarks.com " type="text">
  <button type="submit">Search</button>
</form>

Я позаимствовал эту идею отсюда. Там похожий подход используется для организации поиска по документации Eleventy.

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

▍Webp-изображения


Преимущества формата webp перед другими графическими форматами заключаются в размерах файлов. Webp-файлы обычно гораздо меньше, чем файлы, сохранённые в других форматах. К несчастью, я не могу просто взять и заменить все мои jpg-изображения на их webp-версии, так как Safari и IE не поддерживают этот формат. Но мы можем дать браузеру возможность самостоятельно выбрать подходящее изображение, используя элемент <picture>:

<picture>
  <source srcset="image.webp" type="image/webp"> 
  <img src="image.jpg" alt="image description"> 
</picture>

Браузер читает содержимое элемента <picture> сверху вниз. Если браузер поддерживает формат webp, то он использует соответствующее изображение, описанное в элементе <source>. Если не поддерживает — он просто пропустит этот элемент и выведет изображение, описываемое элементом <img>.

▍Ленивая загрузка


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

<img data-src="myimage.jpg" loading="lazy" />
// Заменить значение атрибута src на значение атрибута data-src
// для браузеров, не поддерживающих ленивую загрузку.
    if ('loading' in HTMLImageElement.prototype) {
        const images = document.querySelectorAll("img[loading='lazy']");
        images.forEach(img => {
            img.src = img.dataset.src;
        });
    } else {
      // Запасной вариант для других браузеров
    }

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

Итоги: прогрессивные улучшения — это прекрасно


Я назвал этот материал «Красота прогрессивных улучшений» из-за того, что мне очень приятно видеть то, как сайт подстраивается под разные устройства, операционные системы, браузеры. Прогрессивные улучшения позволяют нам использовать самые свежие и самые интересные возможности HTML, CSS и JavaScript. Но при этом они помогают создавать простую и надёжную базовую структуру сайтов, которая позволяет сайтам работать где угодно. Веб-разработчику очень важно заботиться обо всех пользователях — в том числе о тех, кто смотрит сайты с помощью IE 11 и Opera Mini. Не стоит полагаться на статистические данные по браузерам. Нам надо думать о тех, для кого мы создаём сайты. Наши пользователи очень сильно отличаются друг от друга. Речь идёт об их физических возможностях, об их личных предпочтениях, об их устройствах и браузерах.

Используете ли вы прогрессивные улучшения в своих веб-проектах?



RUVDS.com
RUVDS – хостинг VDS/VPS серверов

Похожие публикации

Комментарии 10

    +3
    Webp-файлы обычно гораздо меньше, чем файлы, сохранённые в других форматах.
    Разве только в синтетических тестах. Реальные webp, создаваемые ImageMagick из тех же png, обычно оказываются больше, причём значительно, на треть где-то.
    Как создавать сайты, которые будут хорошо работать на таком телефоне?
    Для начала хорошо бы сделать сайт таким, чтоб там не было ни строчки JS. Серьёзно, в XXI веке уже пора бы тем же «зелёным» создать движение Защиты Веба от Javascript, потому как проблема давно назрела и даже перезрела. Ведь страшно даже представить, сколько электроэнергии тратиться на обработку этих скриптов, при том что в 99% случаев в них нет особой необходимости.
    А ещё бы хорошо всяким там W3C наконец собраться и придумать, как доработать стандарты, чтобы самые основные задачи, выполняемые JS, переложить на движок самого браузера.
    Первое, для чего используется JS — сбор бессмысленной телеметрии, которая на самом деле в 99% случаев тупо лежит на серверах мёртвым грузом и никогда не используется. Но ведь куда эффективнее собирать её силами самого браузера! Добавляем в стандарт HTML тег:
    <telemetry WhatToCollect submit="url"&gt
    и все будут довольны. И телеметрия будет собираться, и тормозов не будет. Второе по важности применение JS — показ баннеров. Ну добавьте вы уже тег, аналогичный тегу video, чтоб не тормознутым JS, а силами самого браузера эти баннеры крутить:
    <banner width="..." settings=... src=Google|Yandex|etc>
    и будет всем счастье без JS этого тормознутого.
      0

      AMP?

        0
        А ещё бы хорошо всяким там W3C наконец собраться и придумать, как доработать стандарты, чтобы самые основные задачи, выполняемые JS, переложить на движок самого браузера.


        Ни один комитет не сможет решить за всех то, какие задачи основные, а какие — нет. Если пытаться пропихнуть в стандарт решения для частных задач, а действия, которые сейчас приходится реализовывать с помощью JavaScript полностью переложить на плечи браузера, то в конечном счете стандарт моментально раздуется, а «нагрузка» навряд ли значительно уменьшится. Все-таки те же самые действия по прежнему будут выполняться. Это если пофантазировать.

          0
          Реальные webp, создаваемые ImageMagick из тех же png, обычно оказываются больше, причём значительно, на треть где-то.

          Можете показать примеры изображений? Мне интересны примеры, где webp не работает.

          В наших проектах (не связанных с вебом) проводили начальное исследование эффективности сжатия на конкретном (не синтетическом) контенте, и выигрыш по размеру был существенным — в среднем сжатые изображения весили 25% от начального размера PNG
            +1
            Изображения с чёткими цветовыми границами и отсутствием градиентов экстремально плохи для WebP. Как пример, Pixel Art и спрайтовые листы / иконки.
            Чем меньше в изображении контрастных границ и больше плавных переходов, тем WebP лучше. Но тут он уже конкурирует не с PNG, а с JPEG, и далеко не всегда успешно.
              +2
              Официальный гугловский энкодер (cwebp v1.0.3) при максимальном lossless-сжатии (-z 9) даёт:
              10964 -> 8876 (-19%)
              1255 -> 1072 (-15%)
              48013 -> 43620 (-9%)

              Экономия вполне себе есть, хотя и меньшая, чем можно было бы ожидать из среднебольничных бенчмарков. Но это вполне объясняется большой специфичностью изображений (две из трех картинок 2-битные). Во всяком случае, хуже уж точно не становится.
              Так что дело либо в некачественной реализации ImageMagick, либо что-то не то с настройками.
            +1
            Реальные webp, создаваемые ImageMagick из тех же png, обычно оказываются больше

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


            Фотография (изображение, где в принципе не может быть больших областей с одинаковыми пикселями, хотя бы из-за шума матрицы) в формате png будет занимать мегабайты, тогда как в webp можно будет ужать ее до десятков килобайт.


            А, например, экспортированный из svg баннер, скриншот интерфейса приложения, или что-то подобное в png будет занимать зачастую пару сотен килобайт, но в webp так или иначе будут артефакты (если не сжимаем lossless) даже при размере в те же десятки килобайт.


            Дело не в форматах, дело в характере самого изображения

              0

              Я очень за то, чтобы отказаться от JS. Однако


              • Как показывать формулы в тексте? MathML мертв, пререндеренные картинки из латеха выглядят ужасно.
              • Как сделать график с возможностью скроллинга и всего такого здесь?
              0
              Эти инструменты помогают мне украсить HTML, CSS и JavaScript


              надеюсь, это поможет
                –1
                //не по теме
                Снова Я
                Нашел еще ошибки в той статье
                «const list = []»
                Очень часто «list» используется в качестве переменной, что запрещено

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

                Самое читаемое