Оригинальный автор: Эдди Османи
Переводчик: Джоти, UC International R&D
Спереди написано: Добро пожаловать в официальный аккаунт «UC International Technology», мы предоставим вам качественные технические статьи, связанные с клиентом, сервером, алгоритмом, тестированием, данными, интерфейсом и т. д., не ограничиваясь оригинальностью и перевод.
Это статья про оптимизацию производительности. Это статья, которую стоит прочитать. Содержание статьи очень богатое. На ее прочтение у вас уйдет около 5-10 минут.
В течение прошлого года мы были заняты попытками выяснить, как сделать Интернет быстрее и эффективнее. Отсюда и новые инструменты, методы и библиотеки, которыми мы хотим поделиться с вами в этой статье. В первой части мы покажем вам некоторые методы оптимизации, которые мы использовали при разработке приложения The Oodles Theater. Во второй части мы обсудим наши эксперименты с предиктивной загрузкой и наши новые планы Guess.js.
Совет: Вы можете посмотреть видео на Youtube https://www.youtube.com/watch?v=Mv-l3-tJgGk
потребности в производительности
Интернет становится все тяжелее с каждым годом. Если мы проверим статус веб-страницы, мы увидим, что мобильная страница среднего размера составляет около 1,5 МБ, в основном это JavaScript и изображения.
Растущие размеры веб-сайтов в сочетании с другими факторами, такими как задержка в сети, ограничения ЦП, режимы блокировки рендеринга или избыточный сторонний код, могут привести к сложным проблемам с производительностью.
Большинство пользователей рассматривают скорость как высший уровень иерархии потребностей взаимодействия с пользователем (см. рисунок ниже). Это не слишком удивительно, так как вы не можете сделать многое, пока страница не загрузится. Вы не можете извлечь пользу из страницы, вы не можете оценить ее эстетику.
Рисунок 1. Насколько важна скорость для пользователей?
Мы знаем, что производительность важна для пользователей, но опять же, это секрет, с чего начать оптимизацию. К счастью, есть несколько инструментов, которые могут нам помочь.
Lighthouse — основа производительных рабочих процессов
Lighthouse является частью Chrome DevTools, который позволяет вам просматривать свой веб-сайт и предлагать предложения по оптимизации.
Недавно мы запустили ряд новых отзывов производительности (https://developers.google.com/web/updates/2018/05/rueb/updates/2018/05/lighthouse), которые очень полезны в повседневных рабочих процессах развития.
Рисунок 2. Обзор New Lighthouse
Давайте рассмотрим, как их использовать на практическом примере: приложение Ooodles Theatre. Это небольшое демонстрационное веб-приложение, в котором вы можете попробовать некоторые из наших любимых интерактивных дудлов Google и даже сыграть в одну или две игры.
При создании приложения мы хотим убедиться, что оно максимально эффективно. Отправной точкой для оптимизации является отчет Lighthouse.
Рисунок 3. Отчет Lighthouse для приложения Ooodles
Первоначальная производительность нашего приложения в отчете Lighthouse была ужасной. В сетях 3G пользователю нужно подождать 15 секунд до первого осмысленного отрисовки (страницы) или (скажем) до того, как приложение станет интерактивным. Lighthouse выявил ряд проблем с нашим сайтом, и общий балл производительности 23 отражает это.
Размер страницы около 3,4 МБ - нам срочно нужно похудеть.
Здесь начинается наша первая задача по повышению производительности: поиск контента, который можно легко удалить без ущерба для общего опыта.
Возможности оптимизации производительности
Есть некоторые очевидные вещи, которые можно безопасно удалить: пробелы и комментарии.
Рисунок 4. Минимизируйте и минимизируйте JavaScript и CSS
Маяк вUnminified CSS & JavaScript рассмотрениевыделил эту возможность. Программа собрана с помощью webpack, поэтому для уменьшения размера мы выбрали плагин Uglify JS.
Сокращение — распространенная задача, поэтому вам нужно найти готовое решение, которое подходит для вашего процесса сборки.
Еще один полезный обзор в этом проектеВключить сжатие текста. У нас нет причин отправлять несжатые файлы, и в наши дни большинство CDN поддерживают это «из коробки».
Мы используем Firebase Hosting для размещения нашего кода, в Firebase по умолчанию включен gzip, поэтому, размещая наш код на приемлемом CDN, мы получаем эту функцию бесплатно.
В то время как gzip является очень популярным методом сжатия, другие механизмы, такие как Zopfli и Brotli, набирают обороты. Brotli поддерживается большинством браузеров, и вы можете использовать двоичный код для предварительного сжатия ресурса перед его отправкой на сервер.
Наш следующий шаг — убедиться, что мы не отправляем ресурс повторно, когда в этом нет необходимости.
в МаякеНеэффективная стратегия кэшированияОбзор привлек наше внимание к тому, что мы можем добиться этого, оптимизировав стратегию кэширования. Установив заголовок срока действия max-age на нашем сервере, мы можем гарантировать, что в случае повторного доступа пользователи смогут повторно использовать свои ранее загруженные ресурсы.
В идеале вы должны безопасно кэшировать как можно больше ресурсов как можно дольше и предоставлять маркеры проверки для эффективной повторной аутентификации обновленных ресурсов.
До сих пор мы удаляли существенные части ненужных загружаемых файлов, а как насчет менее заметных частей? Например, неиспользуемый код.
Рисунок 5. Проверка покрытия кода
Иногда мы включаем ненужный код в наше приложение. Это особенно актуально, если ваше приложение разрабатывалось в течение длительного времени, ваша команда или ваши зависимости изменились, а иногда и «осиротевшие библиотеки» забыты. Это именно то, что мы испытали.
Первоначально мы использовали библиотеку Material Components для быстрого создания прототипа нашего приложения. Со временем мы перешли на более индивидуальный вид и совсем забыли об этой библиотеке. К счастью,покрытие кодаПроверка помогла нам заново открыть его в комплекте.
Вы можете проверить статус покрытия кода в DevTools, включая время выполнения и время загрузки приложения. Вы можете видеть две большие красные полосы на нижнем снимке экрана — у нас более 95% неиспользованного CSS и целая куча JavaScript.
Lighthouse также упомянул эту проблему в обзоре неиспользуемых правил CSS. Это означает, что мы потенциально можем сэкономить более 400 КБ. Поэтому мы вернулись к коду и удалили из библиотеки части JavaScript и CSS.
Рисунок 6. Прекращение поддержки адаптера MVC, наши стили уменьшились до 10 КБ!
Это уменьшило наш пакет CSS в 20 раз, что отлично для крошечного двухстрочного коммита.
Конечно, это повысило наш показатель производительности, а также было оптимизировано время взаимодействия.
Однако при таком изменении недостаточно просто проверить метрики и баллы. Удаление фактического кода ни в коем случае не является безопасным, поэтому вы всегда должны помнить о выявлении потенциальных рисков.
95% нашего кода не используется — 5% все еще где-то используется. Очевидно, один из наших компонентов все еще использует стиль из этой библиотеки — маленькая стрелка в ползунке дудла. Поскольку он такой маленький, мы можем вручную включить эти стили в кнопку.
Рисунок 7. Компонент все еще использует удаленную библиотеку
Поэтому, если вы удалите код, убедитесь, что у вас есть правильный рабочий процесс для тестирования, чтобы помочь вам охранять потенциально видимые регрессии риска.
Мы знаем, что многие ресурсы могут замедлять загрузку веб-страницы. Они могут истощать деньги пользователей и оказывать значительное влияние на их тарифный план, поэтому важно знать об этом.
используяогромная нагрузка на сетьОбзор: Lighthouse смог обнаружить проблемы с некоторыми нагрузками на нашу сеть.
Рисунок 8. Обнаружение большой нагрузки на сеть
Как вы можете видеть здесь, мы передаем более 3 МБ кода, что не редкость, особенно на мобильных устройствах.
В самом верху этого списка Lighthouse сообщает нам, что есть 2-мегабайтный несжатый пакет JavaScript от поставщиков. Это также проблема с подсветкой веб-пакетов.
Как говорится: самый быстрый запрос тот, который еще не сделан.
В идеале вы должны измерить ценность каждого ресурса, который вы отправляете пользователю, измерить производительность этих ресурсов и на основе первоначального опыта решить, действительно ли стоит его передавать. Потому что иногда эти ресурсы могут задерживаться, лениво загружаться или обрабатываться во время простоя.
В нашем случае, поскольку мы имеем дело с большим количеством пакетов JavaScript, нам повезло, потому что у сообщества JavaScript есть множество инструментов для проверки пакетов JavaScript.
Рисунок 9. Обзор пакета JavaScript
Мы начали использовать анализатор пакетов webpack, и он сказал нам, что у нас есть зависимость под названием unicode, которая представляет собой 1,6 МБ проанализированного JavaScript, очень большой файл.
Затем заходим в наш редактор, и используем плагин Import Cost для готового визуального кода, через который мы можем посмотреть стоимость каждого модуля нашего импорта. Это может помочь нам определить, какой компонент содержит справочный код для этого модуля.
Затем мы переключаемся на другой инструмент, BundlePhobia. Этот инструмент позволяет вам ввести имя любого пакета NPM и фактически увидеть его предполагаемый размер после того, как он был сжат и заархивирован. Мы нашли хорошую альтернативу, модуль slug, который мы использовали, весил всего 2,2 КБ, поэтому мы использовали его.
Это сильно повлияло на наше выступление. Благодаря этому изменению и поиску других возможностей уменьшить размер пакета JavaScript мы сэкономили 2,1 МБ кода.
Комбинируя сжатие и уменьшение размера этих пакетов, мы видим общее улучшение на 65%. Мы нашли, что это действительно стоит сделать.
В общем, постарайтесь исключить ненужные загрузки с вашего веб-сайта и из приложений. Инвентаризация ресурсов и измерение их влияния на производительность могут привести к новым изменениям, поэтому регулярно проверяйте свои ресурсы.
Сократите время запуска JavaScript с помощью разделения кода
Хотя большая сетевая нагрузка может оказать существенное влияние на наши приложения, есть еще одна вещь, которая может оказать огромное влияние — это JavaScript.
JavaScript — ваш самый дорогой актив. На мобильных устройствах, если вы отправляете много JavaScript, это может задержать взаимодействие пользователя с компонентами интерфейса. Это означает, что их клики по пользовательскому интерфейсу могут быть бессмысленными. Поэтому крайне важно понять, почему стоимость JavaScript так высока.
Вот как браузеры обрабатывают JavaScript.
Рисунок 10. Обработка JavaScript
Сначала нам нужно загрузить скрипт, наш движок JavaScript должен разобрать код, скомпилировать его и выполнить.
Теперь эти этапы (обработки) не занимают много времени на устройствах высокого класса, таких как настольные компьютеры или ноутбуки, или даже на мобильных телефонах высокого класса. Но на телефоне среднего класса этот процесс может занять в 5-10 раз больше времени. Это именно то, что задерживает взаимодействие, поэтому очень важно избавиться от него.
Чтобы помочь вам обнаружить эти проблемы с вашим приложением, мы добавили в Lighthouse новый инструмент проверки времени запуска JavaScript.
Рисунок 11. Обзор времени запуска JavaScript
В примере с приложением Oodle видно, что нам потребовалось 1,8 секунды, чтобы запустить JavaScript. Что я сделал за это время, так это статически импортировал все маршруты и компоненты в целый пакет JavaScript.
Одним из решений этой проблемы является использование разделения кода.
Концепция разделения кода заключается в том, чтобы вместо того, чтобы давать своим пользователям сразу целую пиццу JavaScript, давайте им только тот фрагмент, который им нужен за раз?
Разделение кода может применяться на уровне маршрута или на уровне компонентов. Он работает с React и React Loadable, Vue.js, Angular, Polymer, Preact и некоторыми другими библиотеками.
Мы внедрили в наше приложение разделение кода, переключившись со статического на динамический импорт, чтобы получить нужный нам асинхронный код с ленивой загрузкой.
Рисунок 13. Разделение кода с помощью динамического импорта
Этот эффект уменьшает размер пакета и экономит время запуска нашего JavaScript. Это сократило время до 0,78 секунды, ускорив работу приложения на 56%.
В общем, если вы создаете свой опыт работы с JavaScript, обязательно отправляйте пользователям только тот код, который им нужен.
Используйте такие концепции, как разделение кода, исследуйте такие идеи, как встряхивание дерева, и ознакомьтесь с репозиторием webpack-libs-optimizations, чтобы узнать, как уменьшить размер библиотек при использовании webpack.
Оптимизация изображений
Шутка о производительности загрузки изображений
В приложении Oodle мы используем много изображений. К сожалению, Lighthouse относится к этому с гораздо меньшим энтузиазмом, чем мы. Фактически, мы умерли во всех трех обзорах, связанных с изображением.
Мы забыли оптимизировать изображения, неправильно их размер, и мы могли бы оптимизировать изображения с другими форматами.
Рисунок 14. Обзор изображения маяка
Начали оптимизировать картинку.
Для одноразовой оптимизации вы можете использовать инструменты визуализации, такие как ImageOptim или XNConvert.
Более автоматизированный подход заключается в использовании библиотеки, такой как imagemin, которая оптимизирует изображения в процессе сборки.
Таким образом, вы можете быть уверены, что изображения, которые вы добавляете в будущем, автоматически оптимизируются. Некоторые CDN, такие как Akamai или сторонние решения, такие как Cloudinary или Fastly, также предлагают комплексные решения по оптимизации изображений. Таким образом, вы также можете безопасно размещать свои изображения на этих сервисах.
Такие проекты, как Thumbor или Imageflow, также предлагают альтернативы самостоятельному размещению, если вы не хотите делать это из-за проблем с затратами или задержкой.
Рисунок 15. До и после оптимизации
Наши фоновые изображения в формате PNG помечены как большие в webpack, и это правда. После изменения размера окна просмотра и оптимизации с помощью ImageOptim мы уменьшили его до 100 КБ, что является приемлемым.
Мы неоднократно делали это для изображений на сайте, что значительно уменьшало общий размер страницы.
Используйте правильный формат для анимированного контента
Гифки очень дорогие. Удивительно, но формат GIF никогда не предназначался для использования в качестве платформы для анимации. Поэтому переход на более подходящий формат видео может значительно сэкономить размер файла.
В приложении Oodle мы использовали GIF на главной странице в качестве вступительной анимации. По данным Lighthouse, переход на более эффективный формат видео экономит более 7 МБ. Наша анимация весит почти 7,3 Мб, что слишком много для любого веб-сайта, поэтому мы превратили ее в элемент видео с двумя исходными файлами — mp4 и WebM, для совместимости с большим количеством браузеров.
Рис. 16. Замена анимированных GIF-файлов видео
Мы используем инструмент FFmpeg для преобразования анимированных GIF-файлов в файлы mp4. Формат WebM экономит еще больше — API ImageOptim может сделать это преобразование.
Это преобразование сэкономило нам более 80% от общего объема. Это приводит нас к примерно 1 мб.
Тем не менее, 1 МБ — это большой ресурс для сетевых передач, особенно для пользователей с ограниченной пропускной способностью. К счастью, мы можем использовать API эффективного типа, чтобы определить, что они находятся в медленной сети, и предоставить им меньший JPEG.
Этот интерфейс использует эффективное время приема-передачи и значения сокращения для определения типа сети, которую использует пользователь. Он просто возвращает строку типа slow 2G, 2G, 3G или 4G. Поэтому, исходя из этого значения, для пользователей ниже 4G мы заменили элемент видео изображением.
Это немного жертвует пользовательским интерфейсом, но, по крайней мере, в медленных сетях сайт можно использовать.
Ленивая загрузка закадровых изображений
Карусельные анимации, слайдеры или очень длинные страницы часто загружают изображения, даже если пользователь не сразу видит их на странице.
Lighthouse отметит это поведение при просмотре закадрового изображения, которое вы также можете сами увидеть на сетевой панели DevTools. Если вы видите много входящих изображений, но видны только некоторые из них, это означает, что вы можете рассмотреть возможность их ленивой загрузки.
Браузеры изначально не поддерживают ленивую загрузку, поэтому для добавления этой функциональности нам нужно использовать JavaScript. Мы используем библиотеку Lazysizes, чтобы добавить ленивую загрузку к нашим обложкам Oodle.
Lazysizes умен, потому что он не только отслеживает изменения видимости элементов, но также предварительно выбирает элементы рядом с представлением для лучшего взаимодействия с пользователем. Он также обеспечивает дополнительную интеграцию IntersectionObserver, что дает вам очень эффективный поиск видимости.
После этого изменения наши изображения будут извлекаться по запросу. Если вы хотите углубиться в тему, загляните на images.guide — очень удобный и всеобъемлющий ресурс.
images.guide: https://images.guide/
Помогает браузерам раньше обслуживать ключевые ресурсы
Не каждый байт, отправленный по сети в браузер, одинаково важен, и браузер это знает. Многие браузеры имеют эвристику, чтобы решить, что они должны получить в первую очередь. Поэтому иногда они получают CSS раньше, чем изображения или скрипты.
Что может быть полезно, так это то, что мы, как авторы страниц, можем сообщить браузеру, что для нас действительно важно. К счастью, за последние несколько лет браузеры добавили ряд функций, помогающих нам добиться этого, например подсказки ресурсов с использованием ссылки rel=preconnect, preload или prefetch.
Эти функции веб-платформы могут помочь браузеру получить нужный ресурс в нужное время, и они будут более эффективными, чем какой-либо индивидуальный подход к загрузке, основанный на логике, реализованный с помощью сценариев.
Давайте посмотрим, как Lighthouse на самом деле помогает нам эффективно использовать эти функции.
Первое, что позволяет нам сделать Lighthouse, — это избежать многочисленных дорогостоящих запросов туда и обратно к одному источнику.
Рис. 17. Как избежать множественных дорогостоящих двусторонних запросов к любому источнику
Для приложения Oodle мы активно используем шрифты Google. Всякий раз, когда на странице используется таблица стилей Google Fonts, она связывается с двумя субдоменами. Lighthouse сообщает нам, что если мы сможем разогреть это соединение, мы сможем сэкономить до 300 мс на начальном соединении.
С помощью link rel preconnect мы можем эффективно маскировать задержки соединения.
Это может иметь большое значение, особенно для ресурсов, таких как Google Fonts, которые размещают CSS шрифтов на googleapis.com и ресурсы шрифтов на Gstatic. Поэтому мы применили эту оптимизацию и оптимизировали на несколько сотен миллисекунд.
Следующее, что предлагает Lighthouse, — жадно загружать критические запросы.
Рисунок 18. Предварительная загрузка критических запросов
очень мощная функция, она информирует браузер о том, что ресурс необходим для текущей навигации, и пытается получить его как можно скорее.
Теперь Lighthouse говорит нам, что мы должны предварительно загрузить наш ключевой ресурс веб-шрифта, поскольку мы загружаем два веб-шрифта.
Предварительная загрузка веб-шрифтов выглядит так: укажите rel=preload, передайте тип шрифта в поле as и укажите тип загружаемого шрифта, например, woff2.
Влияние, которое это окажет на вашу страницу, будет очень заметным.
Рисунок 19. Влияние предварительной загрузки ресурсов
В общем, если вы не используете предварительную загрузку ссылки rel, если вы оказались на веб-шрифтах, это важная страница, браузер должен сначала получить HTML, проанализировать CSS и другие ресурсы для следующего, и, наконец, получить ваш веб-сайт. шрифты .
С предварительной загрузкой ссылки, как только браузер проанализирует HTML, он может начать загрузку этих веб-шрифтов раньше. Для нашего приложения это сокращает время, которое мы тратим на рендеринг текста с помощью веб-шрифтов.
Теперь, если вы хотите попробовать предварительно загрузить шрифты с помощью Google Fonts, это не так просто, у нас есть еще один вопрос.
URL-адреса шрифтов Google, которые мы указываем в шрифтах в наших таблицах стилей, регулярно обновляются командой Google Fonts. Эти URL-адреса могут быть устаревшими или регулярно обновляться, поэтому, если вы хотите полностью контролировать загрузку шрифтов, мы рекомендуем самостоятельно размещать свои веб-шрифты. Это также здорово, потому что дает вам доступ к таким вещам, как предварительная загрузка ссылок.
В нашем случае мы обнаружили, что инструмент Google Web Fonts Helper очень полезен, поскольку он помогает нам отключить некоторые веб-шрифты и установить их локально, поэтому проверьте этот инструмент.
Независимо от того, включаете ли вы веб-шрифты или JavaScript как часть важного ресурса, заставьте браузер обслуживать этот критический ресурс как можно быстрее.
Эксперимент: приоритетные советы
Есть что-то особенное, чтобы поделиться с вами сегодня. В дополнение к таким функциям, как подсказки ресурсов и предварительная загрузка, мы также работаем над новой экспериментальной функцией браузера, которую мы называем подсказками приоритета.
Рисунок 20. Подсказка приоритета
Эта новая функция позволяет предупредить браузер о важности ресурса. Он предоставляет новое свойство — важность — которое может принимать значения low, high или auto.
Это позволяет нам снизить приоритетность менее важных ресурсов, таких как некритические стили, изображения или вызовы API-интерфейса, чтобы уменьшить вытеснение трафика. Мы также можем повысить приоритет более важных вещей, таких как наши главные изображения.
Для нашего приложения Oodle это фактически дало нам возможность оптимизировать.
Рисунок 21. Установка приоритета первого видимого контента
在我们对图像设置懒加载之前，浏览器的做法是，我们将这个图片轮播与所有涂鸦一起使用，而浏览器会在轮播最开始时以高优先级获取所有图像。不幸的是，轮播中间的图像对用户来说是最重要的。所以我们的做法是，将背景图像的重要性设置得非常低，前景图像的重要性设置得非常高，这在慢速 3G 时能带来 2 秒的提速，我们也能够快速地获取和渲染这些图像。 это был замечательный опыт.
Мы надеемся, что через несколько недель эта функция на Канарских островах, пожалуйста, обратите пристальное внимание.
Разработайте стратегию загрузки веб-шрифтов
Типографика — это основа хорошего дизайна, и если вы используете веб-шрифты, в идеале вы не хотите блокировать отрисовку текста и уж точно не хотите отображать невидимый текст.
Мы подчеркиваем это в Lighthouse, вavoid invisible text while web fonts are loadingможно найти в обзоре.
Рисунок 22. Избегайте невидимого текста при загрузке веб-шрифтов
Если вы используете блок шрифта для загрузки веб-шрифта, а загрузка шрифта занимает много времени, вы позволяете браузеру решать, что делать. Некоторые браузеры будут ждать до трех секунд, прежде чем вернуться к системным шрифтам, и как только шрифты будут загружены, браузер в конечном итоге переключится обратно на шрифты.
Мы пытаемся избежать этого невидимого текста, и в этом случае мы не сможем увидеть классические граффити этой недели, если веб-шрифты будут загружаться слишком долго. К счастью, с новой функцией под названием font-display у вас действительно больше контроля над этим процессом.
Отображение шрифтов помогает вам решить, как веб-шрифты отображаются или отступают в зависимости от того, сколько времени требуется для замены.
В этом случае мы используем замену отображения шрифта. Swap обеспечивает ноль секундных периодов блокировки и бесконечные периоды замены для шрифтов. Это означает, что если для загрузки шрифта потребуется некоторое время, браузер немедленно отобразит текст альтернативным шрифтом. Как только шрифт доступен, он преобразует его.
Это отличная функция для нашего приложения, позволяющая отображать осмысленный текст очень рано и преобразовывать его, как только веб-шрифт будет готов.
Рисунок 23. Результаты отображения шрифта
В общем, если вы используете веб-шрифты, и они занимают большую часть Интернета, вам нужна хорошая стратегия загрузки веб-шрифтов.
Есть много веб-платформ, которые могут помочь вам оптимизировать процесс загрузки шрифтов, и вы также можете проверить репозиторий Zach Leatherman Web Font Recipes, потому что он потрясающий.
Web Font Recipes repo: https://www.zachleat.com/web/recipes/
Уменьшите количество сценариев блокировки рендеринга
Есть и другие части нашего приложения, которые можно разместить на ранних этапах цепочки загрузки, чтобы заранее обеспечить некоторый базовый пользовательский интерфейс.
На временной шкале Lighthouse вы можете видеть, что пользователь ничего не видит в течение первых нескольких секунд загрузки всех ресурсов.
Рисунок 24. Уменьшение вероятности блокировки таблиц стилей рендеринга
Загрузка и обработка внешних таблиц стилей заблокировала процесс рендеринга.
Мы можем попытаться оптимизировать наш критический путь рендеринга, предоставив сначала несколько стилей.
Если мы извлечем стили, отвечающие за первоначальный рендеринг, и встроим их в HTML, браузер сможет отображать их напрямую, не дожидаясь внешней таблицы стилей.
В нашем случае мы используем модуль NPM под названием Critical для встраивания важного содержимого в index.html на этапе сборки.
Хотя этот модуль сделал за нас большую часть тяжелой работы, все же было немного сложно заставить его работать без сбоев на разных маршрутах.
Если вы не будете осторожны или структура вашего сайта очень сложна, может быть очень сложно внедрить этот шаблон, если вы не спланировали архитектуру оболочки приложения с самого начала.
Вот почему важно заранее учитывать факторы производительности. Если вы не проектируете производительность с самого начала, у вас могут возникнуть проблемы с ее реализацией позже.
В конечном итоге наш риск окупился, и нам удалось заставить его работать, и приложение начало доставлять контент раньше, что значительно улучшило наше время до первой осмысленной раскраски.
результат
Оценка производительности маяка выросла от 23 до 91. Довольно достойное улучшение скорости. Все эти изменения обусловлены нашим постоянным обзором и соблюдением отчетов маяка. Если вы хотите посмотреть, как мы используем все улучшения технически, не стесняйтесь проверить наше репо (http://github.com/google /oodle-demo), особенно PR.
Прогнозируемая производительность — взаимодействие с пользователем на основе данных
Мы считаем, что машинное обучение открывает захватывающие возможности во многих областях будущего. Одна идея, которая, как мы надеемся, вызовет больше экспериментов в будущем, заключается в том, что реальные данные могут действительно направлять пользовательский опыт, который мы создаем.
Сегодня мы принимаем множество произвольных решений о том, что может хотеть или в чем нуждается пользователь, и, таким образом, какие ресурсы должны быть предварительно выбраны, предварительно загружены или предварительно кэшированы. Если мы угадали правильно, мы можем установить приоритеты для небольшого количества ресурсов, но трудно масштабировать его на весь сайт.
На самом деле у нас есть данные для лучшей поддержки наших оптимизаций. Используя API отчетов Google Analytics, мы можем увидеть следующую домашнюю страницу и процент выхода для любого URL-адреса на нашем сайте, чтобы сделать выводы о том, каким ресурсам мы должны отдавать приоритет.
Если мы объединим это с хорошей вероятностной моделью, мы избежим потери пользовательских данных из-за агрессивной предварительной загрузки контента. Мы можем использовать данные Google Analytics и реализовывать такие модели с помощью машинного обучения и таких моделей, как цепи Маркова или нейронные сети.
Рисунок 25. Объединение веб-приложений на основе данных
Чтобы облегчить этот эксперимент, мы рады объявить о новой инициативе под названием Guess.js.
Рисунок 26. Guess.js
Guess.js — это проект, ориентированный на взаимодействие с пользователями в Интернете, основанное на данных. Мы надеемся, что это вдохновит людей на изучение использования данных для повышения производительности сети и других целей. Он полностью с открытым исходным кодом и доступен на GitHub. Это было создано Минко Гечевым, Кайлом Мэтьюзом из Гэтсби, Кэти Хемпениус и некоторыми другими в сотрудничестве с сообществом открытого исходного кода.
Суммировать
Оценки и метрики помогают повысить скорость Интернета, но сами по себе они являются средством, а не целью.
Мы все сталкивались с медленной загрузкой веб-страниц, но теперь у нас есть возможность предоставить пользователям гораздо более приятный опыт быстрой загрузки.
Повышение производительности — это путешествие. Многие небольшие изменения могут привести к огромной прибыли. Используя правильные инструменты оптимизации и уделяя пристальное внимание отчетам Lighthouse, вы можете предоставить своим пользователям лучший и более инклюзивный опыт.
Спасибо: Уорд Питерс, Минко Гечев, Кайл Мэтьюз, Кэти Хемпениус, Дом Фаролино, Йоав Вайс, Сьюзи Лу, Юсуке Уцуномия, Том Анкерс, Lighthouse и Google Doodles.
Английский оригинал:
https://developers.google.com/web/updates/2018/08/web-performance-made-easy
«UC International Technology» стремится делиться с вами высококачественными техническими статьями.
Добро пожаловать, чтобы подписаться на наш официальный аккаунт и поделиться статьей с друзьями