Обратите внимание на фронтальный утренний чат, следите за 30-й | Фронтальная утренняя чат-конференция BFF, специальная сессия (GraphQL, единый шлюз, управление доступом к API, сверхкрупномасштабный кластер, преобразование протокола, аспекты безопасности, высокая параллелизм, визуальная оркестровка, построение единой стабильности...) 8-14 Live весь день, 9 лекторов,Нажмите, чтобы зарегистрироваться, чтобы посмотреть прямую трансляцию 👉 ):
Фронтенд заранее заговорил о конференции и провел ее совместно с Nuggets. Добавьте codingdreamer в техническую группу конференции и побеждайте на новом старте, Все предыдущие серии полностью записаны и транслируются.Начните и разблокируйте все сразу
Эта статья является 18-м сеансом сеанса оптимизации производительности раннего чата, а также 127-м сеансом сеанса раннего чата, опубликованным Али Флигги-Тайву.
Самостоятельное введение
Всем привет, я Ху Хао из Fliggy, и мой никнейм Taiwu. Не спешите начинать, потому что я только что видел скриншоты, которыми поделились предыдущие наставники в кругу друзей маленького помощника, и в то же время видел некоторые ваши вопросы. Кто-то сказал, что я поделился этой статьей вНаггетсЕсть соответствующая статья. Я считаю, что многие друзья, возможно, прочитали эту статью. Я хочу сказать, хотите ли вы послушать мой рассказ после просмотра этой статьи, я думаю, вам все равно нужно ее послушать.
Основная функция статьи — распространение, а некоторые галантерейные товары все же должны быть в формате PPT, поэтому всем не стоит позволять фронтенду рано говорить о последнем обмене в 2020 году. Первые два больших парня более хардкорные: IDE и визуализация. Наконец-то мы вернулись к оптимизации производительности на традиционном H5, которая может быть не такой серьезной, как первые две, но я надеюсь, что она может вдохновить вас.
Этот PPT также использовался для обмена в нашей группе ранее, поэтому он немного ленив.На самом деле, большая часть контента похожа, но некоторые из них все еще нуждаются в некоторых конкретных пояснениях. Эта публикация называется "Fliggy Double 11 — Оптимизация производительности в Интернете". Одной из моих обязанностей во время работы над Double 11 было управление производительностью, поэтому у меня все еще есть определенное понимание общей оптимизации производительности Double 11 в Интернете, и я надеюсь донести это понимание до Всех.
содержание
Целое будет разделено на три части, чтобы объяснить.
- задний план
- направление оптимизации. Основной метод оптимизации — это 6 вещей, которые вы видите справа, конкретное содержание будет подробно объяснено позже.
- Подводить итоги и планировать
задний план
Во-первых, это фон. Каковы соображения по переходу с Weex на Интернет?
Эволюция стека технологий
Наш Fliggy начинался с размещения первой страницы H5 в 2013 году, пока мы не перешли на Weex в целом в 2016 году. И Weex, и Rax в основном визуализируются Weex, в Fliggy и Hand Tao. До июня 2020 года мы снова перешли на H5 в соответствии со стратегией группы в целом, и стек технологий также был унифицирован, используя стек технологий Rax 1.0 в целом.
Возможно, были ученики из Ракса, которые пришли к интерфейсу, чтобы поболтать и поделиться ранее. Как нам перейти с Weex на H5, исходя из такого соображения, наша уверенность в производительности Weex все еще выше, чем у H5. Но зачем переходить с относительно лучшего стека Weex на H5? В основном исходя из следующих соображений:
- Во-первых, мы считаем, что опыт исследований и разработок H5 должен быть лучшим, и после обновления ядра U4 и WKWebview UC во Fliggy мы считаем, что разрыв в производительности с Native постепенно сокращается, поэтому мы можем попытаться разработать H5.
- Во-вторых, в ответ на предыдущую стратегию мини-программ Alipay появляется все больше и больше сценариев развития мини-программ, а динамика развития мини-программ недостаточна, поскольку ее традиционное значение развития и система H5 относительно разделены. кодексов необходимо разработать. Если страницу нужно проголосовать за апплет и Н5 отдельно, это требует двойных затрат на разработку, что для нас неприемлемо, ведь рабочая сила так драгоценна;
- В-третьих, мы по-прежнему надеемся унифицировать конечное технологическое решение и надеемся получить набор кода, который можно доставлять на несколько концов, поддерживая H5, апплет и будущий Flutter. По сути, это уже текущий Flutter;
- В-четвертых, Rax1.0 также может поддерживать Weex, почему он не скомпилирован в Weex? Поскольку программы Weex и Mini имеют свои совместимые аспекты, они являются как подмножеством традиционных API, так и некоторыми отдельными API. Так что если мы хотим адаптировать Weex и апплет одновременно, это будет катастрофой для разработки. Ниже приведено простое сравнение сложности разработки.Нет предела простой разработке H5.Я считаю, что многие мелкие партнеры готовы его развивать, но он имеет определенные ограничения для небольших программ. Было бы неприемлемо, если бы апплет Weex plus разрабатывался одновременно и обе стороны были бы совместимы одновременно. И если это апплет H5 plus, вам нужно просто адаптировать апплет, чтобы завершить его. Это относительно приемлемо.
Это общий фон.
трудности, с которыми столкнулись
Исходя из этого, производительность H5 определенно немного хуже, чем производительность Weex. После H5, который только что был заменен ранее, и двух крупных рекламных акций (продвижение 618 и Национальный день), производительность Fliggy на месте составляет около 1,5 секунды для IOS и около 2 секунд для Android. По сравнению с площадкой Tao серии 618 производительность составляет 1,4 секунды и 2,1 секунды, что относительно похоже. Все в основном исчерпали общие методы оптимизации и нуждались в выходе в глубоководную зону. Для Fliggy Double 11 цель составляет 1,2 секунды для IOS и 1,6 секунды для Android, а общее улучшение составляет около 20%. В случае, если общие средства исчерпаны, также очень большой проблемой является увеличение на 20%.
А в сцене «Летучей свиньи»:
- летающая свиньяМодули сложные. Со стороны операционного бизнеса есть много идей для туристических сценариев, например, на карте головы должно быть видео, чтобы привлечь других к игре. И интерактивный анимационный модуль Fliggy. Существуют также типы списков Fliggy, а также некоторые модули агрегации для списков, которые относительно сложны. Некоторые из них отнимают много времени, а некоторые алгоритмы требуют много времени.
- Интерфейс RT относительно высок. И нет возможности оптимизировать серверную часть. Как и в случае со списком, это агрегация нескольких списков с персонализацией списка, и алгоритм хочет добавить различные модели для увеличения своего RT. Теория может принести определенное количество кликов. , У вас нет возможности опровергнуть других. Таким образом, вы можете позволить ему свободно увеличивать RT, и у вас нет выбора.
- Некоторые особенности туристической индустрии.. Некоторые из наших персонализаций или некоторые модули больше полагаются на информацию о позиционировании и информацию о пользователе, чтобы продвигать соответствующие продукты для всех. Информация о позиционировании и информация о пользователе еще больше замедлят время первого экрана, так что это вся оптимизация. Некоторые трудности, с которыми мы столкнулись.
Направление оптимизации
В ответ на эти трудности видение должно быть отделено от внешней стороны, стоя в направлении многофункциональной координации, в основном полагаясь на некоторые возможности клиента и сервера для выполнения общей оптимизации.
Идеи оптимизации
Общая идея оптимизации, давайте сначала поговорим об общей идее оптимизации:
- Первый этапбелый экран. Например, вся страница похожа на страницу, и процесс ее открытия с начала белого экрана в основном заключается в инициализации веб-просмотра, загрузке основного документа и загрузке базового JS. Первые несколько лекторов в основном упомянули эти процессы.Методы оптимизации фронтенда должны зависеть от кеша клиента и общие методы уменьшения размера пакета ресурсов;
- вторая стадияЗагрузка ситуации. Это в основном этап, на котором происходят запросы данных.Общие методы, которые можно использовать на этом этапе, аналогичны оптимизации на стороне сервера, разделению запросов и идее о том, что данные страницы могут быть разложены на первый экран и не -складывающийся экран. Рендеринг первого экрана, как можно меньше DOM, как можно меньше модулей и некоторая предварительная загрузка данных. Параллелизм данных, упомянутый ранее, и способ, которым клиентская сторона инициирует параллельные запросы данных. Несколько предыдущих лекторов также упомянули, что я не буду здесь вдаваться в подробности;
- последняя фазаэкран модуля. Медленно появляются элементы, которые можно загрузить на экран. Главное, что происходит за это время — загрузка модуля JS и отрисовка модуля. Общие средства здесь — это в основном упрощение JS для модулей и кэширование для модулей. Дело в том, что наше место в основном является строительной площадкой, какова концепция строительства? Это макет страницы внизу, его можно представить как получение от сервера по параметрам какие модули нужны для той или иной страницы, затем асинхронно вытаскивание этих модулей вниз, заливка данных в эти модули и их отображение. есть такая идея. Подобно тому, как вы разделяете свою страницу общего назначения на множество модулей для рендеринга, какие модули для рендеринга определяются данными на стороне сервера, что похоже на создание такой сцены.
Исходя из этих общих методов, все продумали, и все обязательно воспользуются, а эффект после использования как у 618, упомянутая ранее акция в честь Национального дня - это уже пик, и если вы захотите ее потом оптимизировать, вам нужно оторваться от них для дальнейшей оптимизации. К рекламным средствам относятся следующие:
- предварительный рендеринг. Это делается для того, чтобы обеспечить эффект открытия основного места проведения. Конкретная реализация будет упомянута позже;
- SSR. Предыдущие лекторы также упоминали, что теперь мы можем меньше упоминать SSR в сценарии C-стороны и использовать его реже. Но теперь я снова упоминаю SSR Почему? Это также для увеличения второй скорости открытия. В случае с Weex раньше скорость открытия в секундах всегда была увеличена, но после перехода на H5 она может быть не так хороша, как Weex в то время, поэтому нам нужно использовать некоторые вещи, такие как SSR, чтобы улучшить скорость открытия. наших страниц за секунды;
- Snapshot. Подобно снимкам страниц, упомянутым предыдущими лекторами, некоторые данные страницы или HTML-код страницы сохраняются напрямую. До того, как поступят реальные данные, предварительное отображение структуры страницы может значительно увеличить время просмотра пользователем, чтобы пользователь не ждал с таким нетерпением;
- SPA. Одностраничное приложение — это такая штука. Объедините несколько страниц, чтобы обеспечить плавный переход между страницами и улучшить ощущение движения пользователя.
В основном именно эти 4 очка гарантируют сцену двойной 11-й акции.
общая идеяпроцесс рендерингаС точки зрения, блоки соответствуют частям описанного выше процесса рендеринга, которые можно упростить. Видно, что SSR, Snapshop и предварительный рендеринг будут становиться все лучше и лучше сверху вниз, но это определенно применимо ко все меньшему количеству сцен. Об этом будет подробно сказано позже. Подобно некоторой предварительной загрузке на стороне клиента, автономному кэшированию ресурсов, запросам на искажение данных и кэшированию модулей, все эти распространенные методы уже давно интегрированы с клиентами.
интегралГлавная мысль, о котором я также упоминал ранее, — это передача давления, которая преобразует давление клиента на сервер. Некоторое кэширование, в зависимости от возможностей клиента, деформация сцены и, наконец, некоторые соматосенсорные оптимизации для пользователей, чтобы предоставить пользователям наилучшие впечатления.
предварительный рендеринг
Сначала поговорим о предварительном рендеринге. Лектор также упомянул предзагрузку ранее.Возможно сторона Флигги более агрессивна.Вы можете сначала посмотреть на эффект справа. После включения предрендеринга слева, нажмите на капсулу, похожую на основную площадку, и прыгайте в прошлое буквально за секунды, без ощущения какого-либо процесса рендеринга. Справа, если предварительный рендеринг не включен, будет процесс белого экрана, загрузки и загрузки модуля, что является очевидным сравнением.
что такое предварительный рендеринг? Клиент инициализирует контейнер и LoadUrl «за кадром» и завершает растеризацию страницы, прежде чем она появится на экране. То есть клиент напрямую загружает URL-адрес через Webview в фоновом режиме, а когда нам это нужно, он напрямую выполняет экранную операцию в Webview, так что это более радикально. Однако для обеспечения ключевой защиты основного места лучше иметь такую возможность на стороне устройства, да и опыт лучше.
Что особенного в предварительном рендеринге?
- Прямо из ниоткуда. очевидный опыт;
- Пользовательская сторона. Это может быть связано с тем, что он больше связан со стороной терминала, и, возможно, только терминал Fliggy может использовать такую возможность;
- несколько страниц. В настоящее время он используется только для основного места проведения, потому что, если вы думаете о фоне APP для постоянного запуска такого веб-просмотра, он определенно будет потреблять больше памяти и может вызвать некоторые риски сбоя. Таким образом, можно настроить только небольшое количество страниц.Если страниц больше, частота сбоев может быть все выше и выше.
Но после реализации такой схемы предварительного рендеринга FCP (время первого рендеринга первого экрана) увеличивается с 1-2 секунд до 100 миллисекунд на интерфейсе, а управление на стороне клиента составляет в основном 50-60 миллисекунд. Отображение страницы может быть завершено очень быстро.
Дизайн
Для разработки общего решения у нас будет платформа динамического распространения, такая как Orange, для настройки некоторых URL-адресов, которые мы хотим предварительно отобразить, и они будут динамически распространяться в приложение пользователя, и приложение может получить их после настройки, такой URL будет загружен в фоновом режиме, и страница будет обработана.После завершения растеризации страницы она будет помещена в кеш-пул.Также мы запустим мониторинг предупреждений о памяти, чтобы обеспечить стабильную работу APP.Если есть риск сбоя, мы автоматически освободим страницы в пуле кеша, мы все равно должны поддерживать стабильность и разработать такой контроль памяти.
Когда пользователь фактически посещает страницу H5, мы проверяем, попадает ли пользователь в предварительно обработанную конфигурацию URL. У нас будет доменное имя URL и некоторые специальные параметры URL-запроса для сравнения ключей. Если он попадет, он будет использовать URL-адрес в качестве ключа для поиска веб-просмотра в пуле кеша и непосредственно выполнить операцию на верхнем экране, а графический процессор напрямую отобразит верхний экран. Поскольку эта страница была визуализирована клиентом в фоновом режиме, она определенно несовместима с некоторой логикой во внешнем интерфейсе, поэтому нам нужно отправить событие документа клиенту после отображения реального экрана, чтобы уведомить страницу H5 после рендеринга. завершено, внешний интерфейс прослушивает это событие. После этого мы выполним некоторую обработку для отслеживания производительности, отслеживания страниц и, наконец, некоторых динамически доставляемых событий, которые должны быть совместимы во внешнем интерфейсе.
После этого общая логика отображения этой страницы завершена. После того, как пользователь покинет страницу, мы очистим соответствующий кеш веб-просмотра и немедленно перезапустим такой новый веб-просмотр в фоновом режиме через 300 миллисекунд, чтобы загрузить страницу, и снова запустим следующий общий процесс.
Предварительный рендеринг такого решения может быть немного более радикальным, чем предварительная загрузка только контейнера Webview и отсутствие запроса реальных данных. Но эффект будет относительно лучше.
SSR
Второй вариант — ССР. Какова цель перезапуска SSR? В общем, определение SSR в группе теперь постепенно переносится с исходного рендеринга на стороне сервера на рендеринг на стороне без сервера, следуя тенденции без сервера и постепенно обнаруживая использование SSR. Мы не являемся SSR в традиционном смысле, но в традиционном смысле SSR — это тип SSR, который напрямую возвращает основной документ HTML, аналогичный основному документу в эпоху ПК.
Наша разница заключается в том, чтобы посмотреть на сравнение двух процессов рендеринга ниже.Вышеупомянутый традиционный процесс рендеринга CSR.С помощью кэширования документов на стороне клиента и предварительной загрузки данных выполняется модуль JS и модуль рендеринга. С нашей стороны, на этом рисунке видно, что наш SSR — это HTML, возвращенный в интерфейсе. После того, как интерфейс вернет HTML, мы асинхронно гидратируем HTML на страницу. Это эквивалентно сохранению более позднего загружаемого модуля JS. процесс, подобный модулю рендеринга, поскольку в интерфейсе возвращается HTML, интерфейс может работать медленнее, чем обычно. Мы рассчитали, что для вставки HTML непосредственно на страницу потребуется около 10 мс. Таким образом, общее время загрузки и рендеринга модуля JS в следующем модуле сокращается, и мы сэкономим от 700 до 800 миллисекунд времени на нашей стороне, сравнение SSR и CSR.
Дизайн
Изменение всего процесса рендеринга основано на таком соображении, вместо прямого возврата структуры всей страницы в основной текст в традиционном понимании, а когда интерфейс возвращается, возвращая такой HTML для выполнения другого рендеринга.
Мышление, стоящее за этим, в основном основано на таком соображении: прежде чем Taobao также составил такой план, они сделали синхронный SSR и вернули его в основной документ. В то время они обнаружили, что после синхронного SSR время белого экрана станет больше, потому что он не может использовать некоторые возможности клиента, такие как автономные пакеты и предварительная загрузка данных, два клиента обеспечивают очень хорошие возможности. Мы использовали асинхронную схему SSR, которая должна возвращать HTML в интерфейсе.
Он имеет несколько преимуществ:
- Сокращение времени, затрачиваемого на загрузку модуля перед рендерингом. То есть после того, как базовые данные возвращены из модуля, мы можем отобразить страницу, не дожидаясь, пока модуль подтянет и отрендерит модуль;
- Рендеринг размещается на стороне сервера, что позволяет избежать влияния машинных контейнеров высокого и низкого уровня. На высокопроизводительных машинах рендеринг и извлечение модулей могут иметь незначительный эффект. Но для младших машин извлечение и рендеринг некоторых модулей занимает очень много времени. А если поставить рендеринг на сервер, то можно избежать влияния такого мощного и низкоуровневого машинного контейнера;
- Возможности клиента, оптимизированные для производительности, можно использовать повторно. Таким образом, мы можем использовать автономный пакет, предоставленный клиентом, и возможность предварительной загрузки данных, не теряя часть возможностей клиента.
Мы исходим из принципа минимизации затрат на дооснащение:
- На основе существующей ссылки добавьте только ссылку рендеринга SSR;
- Он может обеспечить плавное переключение с CSR на SSR;
- Необходимо только определить, можно ли возвращать HTML, вы можете переключиться на разные ссылки для выполнения рендеринга, а модуль может быть существенно повторно использовать так, что эффект SSR очень небольшой стоимости преобразования.
проблемы под рукой
- Один - как выполнить плавное переключение, то есть что делать, если проблема с SSR? Как понизить обратно? На основе рассмотрения нам нужно только судить, возвращает ли интерфейс HTML на стороне внешнего интерфейса, а затем мы можем перейти к другим ссылкам.Это относительно простой метод решения проблемы;
- Некоторые соображения по стабильности интерфейса. Поскольку в SSR должно быть много модулей, он может использовать некоторые переменные или использовать некоторые асинхронные, и может не получать конкретные данные модуля на стороне сервера, поэтому при возврате может появиться аналогичная ошибка или что-то подобное Сначала этот модуль не отображался, а затем он отображался на веб-стороне в Hydrate, как мигание страницы. Таким образом, общее обновление бизнес-модуля заключается в выполнении некоторых переменных на уровне SSR и выполнении некоторой обработки, аналогичной заполнителю для модуля, чтобы гарантировать инициализацию страницы и минимальное обновление гидрата;
- Поддержка иммерсивных заголовков. Иммерсивная титровальная панель должна зависеть от некоторых переменных на стороне клиента Высота навигационной панели клиента является необходимым параметром иммерсивной титровальной панели, и SSR определенно не может получить параметры на стороне клиента. Поэтому позже мы обнаружили, что при использовании innerHTML существует пробел для получения такой высоты заголовка.В настоящее время мы можем динамически устанавливать такую высоту с помощью стиля, чтобы добиться поддержки иммерсивного заголовка;
- Последний пункт, потому что мы сейчас строим эту сторону, равномерно отрисовывая страницу. Будь то автономный режим, предварительная загрузка данных или кэширование некоторых модулей, существует такая вещь, как унифицированная страница рендеринга. Для единой страницы рендеринга, подобной этой, после того, как она перейдет в автономный режим, конфигурация SSR в ней будет исправлена там, и она не может быть нацелена на одну страницу, что эквивалентно открытию SSR для всех ваших страниц. Некоторые из наших страниц определенно не обязательно хорошо адаптированы, или, исходя из соображений трафика, все страницы не могут открыть SSR. Таким образом, мы должны добавить еще один уровень перехвата, чтобы определить, использовать ли ссылку SSR или обычную ссылку CSR. Мы перехватываем доменное имя и определяем, находится ли оно в белом списке, оценивая следующий запрос. В белом списке берите ссылку SSR, иначе берите ссылку CSR.
После завершения этих соображений мы успешно реализовали схему SSR и добились хороших результатов.В принципе, после использования SSR в предыдущие 1 ~ 2 секунды среднее потребление времени может быть уменьшено до менее 1 секунды.
Snapshot
Снимок страницы. Сначала посмотрите на эффект справа. После включения моментального снимка ссылка «Загрузка» отсутствует. Просто нажмите на страницу, и страница непосредственно выполнит аналогичный прямолинейный эффект. Snapshot на самом деле лучше, чем SSR, но зачем нам SSR, когда у нас есть Snapshot?
- Во-первых, в таком сценарии, как маркетинговая страница, процент повторных посещений относительно низок. Вероятность того, что пользователь откроет страницу во второй раз, составляет всего 10-30%. Таким образом, Snapshot кэширует эти данные, и его частота попаданий составляет всего 10–30% от такой скорости движения;
- Во-вторых, Snapshot подходит для сценария, отличного от тысяч людей. Кое-что похоже на то, о чем говорили предыдущие лекторы, а именно своевременность товара, поэтому некоторые сценарии не подходят для Snapshot.
Для этого снимка страницы мы разработали два решения. Один из вариантовкеш интерфейса, схема в традиционном пониманииКэширование HTML. Почему эти две схемы сосуществуют?
Один вид площадки меняется каждый день, на самом деле, если вы смотрите Double 11 или Double 12, вы идете на площадку, и порядок модулей и логика отображения данных модулей будет пересматриваться каждый день. Таким образом, в условиях, которые меняются каждый день, использование кэширования HTML неизбежно приведет к некоторым проблемам с перепрошивкой. Например, если вы посетили эту страницу вчера, а затем снова зашли на эту страницу сегодня, на ней может отсутствовать несколько модулей или может быть несколько товаров, а ее ямы изменились с 4 на 6, так что после того, как вы зайдете, вся Страница будет мигать случайным образом, и в этом процессе мигания может возникнуть много проблем и некоторые непредсказуемые проблемы. Например, модули могут рендериться неоднократно, а некоторые модули могут располагаться не на своем месте, что является особенно метафизической проблемой.
Поэтому мы разработали второй способ кэширования интерфейса.Кэширование интерфейса совмещено с кэшированием модуля.В принципе, производительность может быть в основном такой же, как и при прямом кэшировании HTML. Поскольку кеш интерфейса и данные кеша модуля относительно фиксированы, они избегают мерцания, и почему у нас такое сосуществование, мы обнаружим, что кеш HTML не бесполезен, как и сцена справа, все места, такие как Эта сцена, он принципиально не будет меняться в течение всего периода продвижения. Таким образом, использование кэширования HTML для повышения эффективности загрузки — это использование кэширования HTML.
Дизайн
Вся схема устроена следующим образом:
- **Кэш HTML. ** Его преимуществами являются высокая скорость отображения и простота управления, а его недостаток заключается в том, что в случае неуверенных модулей страница может мигать, но применимая сцена аналогична сценам для всех мест. Кэширование HTML похоже на то, что все могут понять, это то, что после отображения всех страниц вы сохраняете DOM первого экрана в кеш, и когда вы в следующий раз заходите на эту страницу, вы сначала идете в кеш, чтобы получить такой HTML, Сначала поместите его на экран и сначала выполните на нем операцию на экране. После того, как вернутся реальные данные, выполните операцию гидрата на таком интерфейсе;
- ** Кэш интерфейса. **Почему кеш интерфейса связан со снимком страницы. Потому что я только что рассказал о построении такой сцены, какие модули на самом деле возвращает интерфейс, и данные также возвращаются интерфейсом. Итак, пока мы кешируем интерфейс, мы знаем, какие модули есть на этой странице и каковы данные этих модулей.Пока мы кешируем этот интерфейс, мы можем напрямую отображать страницу через этот интерфейс. Его преимущество в том, что отображение страницы очень стабильное, а недостаток в том, что по сравнению с кэшированием HTML его отображение будет относительно медленнее, а кеш интерфейса кэширует JS всей страницы, то есть всего интерфейса, что относительно По сравнению с кэшированием HTML, его кеш будет занимать много места, но он подходит для большего количества сценариев. Некоторые из наших основных площадок, такие как super baby, list площадок и популярных площадок, используют метод моментального снимка страницы такого кэша интерфейса.
Еще два момента, некоторые дизайнерские идеи:
- Первый находится в кеше HTML, похожий на те товарные ямы, что у нас есть некоторая своевременность, мы не хотим сохранять HTML, сохраняем DOM, мы можемНастройте некоторые имена классов. Чтобы установить эти модули, при сохранении мы идентифицируем эти имена классов, чтобы удалить их или сохранить только родительский узел, чтобы решить срочную проблему. Кроме того, основываясь на дизайне такого имени класса, мы можем создать несколько похожих списков пролистывания, мы сохраняем только первые несколько элементов или аналогично баннеру с изображением заголовка, мы сохраняем только первый элемент. Такой дизайн уменьшает размер и эффективность кэша HTML;
- второйМастер кеша. Если кеш разблокировать без ограничений, то точно не получится. Мы должны разработать мастер кеша, чтобы контролировать количество кешей. Мы используем LRU (алгоритм) для медленного удаления некоторых кэшированных данных, которые реже всего используются и к которым чаще всего обращаются, и кэшируют новые, чтобы контролировать максимальное число в целом.На тот момент мы должны были кэшировать не более 8 отдельных. После более чем 8 будут сделаны некоторые суждения об отбраковке, чтобы обеспечить стабильность кэша.
SPA
Последний пункт – СПА. Мы медленно делаем некоторые оптимизации на странице, и пользовательский опыт также очень хорош. А вот опыт переключения между страницами не очень. Потому что, прежде чем вы на самом деле увидели, что внизу была панель вкладок. Но на самом деле это несколько страниц.Если вы переключите вкладку внизу так же, как и раньше, это на самом деле переход на страницу, метод замены, и вся страница будет обновлена, что очень плохо.
В Double 11 мы внесли в него улучшения. Нижняя полоса — это общая коробка пакета, когда мы переключаемся, щелкнув нижнюю полосу, нам нужно только получить данные. Только что упомянул этот момент, наша страница получается через данные в модули, и собирается через модули. Так что нам нужно только знать, какие модули есть, и мы можем составлять страницы. Таким образом, когда мы переключаем вкладки, нам нужно только получить данные, получить модуль и заменить DOM страницы, мы можем выполнить такой переход на страницу без полной замены.
Почему это реализовано на основе SPA, или просто упомянул этот момент.
- Создание страницы сформировало относительно зрелую систему, которая является нашей структурой страницы. Она разделяет набор решений / ядра-рендеринга. Она не будет связана со страницами, но является бизнес-модулем. Макет, стоящий за ней, и все страницы 1. Просто модули выше разные, поэтому страницы, которые вы видите, разные, а остальные макеты позади всегда одинаковы;
- Второй момент заключается в том, что каждый бизнес-модуль страницы получается через данные, оба из которых являются необходимыми условиями для переключения такого SPA. Через модуль сбора данных нам нужно только переключить DOM, чтобы сделать переход между страницами, при обратном переходе нам нужно только кэшировать модуль, чтобы сформировать бессмысленный эффект переключения.
Оптимальная эволюция
После того, как наша первая версия дизайна включила SPA, мы получили данные этого модуля, заменили модуль, соответствующий текущей вкладке, и обновили страницу. Но мы обнаружили, что есть проблема: если постоянно заменять весь модуль, он все еще относительно застрял. По сравнению с одностраничным приложением в нашем понимании в прямом традиционном смысле все еще есть небольшой пробел, поэтому мы его модернизировали.
Мы кэшируем только DOM первого экрана, чтобы сократить процесс сбора данных. А на высокопроизводительных машинах мы попросим, чтобы после завершения рендеринга данных первой вкладки мы предварительно загрузили данные нескольких других вкладок. Таким образом, нет процесса сбора данных, когда следующий коммутатор завершен, и мы можем получить к ним прямой доступ. Это эквивалентно получению данных между несколькими страницами одновременно, мы можем вырезать вкладку, чтобы создать эффект шелковистого переключения. Нам просто нужно скрыть DOM внутри других контейнеров вкладок. Просто отобразите DOM, который должен отображаться.
Предварительное кэширование ресурсов и данных
Напоследок хотелось бы отметить два небольших момента, о которых уже упоминали лекторы. По сути, каждая оптимизация требует автономных возможностей клиента, параллельных запросов автономных пакетов и данных, и я думаю, что это в основном используется каждый раз на стороне H5.
Но если говорить о небольшом дизайне, мы разработали **URL для страницы места проведения.+В методе package ** мы введем страницу, которая должна быть в автономном режиме на фоне почтового голубя, в сцене места проведения. Наш почтовый голубь будет запускать кукловод в фоновом режиме для получения ресурсов страницы, а затем с помощью некоторых операций прокрутки мы также получим некоторые лениво загруженные ресурсы. Поместите весь ресурс в пакет ресурсов и, наконец, сопоставьте его при посещении реальной страницы с помощью метода хеширования.
Второй момент, такую часть параллельного запроса данных мы проектируем относительно обычногоХит памятиа такжеМисс миссВ таком состоянии мы также спроектировалиOngoingтакое состояние. Мы думаем, что пока клиент инициирует запрос, он должен быть быстрее, чем реальный запрос, инициированный внешним интерфейсом, потому что на самом деле он должен быть заранее, поэтому мы будем ждать возврата реального запроса клиента, и тогда мы возьмем клиента вместо повторной инициации запроса.
Подводить итоги и планировать
Все здесь не так подробно, во всяком случае, мы, наконец, достигли такой цели в то время, исходя из того, что мы сказали ранее, будь то общее средство или какое-то средство улучшения. Общий метод также может оказать большую помощь, а метод улучшения на его основе имеет более высокое улучшение. Так или иначе, конечной целью является достижение такой цели, и после этих вещей у нас будет ощущение, что можно ожидать будущего.
Суммировать
Оптимизация производительности, вы постепенно обнаружите, что она постепенно выросла из такой функции во внешнем интерфейсе до такого способа многофункционального сотрудничества. Медленно, если вы оптимизируете, вы определенно не сможете стоять в такой перспективе внешнего интерфейса, и постепенно вы будете полагаться на SSR, как упомянутый выше NSR, SSR на стороне сервера и ESR, который у нас есть сейчас. Пограничные вычисления CDN — это что-то вроде этого, и постепенно вы обнаружите, что оптимизация производительности постепенно отделяется от простой функции внешнего интерфейса.
планирование
Планирование не настолько подробное, чтобы упомянуть несколько моментов:
- Схема синхронизации SSR. Мы только что говорили об асинхронном способе возврата HTML в интерфейсе, асинхронной схеме. Синхронное решение — это способ основного документа.Асинхронное решение определенно эффективно в терминале, потому что оно напрямую получает HTML-код после автономного пакета через параллельный запрос предварительной выборки данных и напрямую отображает его на экране, так что он конечно хорошо работает. Но вне терминала у нас будет много.Например, в таких сценариях, как Alipay и Taobao, некоторые офлайн-пакеты и методы prefetch в терминале использовать нельзя, поэтому нам все равно нужно проводить некоторые методы возврата основного документа напрямую ;
- Абтест страницы;
- На стороне клиента рассмотрите способ переключения нескольких вкладок с помощью доступа к NativeTab;
- Некоторые оптимизации производительности в случае вызова терминала, так много новых точек оптимизации, определенно нуждаются в унифицированном управлении состоянием.
Таким образом, ряд улучшений внутренней прочности, и наша цель со стороны Флигги - достичь 90% двухсекундного соответствия на передней части. Поэтому для простого отдельного бизнеса, конечно, один бизнес в нашем терминале должен быть расширен до нескольких бизнесов. Наша идея состоит в том, чтобы иметь метод оптимизации, и теперь в группе у нас есть команда кросс-энд производительности и технический документ, такой метод, чтобы записывать некоторые методы оптимизации, медленно продвигать каждый бизнес, внедрять его и собирать часть бизнеса. хороший метод оптимизации для проведения осадков и обратной связи, а также постепенного улучшения общей производительности.
порекомендовать книгу
Последняя практика рекомендует книгу.Здесь рекомендуется «Принцип пирамиды», который описывает логику, аналогичную написанию PPT или размышлению о выражениях и решениях. Написание PPT, написание статей и т. д. — это набор логических, четких, целенаправленных, хорошо структурированных, простых для понимания мыслей, выражений и стандартизированных действий. Я думаю, что эта книга довольно хороша. После прочтения это очень полезно для создания PPT или написания статей. Кому интересно, может посмотреть.
Продвижение команды
Практика в последней практике, безусловно, необходимость набора людей. Наша команда занимается пользовательским интерфейсом и цифровым управлением Fliggy, а наш бизнес связан с путешествиями. Мы можем попробовать все. Основы нашей команды. Раньше в нашей команде был Nanlu, который также поделился таким решением, как Web Flutter, у нашей команды есть Flutter, поэтому теперь мы также делаем SSR на основе тренда Serverless. Есть также несколько микро-интерфейсов в середине и за кулисами, а также интегрированная разработка и взаимодействие с конечной линией, а также интеллектуальная конструкция, все технические идеи нашей команды включены. Так что в основном все включены во все аспекты, так что если вам интересно, вы можете ждать вас, вы можете передать письмо, чем больше P6 и P7, тем лучше.
Вы также можете обратить внимание на публичный аккаунт нашей технологии Fliggy, Fliggy F2E и Nuggets, Некоторые из моих статей были размещены на Nuggets ранее, и они также собраны нашей фронтенд-колонкой Fliggy. Если у вас есть идеи о производительности кросс-энда, вы также можете добавить меня в WeChat, чтобы узнать.
Следите за ранним чатом переднего плана, следите за новостями, чтобы узнать больше о BFF/GraphQL, пожалуйста, обратите внимание на 30-ю | специальную сессию BFF конференции раннего чата переднего плана — поиграйте с интерфейсами переднего и заднего плана (GraphQL, унифицированный шлюз, Доступ к API, управление API, преобразование протоколов, унифицированные аспекты безопасности, обработка с высокой степенью параллелизма, визуальная оркестровка, унифицированная конструкция стабильности...) 8-14 прямых трансляций в течение всего дня, 9 лекторов,Подписывайтесь, чтобы смотреть прямую трансляцию 👉 ):