Как повысить производительность сайта за счет самостоятельного размещения внешних скриптов?
В NEDigital мы постоянно работаем над улучшением ориентированных на пользователя показателей, таких как LCP (наибольшая отрисовка контента), FID (задержка первого ввода), TBT (общее время блокировки), SI (индекс скорости) и т. д. Как платформа электронной коммерции, одна из проблемы, с которыми мы сталкиваемся, — это загрузка внешних скриптов, влияющая на общее время загрузки веб-сайта. Из-за амбиций группы по продукту и бизнесу улучшить общее впечатление от покупок на веб-сайте за счет интеграции сценариев с внешними партнерами производительность веб-сайта сказывается.
Мы постоянно оцениваем эти сценарии, чтобы измерить их влияние, но одна из распространенных проблем, связанных с загрузкой любого внешнего сценария, заключается в том, что он требует установления соединения, которое вызывает несколько вещей, таких как поиск DNS (преобразование доменного имени в IP), новое соединение HTTP ( TCP Handshake) и SSL-рукопожатие с сервером поставщика. Еще одна плата за получение внешних сценариев заключается в том, что вы упускаете возможность обслуживать ресурс с мультиплексированием HTTP2, что является гораздо более эффективным способом взаимодействия браузера и сервера. На изображении, прикрепленном ниже, показано различное время, затрачиваемое на установление соединения с внешним доменом с помощью теста производительности, выполненного на webpagetest.
Время, затраченное на поиск DNS, составило 204 мс, начальное подключение — 352 мс, а согласование SSL — 260 мс. В общей сложности веб-браузеру требуется 816 мс для подключения к одному внешнему домену, прежде чем мы даже начнем получать скрипт. Если мы сможем разместить эти внешние сценарии в нашей CDN, мы сможем сэкономить разумное количество времени, затрачиваемого на подключение внешних доменов. Для этого мы можем загрузить внешний скрипт в корзину хранилища и начать обслуживать его из CDN. Но проблема с этим подходом заключается в том, что мы пропустим обновления, сделанные производителем.
Для решения этой проблемы нам нужен промежуточный сервис, который будет постоянно обновлять скрипт из внешнего домена. Наше первоначальное предложенное решение выглядело примерно так.
Для предложенного выше решения мы использовали лямбда-функцию AWS в качестве промежуточного сервиса, который будет перебирать список скриптов и подключаться к каждому внешнему домену для получения скрипта. Функция AWS Lambda загрузит их в корзину S3, после чего эта корзина была подключена к AWS CloudFront для размещения файлов через CDN.
Лямбда-скрипт
Скрипт хорошо работал на локальной машине, но после загрузки в лямбда он не работал должным образом, поскольку «запрос» — это пакет npm, а не часть NodeJS. Lamda не предоставляет нам возможность установки каких-либо узловых модулей. При дальнейшем изучении документов я заметил, что можно создать слой, который можно присоединить к лямбда-функции, которая может обслуживать любую необходимую нам зависимость. Исходя из этого, мы работали над версией 2 архитектуры.
Я создал слой с пакетом запросов и интегрировал его с лямбда-функцией. Используя этот уровень, теперь лямбда-функция может импортировать пакеты запросов и может перебирать массив путей к файлам, что позволяет загружать их в определенную папку внутри корзины S3.
Даже при таком подходе нам все равно нужно выполнять эту функцию вручную, что нереально. Изучив дополнительные параметры, я обнаружил, что мост событий лучше всего подходит для этой задачи. Мост событий будет вызывать лямбда-функцию на основе заданной частоты, для нашего варианта использования мы будем запускать лямбда-функцию ежечасно, обеспечивая регулярное обновление наших скриптов. При необходимости можно изменить частоту.
Наша окончательная архитектура выглядит так.
Краткое содержание
Улучшение производительности веб-сайта — это всегда непрерывный процесс, нужно искать области улучшения, на которых можно сосредоточиться. Одной из таких областей улучшения для нас было время, затрачиваемое клиентом на подключение к каждому домену, связанному с внешним скриптом. В этой статье мы работали над решением этой проблемы, разместив внешний скрипт в AWS Cloudfront через корзину AWS S3. Тем временем мы решили проблему синхронизации файлов с помощью функции FileSync Lambda. Эта лямбда-функция будет перебирать список скриптов из внешнего домена и загружать его в нашу корзину S3. Кроме того, мы используем мост событий для выполнения нашей лямбда-функции каждый час.
Надеюсь, эта статья предоставит вам четкий подход к размещению внешних скриптов в CDN.
Спасибо за чтение!
