предисловие

С момента рождения JavaScript фронтенд-технологии развивались очень быстро. Оптимизация мобильного белого экрана является важным направлением оптимизации внешнего интерфейса, и такие технологии, как SSR, CSR и предварительный рендеринг, родились в веб-интерфейсе. В интерфейсной технологической системе Meituan Payment оптимизация первого кадра веб-страницы улучшается за счет предварительного рендеринга, тем самым оптимизируя проблему белого экрана, улучшая взаимодействие с пользователем и формируя передовой опыт.

В области внешнего рендеринга в основном есть следующие методы на выбор:

	CSR	предварительный рендеринг	SSR	изоморфизм
преимущество	независимый от данных Самое быстрое время FP Пользовательский опыт клиента хороший совместное использование данных памяти	независимый от данных Время FCP быстрее, чем CSR Пользовательский опыт клиента хороший совместное использование данных памяти	SEO дружественный Высокая производительность выше сгиба, FMP быстрее, чем CSR и предварительный рендеринг	SEO дружественный Высокая производительность выше сгиба, FMP быстрее, чем CSR и предварительный рендеринг Пользовательский опыт клиента хороший совместное использование данных памяти Клиентский и серверный код являются общими, а эффективность разработки высока.
недостаток	Не подходит для SEO FCP и FMP медленные	Не подходит для SEO FMP медленный	Высокая стоимость обмена данными клиентов Стоимость обслуживания шаблона высока	Node легко создает узкое место в производительности

Для сравнения, изоморфная схема сочетает в себе преимущества CSR и SSR и может применяться к большинству бизнес-сценариев. Однако в гомогенной системной архитектуре средний уровень Node, соединяющий переднюю и заднюю части, находится в основном канале, и узкое место в доступности системы зависит от Node.Как только Node зависает, вся служба становится недоступной.

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

Так что же такое пререндеринг? Что такое FCP/FMP? Начнем с наиболее распространенных CSR.

Взяв в качестве примера Vue, общие формы CSR выглядят следующим образом:

Все кажется в порядке. Однако в качестве основной цели взаимодействия с пользователем мы обнаружили проблему взаимодействия:проблема с белым экраном.

Почему первый экран белый

Отрисовка в браузере включает в себя синтаксический анализ HTML, построение дерева DOM, построение CSSOM, синтаксический анализ JavaScript, компоновку, рисование и т. д., как показано на следующем рисунке:

Чтобы разобраться, почему появляется белый экран, необходимо на этой теоретической базе провести конкретный анализ реального проекта. Анализ через DevTools:

В ожидании возврата документа HTML он находится в состоянии белого экрана.
Отрисовка первого экрана выполняется после анализа HTML-документа, поскольку проект
Добавлен серый цвет фона, что дает серый экран.
Такие процессы, как загрузка файлов и парсинг JS, приводят к тому, что интерфейс долгое время находится в сером экране.
Когда смонтированный экземпляр Vue срабатывает, интерфейс отображает общий фрейм.
Конечный контент страницы может отображаться только после вызова API для получения бизнес-данных о времени.

Из этого можно сделать вывод, что из-за ожидания процесса загрузки файла, построения CSSOM, парсинга JS и т. д., а эти процессы занимают много времени, пользователь будет находиться в неинтерактивном состоянии первого экрана серого и белого экрана. в течение длительного времени, таким образом давая пользователю вид веб-страницы очень трудно "медленно" чувство. Тогда веб-страница слишком «медленная», как это отразится?

«медленный» эффект

Global Web Performance Matters for ecommerceВ отчете говорилось:

57% пользователей больше заботит, завершилась ли загрузка страницы в течение 3 секунд.
52% онлайн-пользователей считают, что скорость открытия страницы влияет на их лояльность к сайту.
Каждая 1 секунда замедляет PV страницы на 11% и удовлетворенность пользователей на 16%.
Почти половина мобильных пользователей сдаются, потому что они не открывали страницу в течение 10 секунд.

Наша команда в основном отвечает за бизнес, связанный с платежами Meituan.Если веб-сайт работает слишком медленно, это повлияет на процесс оплаты пользователем и вызовет жалобы клиентов или финансовые потери. Поскольку слишком "медленный" сайт может иметь такое значительное влияние, как его оптимизировать?

Идеи оптимизации

