Как стать автором
Обновить

Комментарии 11

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

По поводу производительности, было дело, наобещал заказчику, что будет 98 баллов, открываем, измеряем и тут оказывается, что оно в районе 73 и в желтой зоне.

Тут-то я и узнал, что производительность не нормализуется и измеряется в браузере на конкретном железе и если у тебя 98 баллов, это не значит, что у всех 98 баллов.

Пример сайта цифровой библиотеки на Nuxt.js 2 на двух разных ПК.

Соответственно, надо не только мерить Lighthouse, но и смотреть на измеренные показатели по пользователям конкретного сервиса.

Мой вывод - если нужно гнаться за sео, то NextJS (React) не выбор

И вот почему я считаю что это не случайностью

То есть Вы по одному единственному параметру решили судить о применимости фреймворков в контексте оптимизации производительности для SEO? Какое-то более глубокое сравнение пытались делать? Например, искать корреляцию между количеством скриптов и DOM нод на страницах с использованием разных фреймворков?

В какой-то момент нужны будут .webp, поэтому, на момент написания статьи, обязательно использование next-images

Зачем? Достаточно перед загрузкой страницы проверить поддержку avif и webp в браузере через base64 fetch и передать расширение изображения в пропах. Это к Вашему высказыванию:

битва за каждый кб. При 10кб уже стоит задуматься

Еще про апи - использовать шифрование и сжатие. Для koa это koa-compress. Для Nest.js используется compression.

На этом моменте я совершенно запутался. Какое отношение это имеет к SEO и уж тем более какое отношение статья о NextJS имеет к NestJS? В ссылке на документацию к Nest которой вы поделились чёрным по белому написано:

For high-traffic websites in production, it is strongly recommended to offload compression from the application server - typically in a reverse proxy (e.g., Nginx)

С учётом того, что свой бэкенд с вероятностью 90% Вы будете хостить на PaaS, у которого есть свой собственный load balancer, он же reverse proxy, - то о сжатии будет беспокоиться именно он и в таком случае сжатие с однопоточного JavaScript движка лучше вообще снять, иначе можете сделать только хуже.

В конце-концов, готов оспорить самый главный тезис, озвученный Вами в этой статье. NextJS - это один из лучших, если не лучший инструмент для разработки UI с упором на оптимизацию. В подтверждение своих слов демонстрирую Вам скриншот аудита одного из наших NextJS проектов, где на мобильном устройстве оценка достигает 75-77/100 (https://imgur.com/a/20kkHTp), а на десктопе и вовсе 100/100 вышло (https://imgur.com/a/EN7TxOa). Аудит проводили на одной из самых "тяжёлых" страниц с множеством интерактивных компонентов, которая и близко не готова к продакшену - её только пару дней назад закончили "натягивать" с верстки на фреймворк, и ни о какой оптимизации тут и речи не идёт. Тем не менее. Также советую не тратить своё время на попытки добиться 90+ оценки для мобильных устройств, если Вы поставили себе цель гнаться за этим. В этом нет никакого смысла и добиться этого крайне трудно на сайте с интерактивными элементами. В какой-то момент Вы просто заметите, что тратите время на различные "хаки" и анти-паттерн приёмы, которые в дальнейшем будет тяжело поддерживать. Оно того не стоит.

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

Про главный тезис - Мне нравится Next, поэтому я пытался разобраться как на нем оптимизировать. Сори, забыл прикрепить скрины, что я сам добился 90/100 на мобилке, моя ошибка из-за который немного неправильный свет у статьи. В пример я приводил VueJS (и соотвственно NuxtJS), на котором знакомые разрабы писали сайт и у них мобилка вышла 100/100 стабильно. Я не пытался кого-то отговорить писать на Next, а лишь рассмотреть что самое важно для сайта. Перечитаю и возможно чутка перефразирую и дополнью, спасибо за комментарий.

Отдельные замечания рассмотрю внимательнее позже и попробую сам, спасибо.

Не отрицаю что я мог что-то упустить, как никак я лишь начинал вникать в тему сео и всей этой оптимизации. Просто я не находил статей с качественным контентом (была либо шиза, либо ничего полезнее банальных "уменьшите js код"). Думаю хорошая идея была бы еще прикрепить что сам находил.

Вижу я совершил несколько ошибок, на то и первая статья :) Спасибо за отзыв

Можно попробовать использовать preact вместо react. Не знаю как с SEO, но производительность страниц значительно увеличивается, а размер бандла уменьшается. Жаль не все реакт библиотеки переваривают preact/compat

Не слышал о нем, рассмотрю как вариант, спасибо

Для статей используйте, пожалуйста, универсальный инструмент, который не зависит от вкусов вашей машинки - https://pagespeed.web.dev/
Сравнил vuestorefront и vercel - в среднем в обоих случаях 72 балла на мобилке, на десктопе у vercel 95 баллов.
copilot.github.com - ужасный костыль (при всём уважении), грузящий и на десктопе и в мобильной версии картинки png в оригинальном качестве и выполняющий кучу логику на клиенте. В общем-то как и все остальные примеры, по содержимому можно устраивать конкурс на худшую реализацию.
---
Вообще, реальная проблема next - то, что они модерируют примеры не по качеству, а по имени. Увы. (если кому интересно, то речь о странице https://nextjs.org/showcase)
---
К счастью, на конфе с последнего релиза показали две действительно классные (в плане производительности) реализации - Pagespeed insights monogram.io - под 100 баллов на мобильных устройствах и macstadium.com - сейчас ~80, но раньше было также быстро (и по графику реальных пользователей видно, что 99% зеленые).

monogram.io, за 10 проверок выпадало от 82 до 99 баллов на мобильных устройствах
monogram.io, за 10 проверок выпадало от 82 до 99 баллов на мобильных устройствах
macstadium.com среди реальных пользователей
macstadium.com среди реальных пользователей

Да, для прода используем как раз гугловый инструмент, но когда дело доходить до оптимизации и локальной разработки, то, чтобы понять имеют ли смысл изменения, как раз придумали пакеты. Да, их результаты зависят от железа, но сравнивал сайт с хорошей оптимизацией и свой на одной и той же машине с маленьким промежутком, тоесть среда примерно одинаковая. Опять же, цель была понять какие дейсвтия влияют на сео.

За дополнительный материал для чтения спасибо, почитаю

Я конечно понимаю, что web vitals с недавних пор участвуют при приоретизации сайтов в поисковой выдаче, но всё же это только в гугле. Когда я захожу на статью про SEO оптимизацию я ожидаю немного почитать про SEO. Здесь ни о чём кроме производительности речь не идёт.

Ожидалось про семантику, про то, как метатеги добавляются - где их можно добавить, как они потом мерджатся (при добавлении из разных мест); как работает Link от некста и зачем им своя реализация и почему везде нужно использовать её; почему они рекомендует пре-рендеринг, а не какой-нибудь серверный рендеринг и зачем сделали инкрементальный рендеринг в альтернативу серверному для сайтов с большим количеством страниц.

В общем хоть про что-нибудь помимо производительности или не брать в название столь обширную тему, думаю про производительность читало бы не меньше людей, чем про SEO

Благодарю за отзыв. Неопытность в написание статей проявилась, обязательно учту в будущем.

для любого сайта только на английском спокойно хватает latin
Тут надо очень осторожно. Если буква не использована прямо сейчас — это не значит что она не понадобится чуть позднее.
Реальный случай из практики: сайт на английском, шрифты порезали до latin — и вскоре пришло замечание, что чехи/словаки/етц не могут корректно написать свои фамилии. Latin в целом покрывает диакритику Западной Европы, но не Восточную.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории