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

Начиная!! Во-первых, давайте предположим, что вы уже создали базовое приложение для реагирования. Чтобы создать его версию сборки, выполните следующую команду:

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.