существуетUser-centric Performance MetricsТекст, были отнесены к четырем ключевым показателям рендеринга страницы:

Основываясь на этом обосновании, вернитесь к фактической производительности перед проектами:

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

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

Сравнивая различия DOM в трех периодах FP, FCP и FMP, обнаруживается, что различия заключаются в следующем:

FP: Существует только один корневой узел div.
FCP: содержит базовый фрейм страницы, но не содержит данных.
FMP: содержит все элементы и данные страницы.

Все еще взяв в качестве примера Vue, в его жизненном цикле смонтированный соответствует FCP, а обновленный соответствует FMP. Итак, какую HTML-структуру жизненного цикла следует использовать?

	mounted (FCP)	updated (FMP)
недостаток	Просто визуальный опыт опережает FCP, а фактическое время TTI не сильно меняется.	Данные должны быть получены при построении, а скорость компиляции низкая. Существует несоответствие между данными времени сборки и времени выполнения Страницы со сложными взаимодействиями все равно нужно подождать, фактическое время TTI не сильно меняется
преимущество	Не зависит от данных, скорость компиляции высокая	Хорошее впечатление от первого экрана Для страниц с чистым показом время FP и TTI почти одинаково.

Судя по приведенному выше сравнению, окончательный выбор — запускать предварительный рендеринг во время сборки при монтировании. Поскольку мы используем архитектуру CSR без Node в качестве промежуточного уровня, для достижения предварительного рендеринга содержимого DOM нам необходимо обновить и заменить исходный шаблон при сборке и компиляции проекта.

Пока что мы прояснили общую схему пререндеринга во время сборки.

Схема предварительного рендеринга во время сборки

Процесс предварительного рендеринга во время сборки:

конфиг читать

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

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

запуск сборки

Проект в основном использует TypeScript и использует TSдекоратор, мы инкапсулируем метод ловушки унифицированной конструкции предварительной отрисовки, чтобы запуск предварительной отрисовки во время сборки можно было выполнить всего одной строкой кода.

Декоратор:

использовать:

строить компилировать

Из блок-схемы необходимо запустить смоделированную среду браузера на издателе и получить текущее содержимое страницы через предварительно обработанный обработчик событий для создания окончательного HTML-файла.

Из-за наших ранних попыток предварительного рендеринга не былоHeadless Chrome,Puppeteer,Prerender SPA Pluginд., поэтому выбор осуществляется с помощьюphantomjs-prebuilt(Более ранние версии плагина Prerender SPA также были реализованы на основе готовых фантомов).

Текущий HTML можно получить через API, предоставляемый фантомом, например:

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

Оптимизация решения

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

Разберем упрощенный процесс запуска проекта:

Разработка -> Компиляция -> запуск

Предполагая, что файл JS в статическом файле на этот раз изменен, на этот файл будут ссылаться в HTML через CDN, тогда окончательный метод ссылки в документе HTML будет<script src="http://cdn.com/index.js"></script>. Однако, так как проект еще не запущен, файл нельзя получить по полному URL, а предрендеренная сборка стоит до онлайн-действия, поэтому возникает проблема:

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

Как сделать?

запросить угон

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

Предварительный рендеринг процесса НИОКР и эффектов во время сборки

Наконец, процесс разработки перед рендерингом во время сборки выглядит следующим образом:

стадия разработки:

Внедрите методы предварительного рендеринга, запускаемые сборкой, в одну строку с помощью декоратора TypeScript.
Измените файл конфигурации скомпилированной сборки перед публикацией.

Стадия выпуска:

Сначала выполните обычную сборку проекта.
Если есть конфигурация, связанная с предварительным рендерингом, запустите сборку предварительного рендеринга.
Окончательный файл получается в результате предварительного рендеринга, а выпуск и онлайн-действие завершены.

Полный путь запроса пользователя выглядит следующим образом:

Благодаря использованию предварительного рендеринга во время сборки в проекте время FCP было сокращено на 75% по сравнению с предыдущим.

об авторе

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

Предложения о работе

Наша большая команда по исследованиям и разработкам на платформе финансовых услуг Meituan быстро растет. Мы приглашаем к сотрудничеству более выдающихся веб-инженеров по исследованиям и разработкам. Заинтересованные друзья могут отправлять свои резюме на почтовый ящик: shanghanyang@meituan.com.