Безусловно. Это просто один из факторов, который я постепенно собирал и наконец решил опубликовать.
При этом да, не самый ключевой, даже для получения органики. У гугла этих факторов сотни, если не тысячи. В первую очередь соответствие запросу, качество контента, эффективность для пользователя. И если эти факторы слабые - вообще не важно насколько быстрый сайт, т.к. скорость в этом списке ниже.
Но если скорость критично низкая - теряете и первичные факторы. А если максимально высокая - выигрываете.
А в целом высокая производительность и максимальные web vitals - проблемы скорее развитых бизнесов, когда остальное уже отточено. Для стартапов закапываться в это не лучшая идея (но здесь много того, что можно сделать и за 5 секунд, поэтому "почему бы и да")
Если вы дочитали эту статью - ничего нового на Keynote конференции вы, к сожалению, не увидите. Статья по конференции выйдет, но в более вольном, чем ожидалось, формате!
На самом деле надеюсь, что дальше релизы нормализируются - будут пореже и более надёжные. Крупных изменений или планов на них пока не видел - возможно что-то с edge поменяют (который как по мне бесполезен) и думаю ещё interceptor/middleware переделают, потому что всё ещё не выглядят как решения под все случаи.
Апп роутер неплох, уже использую в коммерческих проектах и для ряда задач удалось хорошо ускорить сайт (парсинг строк в реакт, блоки со сложными условиями, выход тысяч элементов из клиентского бандла, ну и стриминг конечно же)
Если честно в один момент тоже так подумал, но потом попробовал сделать проект на remix и теперь меньше жалуюсь на странность архитектуры next.js 😅
А так всему виной пересмотр фронтенда - что развивается BFF, хотелки, сложность проектов. Сейчас часто проекты существуют не просто как клиентский интерфейс с красивыми анимациями.
Например тот же блог можно сделать с next.js с ревалидацией и он будет быстрым, удобным и в общем-то простом в реализации. Альтернативы это либо SSR, либо PHP 😬 Про потребности продуктологов и маркетологов писал ниже, и это тоже играет свою роль.
Так что чем больше возможностей next.js используется в проекте, тем сильнее понимаю к чему такая широта функционала.
Ну и next.js значительно сделан американцами, где сейчас взлетает идея быстро поднять SaaS и разбогатеть - next.js старается занять и этот рынок.
Ну и все остальные инструменты (тот-же remix) тоже сильно изменили свои API под серверные компоненты, просто next.js решил не расширять pages router, о дать вот такой путь для постепенного переезда.
Возможно не лучшее решение, но кто знает каково бы было обновляться если б серверные компоненты и действия завезли в Pages Router...
Ну pages роутер тоже работает без изменений и ещё пару лет продержится. Просто next.js в отличии от go - инструмент для продуктологов или маркетологов. А им всегда хочется больше.
И я на самом деле вижу здесь как, например, PPR может дать супер классные возможности для маркетинга.
Серверные компоненты уже дали много возможностей. Делаешь сложную логику, а фронт всё ещё быстрый, раньше нужно было прям сильно возиться с оптимизациями. Но это конечно же не про запросы в базы, а например распарсить html строку с CMS в реакт ДОМ.
Ещё до этого очень помогли мидлвары - а/б тесты, специфичные реврайты/редиректы, базовая валидация
Ну это просто я решил заморочиться в этот раз. А в целом они открыты в паблик и про важные изменения пишут в своём блоге, также проводят конференции по каждому релизу.
Плюс можно пойти в твиттер и там напрямую спрашивать и девролов, и разрабов, и создателя Vercel (проще когда они делают такие твиты, за последние пару недель натыкался на 5 таких)
Ну на React.js на самом деле влияния у них немного. У меня даже есть ощущения что команда реакта обиделась на команду некста за то что они все лавры за апдейт (серверные компоненты и действия) забрали, особо не упомянув реакт и сейчас специально отдаляется. О тех же серверных компонентах команда реакта говорила ещё лет 5 назад, тогда там в общем-то никого из Vercel не было.
В Vercel работает бесполезная часть функционала - middleware в edge среде (пользы крайне скудно), удалённое кэширование (в целом можно и свой кэш провайдер использовать и будет тоже самое, но вообще тоже не много пользы). Остальное уже сахар самого хостинга - сжатия, доп конфиги, енв переменки.
Используем в работе селф-хост, ни разу не было мысли что нужно вместо этого перейти на Vercel, хотя используем next в общем-то на полную.
В общем-то всё также - разнообразием возможностей. Remix, например, всё ещё плохо работает с серверными компонентами. Да и подход next.js в этом плане сильно лучше - композиция компонент (может быть вложенность клиентский > серверный > клиентский). Ну и PPR действительно многообещающий:
Часть контента (предсобранная во время сборки, статическая) будет стримится сразу, а для части смогут показываться лоадеры. Последняя будет параллельно рендерится на сервере и начнёт стримится как только будет полностью готова. Без PPR страница начнёт стримится клиенту только когда соберётся вся целиком (и если, например, есть серверный компонент с запросами на 5 секунд - сервер ничего не отдаст эти 5 секунд).
Если next.js действительно решит вопросы со стабильностью - то remix уже мало что сможет сказать в свою пользу. Но Remix обещал много перемен после релиза стабильного React.js v19, но тут уже я деталей не знаю. Так что продолжаем наблюдать!)
Официальный релиз впервые состоялся до конференции. Прежде статья о новой версии и сам релиз публиковались во время конференции, примерно через 10 минут после начала.
Это, конечно, изменило планы на эту статью. Но тем не менее я решил абсолютно никак её не менять. О самом релизе будет выпущена ещё одна статья - уже после конференции!
Прочитать официальный релиз можно в блоге next.js - Next.js 15
Профдеформация видимо... Слишком часто натыкаюсь на статьи формата "React VS Next, что лучше". Часто не понимают почему такое сравнение бред (уровня git VS github) и зачем вообще все эти нагромождения, вот и перестал воспринимать это по-умолчанию как сарказм и шутки 😬
Как они взаимодействуют с основным сервером? Версель как-то детектит, что в проекте есть использование edge рантаймов и начинает перенаправлять запросы туда вместо прямых запросов на сервер? Все запросы или не все? А сколько под проект выделить точек в своей network (и где) версель сам решает по метрикам проекта?
Тут вопросы про CDN в целом. Не стал особо затрагивать тему, так как хотел базовую статью про отличительные особенности именно для фронтендеров. Сам Vercel использует edge рантайм вообще для всех приложений и всех запросов. То есть вы подключили домен и Vercel сразу сказал, что этот домен лежит ещё и на этих вот точках по миру. В следующий раз, когда пользователь зайдёт на страницу - провайдер пойдёт спрашивать, а где этот домен лежит, ему в ответе прилетят доступные места и он выберет ближайшую и пойдёт на неё.
На этих точках всегда лежит логика кеширования, также, если в проекте есть реврайты, редиректы, middleware или сегменты в edge рантайме - после сборки он отправит это всё на edge сервера.
Дальше edge рантайм это обработает: проверит реврайты и редиректы -> проведёт через middleware -> посмотрит есть ли в кеше -> если сегмент в edge рантайме - выполнит его у себя, если нет - отправит запрос на оригинальный сервер (но про все эти порядки в Edge рантайме и внутренности Vercel нигде не пишет, но как вижу это именно так).
Если npm start запускает именно сервер, что (и как) запускает edge рантаймы?
Vercel после сборки просто отправляет новый код edge рантайма (они недавно, кстати, сделали его компиляцию в машинный код) на сервера и те просто начинают работать с этим кодом.
Так и не понял, в каком случае вот прям нужно перекладывать работу на Edge
Ну по этой части я писал - хорошо использовать когда можно сделать всю обработку внутри (Запрос будет Client -> Edge). Если же нужно ходить к основному серверу (допустим на БД которая подключена внутри проекта, или файлы читать по какой-то причине) - это будет не выгодно. То есть запрос всё равно будет Client -> Edge -> Server. А раз всё равно ходите на сервер - лучше сразу всю обработку сделать в нём - в нём есть весь кеш, БД лежит рядом, система рядом, да и в целом возможностей больше.
Именно. Это пререндер статики. Чтобы пользователь и роботы при обращении получили сразу готовый html. А уже после этого на клиенте загрузиться вся логика, пройдёт гидрация и соберётся реативное приложение.
Ну а edge может дать прирост во времени ответа сервера (и, как следствие, метрики FCP) - что будем ждать эту статику не 500мс, а 300мс. Учитывая что задержка сейчас часто дольше чем сама загрузка - в некоторых случаях может дать неплохой буст (но, конечно, много переменных).
Да, но как. Они рендерят статическую часть при сборке и оставляют слоты/ссылки на динамические компоненты. Или всё же пересобирают и статическую часть по запросу, но каким-то супер оптимизированным способом и то, что динамическое собирают полноценно. А общение между этими частями как, допустим если со статической части передать пропсом объект с ценами.
Поэтому ждём. Из-за этого например и авторы библиотек переводов аккуратно подходят к реализациям получения локали (переписывался в дискуссиях с автором next-intl в меру общей проблемы).
Да. Но в целом если цель те-же шрифты сохранить локально - можно повторить ту логику что делает google fonts - https://fonts.googleapis.com/css?family=Inter&subset=cyrillic, загрузить нужные сабсеты локально (https://fonts.gstatic.com/s/inter/v18/UcCO3FwrK3iLTeHuS_nVMrMxCp50SjIw2boKoduKmMEVuLyfAZthiI2B.woff2) и настроить на локальные пути.
Спасибо за вариант решения!
Конкретно у нас с этим ничего особенного - Next.js и его
next/font, в котором можно настраивать сабсеты - https://nextjs.org/docs/pages/building-your-application/optimizing/fonts#specifying-a-subset (по сути убираем только совсем уж лишнее).Это встроено в google fonts - можно добавить query-параметр (напр.
&subset=cyrillic) и всё будет работать https://developers.google.com/fonts/docs/getting_started#specifying_script_subsets.Более детально выбирать глифы нам пока не пригождалось, т.к. наполнения много + мультиязычность и убирать более точечно не видим смысла.
Но возможно среди читающих найдётся кто-то с более богатым опытом.
Безусловно. Это просто один из факторов, который я постепенно собирал и наконец решил опубликовать.
При этом да, не самый ключевой, даже для получения органики. У гугла этих факторов сотни, если не тысячи. В первую очередь соответствие запросу, качество контента, эффективность для пользователя. И если эти факторы слабые - вообще не важно насколько быстрый сайт, т.к. скорость в этом списке ниже.
Но если скорость критично низкая - теряете и первичные факторы. А если максимально высокая - выигрываете.
А в целом высокая производительность и максимальные web vitals - проблемы скорее развитых бизнесов, когда остальное уже отточено. Для стартапов закапываться в это не лучшая идея (но здесь много того, что можно сделать и за 5 секунд, поэтому "почему бы и да")
Если вы дочитали эту статью - ничего нового на Keynote конференции вы, к сожалению, не увидите. Статья по конференции выйдет, но в более вольном, чем ожидалось, формате!
Спасибо за комментарий!)
На самом деле надеюсь, что дальше релизы нормализируются - будут пореже и более надёжные. Крупных изменений или планов на них пока не видел - возможно что-то с edge поменяют (который как по мне бесполезен) и думаю ещё interceptor/middleware переделают, потому что всё ещё не выглядят как решения под все случаи.
Апп роутер неплох, уже использую в коммерческих проектах и для ряда задач удалось хорошо ускорить сайт (парсинг строк в реакт, блоки со сложными условиями, выход тысяч элементов из клиентского бандла, ну и стриминг конечно же)
Если честно в один момент тоже так подумал, но потом попробовал сделать проект на remix и теперь меньше жалуюсь на странность архитектуры next.js 😅
А так всему виной пересмотр фронтенда - что развивается BFF, хотелки, сложность проектов. Сейчас часто проекты существуют не просто как клиентский интерфейс с красивыми анимациями.
Например тот же блог можно сделать с next.js с ревалидацией и он будет быстрым, удобным и в общем-то простом в реализации. Альтернативы это либо SSR, либо PHP 😬 Про потребности продуктологов и маркетологов писал ниже, и это тоже играет свою роль.
Так что чем больше возможностей next.js используется в проекте, тем сильнее понимаю к чему такая широта функционала.
Ну и next.js значительно сделан американцами, где сейчас взлетает идея быстро поднять SaaS и разбогатеть - next.js старается занять и этот рынок.
Ну и все остальные инструменты (тот-же remix) тоже сильно изменили свои API под серверные компоненты, просто next.js решил не расширять pages router, о дать вот такой путь для постепенного переезда.
Возможно не лучшее решение, но кто знает каково бы было обновляться если б серверные компоненты и действия завезли в Pages Router...
Ну pages роутер тоже работает без изменений и ещё пару лет продержится. Просто next.js в отличии от go - инструмент для продуктологов или маркетологов. А им всегда хочется больше.
И я на самом деле вижу здесь как, например, PPR может дать супер классные возможности для маркетинга.
Серверные компоненты уже дали много возможностей. Делаешь сложную логику, а фронт всё ещё быстрый, раньше нужно было прям сильно возиться с оптимизациями. Но это конечно же не про запросы в базы, а например распарсить html строку с CMS в реакт ДОМ.
Ещё до этого очень помогли мидлвары - а/б тесты, специфичные реврайты/редиректы, базовая валидация
Ну это просто я решил заморочиться в этот раз. А в целом они открыты в паблик и про важные изменения пишут в своём блоге, также проводят конференции по каждому релизу.
Плюс можно пойти в твиттер и там напрямую спрашивать и девролов, и разрабов, и создателя Vercel (проще когда они делают такие твиты, за последние пару недель натыкался на 5 таких)
Ну на React.js на самом деле влияния у них немного. У меня даже есть ощущения что команда реакта обиделась на команду некста за то что они все лавры за апдейт (серверные компоненты и действия) забрали, особо не упомянув реакт и сейчас специально отдаляется. О тех же серверных компонентах команда реакта говорила ещё лет 5 назад, тогда там в общем-то никого из Vercel не было.
В Vercel работает бесполезная часть функционала - middleware в edge среде (пользы крайне скудно), удалённое кэширование (в целом можно и свой кэш провайдер использовать и будет тоже самое, но вообще тоже не много пользы). Остальное уже сахар самого хостинга - сжатия, доп конфиги, енв переменки.
Используем в работе селф-хост, ни разу не было мысли что нужно вместо этого перейти на Vercel, хотя используем next в общем-то на полную.
Спасибо за приятный комментарий!)
В общем-то всё также - разнообразием возможностей. Remix, например, всё ещё плохо работает с серверными компонентами. Да и подход next.js в этом плане сильно лучше - композиция компонент (может быть вложенность клиентский > серверный > клиентский). Ну и PPR действительно многообещающий:
Часть контента (предсобранная во время сборки, статическая) будет стримится сразу, а для части смогут показываться лоадеры. Последняя будет параллельно рендерится на сервере и начнёт стримится как только будет полностью готова. Без PPR страница начнёт стримится клиенту только когда соберётся вся целиком (и если, например, есть серверный компонент с запросами на 5 секунд - сервер ничего не отдаст эти 5 секунд).
Если next.js действительно решит вопросы со стабильностью - то remix уже мало что сможет сказать в свою пользу. Но Remix обещал много перемен после релиза стабильного React.js v19, но тут уже я деталей не знаю. Так что продолжаем наблюдать!)
Ещё одно организационное изменение:
Официальный релиз впервые состоялся до конференции. Прежде статья о новой версии и сам релиз публиковались во время конференции, примерно через 10 минут после начала.
Это, конечно, изменило планы на эту статью. Но тем не менее я решил абсолютно никак её не менять. О самом релизе будет выпущена ещё одна статья - уже после конференции!
Прочитать официальный релиз можно в блоге next.js - Next.js 15
Профдеформация видимо... Слишком часто натыкаюсь на статьи формата "React VS Next, что лучше". Часто не понимают почему такое сравнение бред (уровня git VS github) и зачем вообще все эти нагромождения, вот и перестал воспринимать это по-умолчанию как сарказм и шутки 😬
Спасибо за комментарий! Добавил эти моменты также в саму статью
Тут вопросы про CDN в целом. Не стал особо затрагивать тему, так как хотел базовую статью про отличительные особенности именно для фронтендеров.
Сам Vercel использует edge рантайм вообще для всех приложений и всех запросов. То есть вы подключили домен и Vercel сразу сказал, что этот домен лежит ещё и на этих вот точках по миру. В следующий раз, когда пользователь зайдёт на страницу - провайдер пойдёт спрашивать, а где этот домен лежит, ему в ответе прилетят доступные места и он выберет ближайшую и пойдёт на неё.
На этих точках всегда лежит логика кеширования, также, если в проекте есть реврайты, редиректы, middleware или сегменты в edge рантайме - после сборки он отправит это всё на edge сервера.
Дальше edge рантайм это обработает: проверит реврайты и редиректы -> проведёт через middleware -> посмотрит есть ли в кеше -> если сегмент в edge рантайме - выполнит его у себя, если нет - отправит запрос на оригинальный сервер (но про все эти порядки в Edge рантайме и внутренности Vercel нигде не пишет, но как вижу это именно так).
Vercel после сборки просто отправляет новый код edge рантайма (они недавно, кстати, сделали его компиляцию в машинный код) на сервера и те просто начинают работать с этим кодом.
Ну по этой части я писал - хорошо использовать когда можно сделать всю обработку внутри (Запрос будет Client -> Edge). Если же нужно ходить к основному серверу (допустим на БД которая подключена внутри проекта, или файлы читать по какой-то причине) - это будет не выгодно. То есть запрос всё равно будет Client -> Edge -> Server. А раз всё равно ходите на сервер - лучше сразу всю обработку сделать в нём - в нём есть весь кеш, БД лежит рядом, система рядом, да и в целом возможностей больше.
Надеюсь ответил на вопросы!
Именно. Это пререндер статики. Чтобы пользователь и роботы при обращении получили сразу готовый html. А уже после этого на клиенте загрузиться вся логика, пройдёт гидрация и соберётся реативное приложение.
Ну а edge может дать прирост во времени ответа сервера (и, как следствие, метрики FCP) - что будем ждать эту статику не 500мс, а 300мс. Учитывая что задержка сейчас часто дольше чем сама загрузка - в некоторых случаях может дать неплохой буст (но, конечно, много переменных).
Новость не заставила себя долго ждать ?
https://nextjs.org/blog/next-15-rc
Да, но как. Они рендерят статическую часть при сборке и оставляют слоты/ссылки на динамические компоненты. Или всё же пересобирают и статическую часть по запросу, но каким-то супер оптимизированным способом и то, что динамическое собирают полноценно. А общение между этими частями как, допустим если со статической части передать пропсом объект с ценами.
Поэтому ждём. Из-за этого например и авторы библиотек переводов аккуратно подходят к реализациям получения локали (переписывался в дискуссиях с автором next-intl в меру общей проблемы).
Надеюсь завтра на Vercel conf коснутся и некста, и PPR в целом как то, что сделает веб ещё быстрее и прочий маркетинг
Твиты разразоботчиков, PR-ы, подогревают тему скорых крупных изменений, ну и в целом время уже к релизу (4-ю минорку они делать не любят).
Честно признаюсь - не знаю. По видео пока вообще непонятно, как это технически будет работать (а по коду пока только мимопроходил)