Forwarded from MetaLamp | CIS
Кэширование в Next.js. Часть 1.
Всем привет! Cегодня я хочу затронуть тему кэширования в Next.js. Это будет серия постов, где в начале мы рассмотрим само кэширование и какие проблемы оно решает, а затем я расскажу, какие проблемы оно привнесло и как разработчики Next.js теперь пытаются решить эти проблемы. Поэтому подписывайтесь, чтобы не пропустить!
В прошлом году я собеседовал много фронтенд-разработчиков, и только пара из них смогли рассказать мне про то, как работает кэширование в Next.js. Надеюсь, вам будет полезно.
И так, в 13-й версии Next.js, вместе с App Router, нам представили новый механизм кэширования, который вызвал неоднозначную реакцию у пользователей и получил долю заслуженного, на мой взгляд, хейта. В Next.js теперь есть 4 уровня кэша и мы рассмотрим каждый из них. Сразу скажу, что я не буду давать полное и исчерпывающее описание, а только саму суть. Более подробно вы всегда можете почитать в документации. Приступим:
1) Request Memoization. Простой механизм, который кэширует все запросы, выполненные функцией
В противном случае, нам бы пришлось запрашивать данные где-то на верхнем уровне, а затем прокидывать их через пропсы, как это было в Pages Router с функцией
2) Full Route Cache, он же SSG, он же Static Rendering. Кэширование всего раута во время билда проекта. Другими словами, Next.js сгенерирует готовый html файл вашей страницы во время билда и будет мгновенно отдавать его по запросу за этой страницей. Next.js по умолчанию пытается применить это кэширование ко всем раутам, но отключит его, если встретит на странице использование чего либо из Dynamic API (headers, cookies, searchParam проп), либо если вы отключите его самостоятельно. В таком случае Next.js переключит ваш раут на Dynamic Rendering. При необходимости кэш можно ревалидировать раз в определённый промежуток времени или по требованию. Это называется ISR - Incremental Static Regeneration.
Проще говоря, Next.js пересоберёт вашу страницу в фоне, что бы сгенерировать свежий html файл, без необходимости пересобирать весь проект. Full Route Cache является серьёзной оптимизацией для вашего сайта, поскольку позволяет пропустить этапы запроса данных на сервере и рендера страницы на сервере, сразу отдавая готовый html файл, который был получен во время билда. Это существенно увеличивает показатели производительности и я неоднократно использовал Full Route Cache на наших проектах. Справедливости ради, с ним есть одна проблема, которую призван решить Partial Prerendering (PPR) в будущем. Но об этом я писал отдельный пост.
Мы рассмотрели 2 вида кэша из 4х, и пока я не сказал ничего плохого о них. Наоборот, отметил положительные стороны и действительно считаю их полезными фичами в Next.js. Так что же не так с кэшированием в Next.js и почему разработчики Next.js пытаются изменить подход к нему? Узнаем в следующих частях.
#миша_якубчук #кэширование_nextjs
Всем привет! Cегодня я хочу затронуть тему кэширования в Next.js. Это будет серия постов, где в начале мы рассмотрим само кэширование и какие проблемы оно решает, а затем я расскажу, какие проблемы оно привнесло и как разработчики Next.js теперь пытаются решить эти проблемы. Поэтому подписывайтесь, чтобы не пропустить!
В прошлом году я собеседовал много фронтенд-разработчиков, и только пара из них смогли рассказать мне про то, как работает кэширование в Next.js. Надеюсь, вам будет полезно.
И так, в 13-й версии Next.js, вместе с App Router, нам представили новый механизм кэширования, который вызвал неоднозначную реакцию у пользователей и получил долю заслуженного, на мой взгляд, хейта. В Next.js теперь есть 4 уровня кэша и мы рассмотрим каждый из них. Сразу скажу, что я не буду давать полное и исчерпывающее описание, а только саму суть. Более подробно вы всегда можете почитать в документации. Приступим:
1) Request Memoization. Простой механизм, который кэширует все запросы, выполненные функцией
fetch, на этапе рендеринга вашей страницы на сервере. Другими словами, если на вашей странице в разных серверных компонентах отправляется один и тот же запрос, то такой запрос отправится только один раз, а полученные данные расшарятся между компонентами. Это позволяет не беспокоиться о том, что один и тот же запрос выполнится несколько раз. В противном случае, нам бы пришлось запрашивать данные где-то на верхнем уровне, а затем прокидывать их через пропсы, как это было в Pages Router с функцией
getServerSideProps. Такой кэш существует только в момент запроса за страницей, а затем удаляется. Отключить его нельзя, да и не зачем, он не несёт никакого вреда и делает разработку более удобной, позволяя запрашивать данные там, где они нужны, не переживая о дублировании запросов. Что отлично ложится в дизайн серверных компонентов. Работает на основе функции cache из React.2) Full Route Cache, он же SSG, он же Static Rendering. Кэширование всего раута во время билда проекта. Другими словами, Next.js сгенерирует готовый html файл вашей страницы во время билда и будет мгновенно отдавать его по запросу за этой страницей. Next.js по умолчанию пытается применить это кэширование ко всем раутам, но отключит его, если встретит на странице использование чего либо из Dynamic API (headers, cookies, searchParam проп), либо если вы отключите его самостоятельно. В таком случае Next.js переключит ваш раут на Dynamic Rendering. При необходимости кэш можно ревалидировать раз в определённый промежуток времени или по требованию. Это называется ISR - Incremental Static Regeneration.
Проще говоря, Next.js пересоберёт вашу страницу в фоне, что бы сгенерировать свежий html файл, без необходимости пересобирать весь проект. Full Route Cache является серьёзной оптимизацией для вашего сайта, поскольку позволяет пропустить этапы запроса данных на сервере и рендера страницы на сервере, сразу отдавая готовый html файл, который был получен во время билда. Это существенно увеличивает показатели производительности и я неоднократно использовал Full Route Cache на наших проектах. Справедливости ради, с ним есть одна проблема, которую призван решить Partial Prerendering (PPR) в будущем. Но об этом я писал отдельный пост.
Мы рассмотрели 2 вида кэша из 4х, и пока я не сказал ничего плохого о них. Наоборот, отметил положительные стороны и действительно считаю их полезными фичами в Next.js. Так что же не так с кэшированием в Next.js и почему разработчики Next.js пытаются изменить подход к нему? Узнаем в следующих частях.
#миша_якубчук #кэширование_nextjs
Forwarded from MetaLamp | CIS
Кэширование в Next.js. Часть 2.
Привет, в предыдущем посте я решил рассказать вам о кэшировании в Next.js, об его особенностях и проблемах. Мы рассмотрели Request Memoization и Full Route Cache, а сегодня поговорим об оставшихся двух уровнях кэша.
3) Router Cache. Это единственный вид кэша, который работает на клиенте, а не на сервере. Router Cache работает во время того, как пользователь переключается между страницами. Он кэширует в памяти браузера ваши layouts, loading states, а так же префетчит страницы, на которые пользователь может потенциально перейти (отслеживает компоненты
Так же Router Cache реализует свой собственный back-forward cache (BFC), который имитирует поведение браузерного BFC, но работает с маршрутизатором Next.js. При необходимости вы так же можете включить кэширование ваших pages, что позволит мгновенно возвращаться на уже посещённые пользователем страницы.
И вот тут мы сталкиваемся с первой ложкой дёгтя, которую подсунули нам разработчики Next.js, ведь до 15-й версии кэширование pages в Router Cache по умолчанию было включено, а до версии 14.2 его вообще никак нельзя было отключить. То есть, возвращаясь на одну из уже посещённых страниц, пользователь всегда увидит устаревшие, закэшированные данные. Что, мягко говоря, подходит не всем. К счастью, как я и сказал, с версии 14.2 мы можем отключить это поведение, а с версии 15, оно отключено по умолчанию.
4) Data Cache. Пожалуй основной уровень кэша, который кэширует все ваши данные между запросами. То есть, если вы запрашиваете данные для страницы в серверном компоненте, то при всех последующих рендерах, данные для этой страницы будут браться из кэша, что позволит быстрее отрендерить страницу и отдать её клиенту. Для этого необходимо использовать функцию
Казалось бы, какие могут быть проблемы с этим? А их оказалось сразу несколько:
🟠 До 15й версии у Data Cache были агрессивные настройки по умолчанию , где все fetch запросы навсегда кэшировались. По незнанию можно было обнаружить, что данные на странице никогда не обновляются и долго с этим разбираться. А когда разобрались, приходилось настраивать этот самый Data Cache на каждой странице или в каждом fetch запросе. К счастью, в 15й версии Data Cache по умолчанию выключен.
🟠 Если ваше приложение разворачивалось в нескольких экземплярах, между которыми происходила балансировка нагрузки, то у каждого экземпляра был свой собственный кэш, что приводило к несогласованности данных. Но если вы развернёте ваш сайт на серверах Vercel, то у вас всё будет работать как надо, от чего знатно подгорало у сообщества. Довольно долгое время эта проблема не решалась и только в версии 14.1 у нас появилась возможность написать собственный cacheHandler, а так же появились примеры со сторонними хранилищами, такими как Redis.
🟠 В конце концов появилось множество опций (revalidate, dynamic, fetchCache и опции функции fetch) по настройке этого самого кэша, разобраться в которых с первого раза было крайне сложно. А разбираться приходилось, как раз из-за агрессивных настроек по умолчанию, о которых я упомянул выше.
🟠 Но даже когда ты хотел осознанно воспользоваться преимуществами нового кэширования, то приходилось долго разбираться в этих настройках, что бы подобрать нужную комбинацию и найти правильное поведение.
Фух, как видите, в отличии от предыдущего раза, претензии к кэшированию есть и они серьёзные. Часть из них уже решены, а оставшуюся часть хотят решить в будущем. Каким образом? Расскажу в следующий раз.
#миша_якубчук #кэширование_nextjs
Привет, в предыдущем посте я решил рассказать вам о кэшировании в Next.js, об его особенностях и проблемах. Мы рассмотрели Request Memoization и Full Route Cache, а сегодня поговорим об оставшихся двух уровнях кэша.
3) Router Cache. Это единственный вид кэша, который работает на клиенте, а не на сервере. Router Cache работает во время того, как пользователь переключается между страницами. Он кэширует в памяти браузера ваши layouts, loading states, а так же префетчит страницы, на которые пользователь может потенциально перейти (отслеживает компоненты
Link в области видимости). Это позволяет сохранять состояние Реакта в layouts и делать переход между страницами практически мгновенным за счёт префетчинга. Так же Router Cache реализует свой собственный back-forward cache (BFC), который имитирует поведение браузерного BFC, но работает с маршрутизатором Next.js. При необходимости вы так же можете включить кэширование ваших pages, что позволит мгновенно возвращаться на уже посещённые пользователем страницы.
И вот тут мы сталкиваемся с первой ложкой дёгтя, которую подсунули нам разработчики Next.js, ведь до 15-й версии кэширование pages в Router Cache по умолчанию было включено, а до версии 14.2 его вообще никак нельзя было отключить. То есть, возвращаясь на одну из уже посещённых страниц, пользователь всегда увидит устаревшие, закэшированные данные. Что, мягко говоря, подходит не всем. К счастью, как я и сказал, с версии 14.2 мы можем отключить это поведение, а с версии 15, оно отключено по умолчанию.
4) Data Cache. Пожалуй основной уровень кэша, который кэширует все ваши данные между запросами. То есть, если вы запрашиваете данные для страницы в серверном компоненте, то при всех последующих рендерах, данные для этой страницы будут браться из кэша, что позволит быстрее отрендерить страницу и отдать её клиенту. Для этого необходимо использовать функцию
fetch или функцию unstable_cache, если вы запрашиваете данные используя API сторонней sdk или базы данных. Кэш так же можно ревалидировать.Казалось бы, какие могут быть проблемы с этим? А их оказалось сразу несколько:
Фух, как видите, в отличии от предыдущего раза, претензии к кэшированию есть и они серьёзные. Часть из них уже решены, а оставшуюся часть хотят решить в будущем. Каким образом? Расскажу в следующий раз.
#миша_якубчук #кэширование_nextjs
Please open Telegram to view this post
VIEW IN TELEGRAM