Как мы уменьшили размер JS при начальной загрузке - Разделение кода с помощью Webpack
Мы создали фрагменты javascript с помощью webpack, который позволяет нам запрашивать js по запросу с помощью WebpackJsonP.
Следующий скрипт демонстрирует, как веб-пакет динамически загружает JS (здесь при нажатии кнопки на высоком уровне).
<a href='linkhref.html' id='mylink'>click me</a>
<script type="text/javascript">
function foo(data)
{
// do stuff with data
}
var myLink = document.getElementById('mylink');
myLink.onclick = function(){
var script = document.createElement("script");
script.type = "text/javascript";
script.src = "Public/Scripts/filename.js?callback=foo";
document.getElementsByTagName("head")[0].appendChild(script);
return false;
}
</script>
Мы также загружаем только критически важный CSS при загрузке страницы, а CSS загружается ниже, когда это необходимо.
Как мы сократили время первой осмысленной отрисовки - Изоморфный JavaScript:
Наши наиболее посещаемые страницы отображаются с использованием изоморфного JavaScript (один и тот же код JS работает как на стороне сервера, так и на стороне клиента с использованием Server-Side React). Мы визуализируем страницу на бэкэнде и отправляем обработанные страницы обратно клиенту. Даже если javaScript отключен, пользователь все равно может видеть полностью обработанные страницы.
Мы также кэшируем сгенерированные страницы в серверной части, чтобы мы могли мгновенно обслуживать эти страницы для следующего вызова. Все пользователи получают одну и ту же страницу с сервера. Мы повторно визуализируем страницу на клиенте, чтобы настроить эту страницу для каждого клиента, а виртуальная модель DOM React позволяет быстро перерисовать эту страницу.
Как мы сделали его масштабируемым - a. AWS Auto Scaling Infra
У нас включено автоматическое масштабирование, которое помогает поддерживать доступность приложений и увеличивать количество экземпляров серверов во время пиков спроса, чтобы поддерживать производительность и уменьшать емкость во время перерывов в работе, чтобы сократить расходы.
Как мы сделали его масштабируемым - б. Кластеризация узлов
Мы используем кластеризацию узлов для обработки нескольких запросов с одним потоком узла на ядро процессора в соответствии с методом циклического планирования.
Как мы исправили проблемы, связанные с изображениями - Image Manager
Мы используем Akamai Image Manager для предоставления изображений клиенту. В зависимости от характеристик устройства менеджер изображений обслуживает оптимизированные форматы изображений, такие как webp, jpeg и png.
Также мы рендерим изображения определенного размера и качества для различных компонентов.
- Для изображений высокого качества и размером 140 пикселей запросы параметризуются с помощью impolicy = hq, imwidth = 140.
2. То же самое для impolicy = hq, imwidth = 414.
Как мы сокращаем размер статических ресурсов - шрифт вместо Image Sprite
Для значков мы заметили, что использование настраиваемого шрифта поверх Image Sprite дает лучшую производительность. Вдобавок мы сжимали шрифты с помощью WOFF2, TTF, что делает размер даже меньше, чем у спрайтов.
Как мы сократили время приема-передачи - HTTP / 2
HTTP / 2 - это значительное усовершенствование исходного протокола HTTP 1.1. Новая функция протокола поддерживает мультиплексированные запросы через одно соединение. Это снижает сетевой трафик, а также двоичную природу протокола и
Включение HTTP / 2 в AWS Application Load Balancer
Как мы оптимизировали кеширование на стороне клиента - Service Worker
Чтобы сделать наш сайт прогрессивным, необходима интеграция сервис-воркера.
Service worker - это рабочий поток, выполняемый браузером в фоновом режиме, отдельно от веб-страницы. Он открывает двери к функциям, которым не нужны веб-страницы или взаимодействие с пользователем, таким как push-уведомления, фоновая синхронизация, геозоны, управление сетью и т. Д.
С точки зрения управления сетью, он действует как прокси-сервер, установленный на клиенте. Вы сами решаете, что делать, по запросу. Вы можете использовать это, чтобы ускорить работу в автономном режиме или создать новые функции.
Мы использовали это для кеширования - чтобы быстрее обслуживать ресурсы из кеша на стороне клиента или сделать их доступными, когда сеть не работает.
Используемые стратегии кеширования -
Все ресурсы не могут обслуживаться одной и той же стратегией кэширования. Например, наши HTML-страницы часто меняются, и, следовательно, записи в кеше устаревают. Нам необходимо часто обновлять этот контент. С другой стороны, изображения могут обслуживаться из кеша без необходимости длительного обновления.
Как вы уже догадались, нам нужны разные стратегии.
У этих стратегий, как у миньонов, есть название (у них были имена, верно ?!). И вы можете различить их, просто взглянув на них.
Кэширование всегда с резервным сетевым подключением
Это предпочтительно использовать для обслуживания статического содержимого, такого как все файлы js, css, font, image. Поскольку мы интегрировали номенклатуру на основе хешей для наших файлов js, css и шрифтов, мы можем легко сохранить их в кеше после первого запроса. Впоследствии, по каждому запросу клиента, они обслуживаются из кеша.
Сначала кеш, затем всегда сеть
Сначала поищите ресурс в кеше. Если обнаружено, обслуживать из кеша, а затем выполнять сетевой вызов в фоновом режиме для обновления кеша. При последующих запросах обновленный файл обслуживается из кеша. Мы реализовали эту стратегию для наших HTML-страниц.
Сеть всегда
Это стратегия по умолчанию. Все остальные запросы, кроме упомянутых выше файлов, всегда выполняются сетевые вызовы. Нам не нужно писать для них особый случай. Обычно в этой стратегии ответ не сохраняется.
Сбивает с толку? Маленький! Фарраго искажений? Поверните голову вправо, затем влево и повторите. Да, вы все правильно поняли. НЕТ!
Да, я выпендриваюсь!
Как только вы освоитесь, это будет довольно легко понять.
Как это нам помогло?
Использование сервис-воркера имело в основном два преимущества.
1. Прогрессивное веб-приложение
Поскольку файлы js и css кэшируются, это помогает нам обслуживать наши страницы, даже когда клиентская сеть не работает. Теперь пользователи могут просматривать наш сайт в автономном режиме. Добрый день!
Пользователи не могут выполнять какие-либо вызовы API, такие как добавление / обновление корзины или
купить акции и т. д., но они в любом случае могут просматривать наш каталог.
2. Экономит пропускную способность сети.
Обслуживание большинства избыточных файлов с помощью сервисных работников также помогает быстрее загружать наш сайт для последующих звонков. Поскольку мы не выполняем вызовы снова и снова. Это освобождает большую часть пропускной способности сети для других критических вызовов, которые могут быть обслужены мгновенно.
Как мы сделали WebApp похожим на нативное приложение - Manifest.json
Вот записи, которые нам нужно добавить в файл manifest.json, чтобы получить идеальную оценку Lighthouse.
1. имя
2.короткое_имя
3. значок
4. цвет фона
5. цвет_цвета
Это обязательные атрибуты. Мы также можем добавить другие параметры в соответствии с нашим требованием.
Обратите внимание, что background_color и theme_color влияют на внешний вид сайта. Поэтому мы обычно игнорируем эти ключи. Но мы включили их в белый цвет по умолчанию.
Помимо файла манифеста, в тег заголовка также необходимо добавить метатег с именем theme-color.
