Всем привет!! Итак, сегодня мы узнаем о кэшировании и о том, как оно помогает в обслуживании набора файлов, известного как производственная сборка вашего приложения для реагирования, которое более эффективно, чем ваше обычное приложение для реагирования, работает быстрее и имеет лучшую производительность.
Начиная!! Во-первых, давайте предположим, что вы уже создали базовое приложение для реагирования. Чтобы создать его версию сборки, выполните следующую команду:
npm run build
Это может занять некоторое время, в зависимости от размера вашего проекта. Как только это будет сделано, вы увидите только что созданную папку с именем «build».
Теперь внутри этой папки вы найдете папку с именем «static». А внутри статической папки вы найдете три папки: «css», «js» и «media» соответственно.
Теперь давайте зайдем в папку js.
В основном вы найдете эти типы файлов js.
Этот файл представляет собой код вашего приложения для реагирования, который включает ваши страницы, компоненты, App.js и т. д.
Этот файл включает в себя код поставщика, который имеет низкую вероятность изменения, например, модули узлов и т. д.
Как работает кэширование?
Amazon Web Services определяет кэширование следующим образом:
В вычислениях кеш – это уровень высокоскоростного хранилища данных, в котором хранится подмножество данных, обычно временных по своей природе, чтобы будущие запросы на эти данные обслуживались быстрее, чем это возможно при доступе к основному месту хранения данных. Кэширование позволяет эффективно повторно использовать ранее извлеченные или вычисленные данные.
Таким образом, кэширование — это не что иное, как хранение файлов, которые не часто меняются, в локальном хранилище, чтобы при необходимости нам нужно было запрашивать их с сервера и получать их из самого локального хранилища.
Наш проект React включает в себя node_modules и статический css, которые, как правило, остаются статичными и не меняются часто.
Как узнать, были ли изменены файлы, хранящиеся в кэш-памяти?
Каждый файл js в папке build/static имеет такое имя, которое включает HASH-код, значение которого зависит от содержимого файла.
Если содержимое любого файла в проекте будет изменено, тогда будет изменен HASH-код для файла. И, следовательно, кеш будет получать информацию об изменениях файла.
Заголовок управления кэшем
Мы можем назначить период времени, в течение которого файлы в кеше будут храниться безопасно, и кеш будет обновляться по истечении этого периода времени.
Мы даже можем установить заголовок cache-control на 1 год для статических файлов (ресурсов), потому что, если мы изменим содержимое файлов ресурсов, соответствующий хэш в файлах сборки будет изменен, что приведет к тому, что кэш-память загрузит свежий копия файлов активов.
Для других файлов мы можем установить для заголовка cache-control значение no-cache, что приведет к тому, что клиент всегда будет загружать новую копию соответствующего файла, например index.html и т. д.
Чем версия сборки отличается от других обычных систем?
Пока мы видели, как кэш улучшает процесс отдачи файлов при запуске проекта.
В других системах, где мы не используем HASH, а заголовок кеша установлен на 24 часа. А что, если разработчик вдруг обновит ассеты и развернет их.
Поскольку заголовок cache-control установлен на 24 часа, файлы кеша не будут обновляться до истечения этого периода времени. Поэтому пользователи не смогут просматривать свежий сайт.
Во-вторых, если некоторые пользователи удалят кеш своего браузера или сделают полное обновление веб-сайта, это приведет к тому, что браузер загрузит совершенно новый набор файлов, и, следовательно, пользователь будет посещать новый веб-сайт. Но те пользователи, у которых все еще есть те же файлы кеша, будут посещать тот же старый веб-сайт.
Следовательно, разные пользователи будут посещать разные версии веб-сайта.
Первоначально опубликовано на http://asquero.com.