Поскольку мы продолжаем наблюдать за развитием таких областей, как Машинное обучение, Искусственный интеллект, Наука о данных, Квантовые вычисления, область Веб-разработка тоже не отстает. Сейчас у нас есть прогрессивные веб-приложения (PWA). Прошли те времена, когда ваше веб-приложение переставало работать в автономном режиме и показывало «красивого» динозавра! Да, я серьезно. Динозавр, друг мой, извини, если это тебя задело, но пора пользователям увидеть что-то более «красивое». Так должна работать эволюция, не так ли? В любом случае, давайте погрузимся в основную дискуссию.
Что такое оболочка приложения?
Оболочка приложения - это архитектурный шаблон для создания прогрессивных веб-приложений, в котором вы отправляете только минимальные критические ресурсы, чтобы загрузить свой сайт, а затем ленивый загружать другие некритические данные или ресурсы, что дает пользователям ощущение нативного приложения.
Другими словами, вы можете думать о оболочке приложения как о своем каркасе страницы, который должен быть там, даже когда ваше приложение отключается от сети! Это означает, что вы будете кэшировать свою оболочку приложения и критические ресурсы вместе для мощной первой загрузки, а затем загружаете оставшиеся данные (ленивая загрузка), необходимые для вашего приложения. Популярные фреймворки, такие как Angular и React, по-прежнему сталкиваются с множеством проблем из-за тяжелой архитектуры и размера пакета в этом вопросе, хотя об этих вещах можно позаботиться с помощью очень умных реализация концепций.
Мы рассмотрим все «за» и «против» при создании собственной надежной оболочки приложения, и мы не будем использовать какие-либо библиотеки или фреймворки. Правильно, ванильный JavaScript - это то, что вам нужно.
Пример оболочки приложения
Прежде чем мы начнем копать, неплохо было бы узнать, как на самом деле выглядит оболочка приложения и как на нее влияет производительность. Следующий пример продемонстрирует это:
Вы можете видеть, как быстро загружается оболочка, и позже, после загрузки оболочки, вы можете использовать ее для загрузки других частей вашего приложения, данные из которых могут быть извлечены асинхронно с использованием стратегий отложенной загрузки. (В демонстрации App Shell пока не используется для запросов данных. В настоящее время я создаю версию Hacker News, в которой будет использоваться эта концепция.)
Ближе к концу статьи я также перечислил тесты производительности времени загрузки страницы App Shell. Но не пропустите содержание, представленное в следующих нескольких разделах, которое поможет в достижении оптимального времени загрузки страницы 1 секунда.
Скелет страницы
Каркас страницы является наиболее важной частью концепции оболочки приложения. Вот пример index.html, который использовался для демонстрации выше.
Здесь вы обнаружите, что я разбил приведенный выше код на следующие части:
- Критические встроенные стили (строка 10)
- Раздел HTML оболочки приложения (основной раздел, занимающий строки с 17 по 54)
- Раздел критических сценариев (конец текста в строке 53)
Также для достижения идеальной оценки PWA потребуется файл manifest.json вместе со значками. Вы найдете ссылку GitHub на полный исходный код в конце этой статьи.
Критические встроенные стили
Раздел критических встроенных стилей - это то место, куда должны входить все важные стили, относящиеся только к оболочке приложения. Основная причина этого заключается в том, что если вы решили сохранить CSS как внешний файл, до тех пор, пока он не будет найден в HTML-файле и не будет загружен, просмотр вашей страницы будет заблокирован от синтаксического анализа (некоторое время тратится на загрузку CSS, а затем анализируется на CSSOM).
Вот как конструкция DOM (объектная модель документа) и CSSOM (объектная модель CSS) работает под капотом, а CSS является ресурсом, блокирующим рендеринг. способ. Подробнее о том, почему CSS блокирует рендеринг, читайте в следующих статьях:
В следующей статье рассказывается о критическом пути рендеринга и является очень важной темой, касающейся оптимизации производительности времени загрузки.
В следующей статье рассказывается о CSS как о ресурсе блокировки рендеринга и о том, как избежать блокировки рендеринга:
HTML-раздел оболочки приложения
Если вы заметили раздел HTML, вы обнаружите, что я использовал раздел для панели навигации и раздел для основной части приложения. Если вы также хотите, вы можете добавить в нижний колонтитул под основным разделом.
Вы можете использовать раздел основного приложения (строки 48–50) для динамической асинхронной загрузки основного содержимого вашего приложения. Таким образом, загрузка страницы не будет затруднена или заблокирована, и ваши пользователи наверняка мгновенно почувствуют скорость эволюции (то есть ваши пользователи всегда будут получать обратную связь от вашего приложения).
В настоящее время я использую этот шаблон в своей локальной настройке для разработки приложения Hacker News с нуля. Конечно, это проделано долгий путь и отлично работает, когда весь фид загружается лениво. Я обязательно напишу об этом приложении, когда закончу свое исследование.
Раздел критических сценариев
Я не встроил JavaScript для этой части, хотя рекомендуется также встроить скрипты, поскольку встраивание всегда экономит время загрузки. Но у нас есть возможность выбрать асинхронную загрузку JavaScript с помощью атрибутов async или defer. Использование любого из этих атрибутов поможет вам асинхронно загрузить содержимое файла сценария.
async помогает загружать скрипты асинхронно и загружает их сразу после завершения загрузки. Это не зависит от порядка, в котором находятся теги сценария, и может вызвать проблемы, если один из ваших сценариев зависит от другого сценария. Так как же решить эту проблему, если мы хотим заказать?
defer приходит на помощь, помогая нам загружать сценарии асинхронно, и даже после того, как они не получают порядок загрузки, они, по крайней мере, выполняются в порядке тегов сценария, найденных в документе HTML. Действительно, очень удобно!
Не стесняйтесь выбирать любой из методов атрибутов или встроенный JavaScript в соответствии с размером вашего HTML. В конце концов, если размер нашей оболочки приложения JavaScript увеличивается, нам обязательно нужно будет разделить его minify и gzip перед тем, как передать его клиенту.
Кэширование критических ресурсов
Бум Service Workers определенно вызвал много шума в области офлайновых первых приложений. Да, наша оболочка приложения сначала будет отключена. Позже я напишу статью о ленивой загрузке ресурсов, а также о динамическом кэшировании их с помощью сервис-воркера, но пока эта статья будет сосредоточена только на оболочке приложения.
Следующий файл известен как сценарий сервис-воркера:
Этот сценарий выполняется параллельно с основным потоком браузера и действует как прокси, который перехватывает запросы и возвращает ответы.
Основные концепции из приведенного выше файла можно условно разделить на 3 области:
- Кэширование статических ресурсов во время установки (строки 8–23)
- Обновите Service Worker и удалите старый кеш (строки 25–44)
- Стратегия кэширования, затем сетевая (строки 46–54)
Для этого потребуются базовые знания обслуживающего работника. Дополнительные сведения о сервис-воркере и его использовании см. В следующей статье:
Вы также можете посетить этот замечательный курс, созданный Udacity в сотрудничестве с Google:
Кэширование статических ресурсов во время установки
Это очень важно для того, чтобы указать имена файлов, которые необходимо кэшировать, с помощью Cache API браузера. Этот Cache API имеет большое значение для того, чтобы при необходимости получать из кеша дальнейшие запросы.
Событие install сервис-воркера - идеальное время, чтобы указать имена файлов для кеширования. Строки 8–23 кода помогают именно в этом. Кэшируются следующие файлы: index.html («/» в строке 14 напрямую кэширует HTML-файл по умолчанию), offline.html и app.js. Да, offline.html делает именно то, что вы думаете. Он показывал фрагмент автономного контента, как только я переключался в автономный режим в демонстрации, и все это происходило из кеша.
Обновите Service Worker и удалите старый кеш
Событие activate работника службы (строки 25–44), которое является событием активации. После установки сервис-воркера событие активации запускается немедленно, если сервис-воркер не был зарегистрирован ранее. Мы соответствующим образом отфильтровываем имена кешей, чтобы они не совпадали с текущим именем статического кеша, которое мы будем использовать, и удаляем таким образом весь наш ранее кэшированный контент.
Эта часть очень важна, если мы хотим регулярно обновлять браузер клиента последними данными кеша, а также очищать ненужный старый кеш.
Для этого каждый раз вам нужно будет увеличивать имя статического кеша (строка 1) всякий раз, когда вы изменяете какую-либо часть содержимого файла сервис-воркера. Всегда помните, что изменение байта в сервис-воркере равносильно установке нового сервис-воркера.
Стратегия кеширования, затем сетевая
Эта часть кода (строки 46–54) действительно помогает в первом поиске данных из кеша. Событие fetch сервис-воркера происходит каждый раз, когда браузер клиента запускает запрос XHR.
Если кеш содержит ответ, мы немедленно отправляем его клиенту, не теряя времени, в противном случае мы идем в сеть, чтобы получить данные.
Таким образом, при каждом запросе offline.html браузер всегда получает элемент из кеша и отображает его, когда приложение находится в автономном режиме. То же самое происходит, когда вы кешируете index.html ‘/’ в соответствии со строкой 14 и обновляете страницу в следующий раз. Все ваши запросы будут извлекаться из кеша с помощью сервис-воркера, а не из внешней сети.
Такой способ динамической обработки ответов действительно имеет большое значение для демонстрации возможностей сервис-воркеров и объема данных, которые мы действительно можем взломать.
Для неэтичных хакеров, поверьте мне, вы можете использовать Service worker только с HTTPS и localhost, если на то пошло. Следовательно, сервис-воркеры были созданы таким образом, чтобы уже были приняты меры по обеспечению безопасности. Извините, неэтичные хакеры!
Итак, после всех этих революционных изменений вы все еще можете спросить: «Что мы получаем от этого? Какое влияние это оказывает? ». Я перечислил тесты производительности ниже. Это ответит на все ваши вопросы.
Тесты производительности с использованием Lighthouse
Оболочка приложения была протестирована в режиме инкогнито браузера Chrome с использованием Lighthouse в режиме мобильного устройства. Кроме того, тест проводился на http: // localhost: 5000 /, который является, а не HTTPS. Вот результаты:
Оценка PWA может стать 100 после того, как вы развернете приложение и используете в нем HTTPS. Оценка Best Practices может быть достигнута 100 с помощью HTTP / 2, который также встроен в Firebase и другие популярные хостинги. Сервисы.
Но наиболее важную часть можно увидеть в производительности страницы загрузки самой оболочки приложения. Мы достигли времени загрузки (первая значимая краска) 600 мс здесь с аудитом, что намного меньше, чем желаемое время загрузки страницы - 1 секунда.
Размер приложения в будущем будет расти, но если оболочка приложения спроектирована правильно, нацелена на производительность, как это сделано выше, вместе с отложенной загрузкой остальных компонентов приложения. , вы тоже добьетесь этих результатов. Да, и всегда помните, #perfmatters (Производительность имеет значение!).
Ленивая загрузка данных динамически
Одна из основных причин, по которой я подчеркиваю ленивую загрузку содержимого приложения после этого, заключается в том, что у вас может быть много данных, которые необходимо получить с сервера, в течение этого времени, если пользователь все еще видит пустую страницу или ничего не отображается. это сильно повлияет на пользовательский опыт.
Например, после загрузки оболочки приложения вы можете захотеть показать счетчик загрузки как часть оболочки на странице, во время которой приложение будет загружать данные своей первой страницы асинхронно в области серого пространства. . Таким образом, ваши пользователи получат некоторую обратную связь, поскольку оболочка страницы уже загружена, и вы также будете разумно использовать время простоя для загрузки динамических данных с сервера. Отличная штука!
Заключение
Внешняя архитектура так же важна, как и внутренняя архитектура, которую вы разрабатываете для своих приложений. Мы часто забываем, что большая часть проблем, связанных с производительностью, связанных с загрузкой страницы, происходит из-за архитектуры внешнего интерфейса. Да, важно спроектировать интерфейс на тот случай, если вы не хотите жить в каменном веке (извините, динозавр!).
Следующая статья вдохновила меня на создание собственной оболочки приложения с нуля.
Если вы, ребята, нашли эту статью полезной, дайте мне знать в разделе комментариев ниже и, пожалуйста, не забудьте хлопать в ладоши. У меня запланировано больше таких статей, которые я буду публиковать в связи с продолжающимся исследованием использования всех этих концепций в реальном приложении, таком как Hacker News.
Вот ссылка на мой исходный код GitHub:
Не стесняйтесь разветвлять этот репозиторий и использовать его как часть вашего собственного начального шаблона для ваших будущих проектов, и да, он построен с использованием Vanilla HTML, CSS и JavaScript. Удачного взлома! 😄
Другие сообщения от меня
Найдите меня по адресу: https://medium.com/@anurag.majumdar
➥ Веб-разработка
- « Супер и расширяет в JavaScript ES6 - понимание сложных моментов»
- Введение в полифиллы и их использование
