Комментарии 22
А за cloaking разве не пессимизируют в выдаче?
Пессимизируют если контент отличается. Например, на сервере вы выдаете контент про здоровое питание, а скриптом подменяете на контент про что-то нелегальное. Когда контент одинаковый то роботы воспринимают его правильно. Кроме того у того же гугла пререндер недавно был рекомендуемым инструментом. И на личной практике он успешно справляется и сайты на пререндере находятся в топе по нужным ключевым словам.
статья пропаганда.
кроме этих двух видов можно использовать гибридный подход, когда некий минимум к странице добавляется на сервере а всё остальное уже на клиентской стороне.
как там ситуация с правильными ботам сейчас? они освоили сайты у которых контент подтягивается после загрузки страницы?
Статья про то как роботам увидеть весь контент. Вариант с минимальной частью на сервере ближе к клиентскому рендерингу. Гугл и яндекс научились рендерить такие сайты, но у гугла результат совсем плохой, у яндекса совсем недавно появилось поэтому статистики еще нет. Остальные роботы зависит от поддержки клиентского рендеринга.
Странно, что сср рассматривается как преимущество для ботов, а не клиентов.типа рендерить на клиенте разработчику ничего не стоит, все же на откуп клиенту отдано.выходит клиенту отгружают мегабайты яваскрипта и все это заставляют рендерить, а с учётом, что мобильный веб популярнее десктопного, рендерить большинство пользователей будет на телефоне часто с не самой лучше связью, но это связь и мощность устройства считается проблемой уже клиента, а не разработчика который типа использовал современный подход.
На клиентах он действительно не нужен, т.к. на клиенте в любом случае придётся рендерить чтобы оживить сайт. И получается что к времени клиентского рендеринга добавляется еще время серверного рендеринга и передачи серверной страницы на клиент. Т.е. клиент от этого только проигрывает как по объему трафика, так и по времени ожидания. Где то в англоязычных интернетах про это даже хорошая статья есть с цифрами и графиками. Да и на моих проектах я не могу получить 500 балов по ligthouse через SSR из-за лишнего трафика и времени, на клиентском рендеринге 500 балов получается элементарно.
Поэтому все фреймворки с SSR работают по следующему принципу. При обращению к первой странице происходит SSR, при последующих страницах работает исключительно клиентский рендеринг. А боты не умеют в переходы, поэтому они запрашивают следующую страницу.
А про трудности слабых устройств вы сильно преувеличили, даже бюджетного 10 летнего телефона хватит что бы без проблем отрендерить сайт на стороне клиента. Главное использовать легковесные библиотеки и фреймворки. Но основная проблема на таких устройствах не скорость рендеринга JS, а скорость обработки CSS. Слабые устройства заставляют тормозить сложные CSS.
рендерить чтобы оживить
давайте не будем далеко ходить, вот вам хабр. вот статья, что в ней надо оживить? я вполне могу прочитать ее с выключенным JS.
добавляется время серверного рендеринга
Что если сервер отвечает и так в районе 100-200ms тк мощности сервера несравнимо больше чем у среднестатистического телефона. Получается добавляется время клиентского рендера, ответ от сервера вам в любом случае предстоит подождать. Стоит ли оно того и нужно ли вообще поверх гидрировать сайт в интерактивный? Метрики Total Block Time и Time to Interactive вам о чем говорят, как вы оптимизируете их на проекте?
Главное использовать легковесные библиотеки и фреймворки.
Тогда vue, react, angular идут на помойку? они не легковесные
Легковесные это alpine.js его аналог petite-vue, оба работают на уже отрисванном DOM и проповедуют Progressive Enhancement который в свою очередь проповедует следующее тезисы:
Basic content should be accessible to all web browsers
Basic functionality should be accessible to all web browsers
Под all browsers понимаются не только современные браузеры, но в целом ВСЕ браузеры отображающие HTML, ваш поход не подразумевает доступность сайта для всех браузеров, только для хедлайнеров. Например читать SPA через eink читалку уже невозможно, хотя может такие пользователи вам просто не нужны? Я ни на что не претендую и нивкоем случае не принижаю вашу статью, просто хочется напомнить, что в 2023 сайты живут не только как SPA и SSR приложения, классический подход к сайтостроению никуда не ушел (популярность CMS Wordpress\Joomla тому подтверждение, а в фреймворках типа Symfony\Laravel можно использовать очень мощный Twig шаблонизатор, такой подход поныне актуален, хотелось бы чтобы и в статье об этом было хоть чуточку упоминаний.
Где вы вообще нашли функцию выключения JS в 2023 году? ))
Вы недооцениваете хабру. Если посмотреть профайлер инициализации хабры, то у нее скриптов не меньше чем в любом навороченном сайте. Карму вы не поднимете, комментарий не напишите, элементарно три точки под комментом работать не будут, я уж молчу про аналитику и рекламу. Если вам нужен текст без JS вы можете прочитать в другом формате, например RSS. Но нет, вы открыли не RSS, а JS и жалуетесь на то что здесь работает JS. Это был ваш выбор, а не чей то другой. Выбирали бы RSS было бы больше контента на RSS.
Вы почему то думаете 1 сервер обслуживает только 1 клиента. Но это не так. Один сервер обслуживает сотни и тысячи клиентов в секунду. Если взять бюджетный телефон, например Redmi 9 за 9 тысяч и новый Xeon за 200 тысяч, да, Xeon будет в 100 раз быстрее, но обслуживать будет 1000 клиентов. При таком раскладе на одного клиента придётся в 10 раз меньше ресурсов. Уже писал в статье что делал программу на клиентском рендеринге и она занимала всего 10% от 4 ядер, в то время как аналогичная программа с серверным рендерингом занимала 15 навороченных серверов. Которые еще и поддерживать надо. И метрики TBT и TTI у клиентского рендеринга лучше за счет отсутствия двойной работы по серверному и клиентскому рендерингу.
vue, react, angular - да, на помойку. Как минимум надо использовать preact, svelte, solidjs (на худой конец $mol ;) ).
alpine.js - выдает вам шаблон который все равно рендерится на клиентской стороне. Вы не сможете прочитать статьи выведенные в циклы в alpine.js пока их не обработает JS. Это все го лишь другой шаблонизатор. Кроме того по тестам перформанса он в разы медленее не только preact, но и react. Пруф по ссылке.
Да, я когда делаю софт делаю поддержку не всех браузеров, а только тех чья доля составляет более 0,5% на рынке. Понижать эту планку экономически не целесообразно, т.к. такая поддержка не то что никогда не окупится, но и принесет ущерб самым массовым клиентам. Если бы клиенты хотели бы видеть контент без JS они бы выбирали RSS, Markdown и другие статичные форматы. Но именно клиенты выбирают JS.
Ну и php мертв, очень странно легаси считать актуальным стеком.
Я не говорю в целом о выключении js в 2023году, я не против js, но форму комментария можно отправить без использования js вообще, вы же наверняка в курсе про нативный sudmit веб форм. Мой посыл про множество 'тонких клиентов' и их тенденции к развитию и отображению веба
Ну и php мертв, очень странно легаси считать актуальным стстекомн
Я пока не готов утверждать, что php мертв, как и сайты на symfony/laravel joomla/wp это мертвое Легаси в коде, попробуйте в телеграмм каналах сообществ сообщить людям о мертвом php
Почему форма именно на JS:
Обратите внимание, редактор комментариев это не просто текстовый элемент, а довольно таки сложный редактор со сложным функционалом. Без JS такое работать не будет.
Эта форма отправляет на бекенд не то что вы видите и не html. Эта форма отправляет на бекенд JSON. Это нужно для того чтобы потом можно было отобразить те же комментарии в нативном приложении.
Форма на submit вызовет мерцание страницы с потерей положения скрола + лишним трафиком на повторную загрузку статьи. Форма на JS красиво вставляет комментарий в список комментариев, без каких либо мерцаний и перезагрузок страниц. Если любому человеку предложить два варианта поведения, то он выберет форму без мерцания и потерей скрола.
Ходить по телеграмм каналам и теребить чувства верующих не в моих правилах. Но сами наверное понимаете что рендерить страницу на html и оживлять через jquery в 2023 может только совсем не адекватный человек. Куда проще взять Next.js и написать изоморфное приложение.
Интересно, с какого это времени PHP стал легаси, и уж тем более мертвым?
А про отключение JS, про то что хабр JS'ом много чего инициализирует и т.п. — работает более чем хорошо. Да, комменты не почитать, но главный контент читаем более чем.
Кстати про читалку.
Этот сайт выполнен как клиентский рендеринг и напичкан JS буквально в каждом элементе. При этом он отлично себя чувствует на читалке. Секрет в легковесных библиотеках и стейт менеджере.
Кроме того использован эффект одного TCP пакета. В нем расположен лоадер. За счет чего на читалке почти сразу отобразился лоадер и еще секунд 10 шла загрузка.
Потом попытался открыть сайт на SSR, долго отображался белый экран, я уж подумал даже что сайт лежит. Но в итоге тоже отрисовался. Все это время он парсил документ и гидрировал страницу.
Вы сами ответили на свой вопрос, 10 секунд загрузки и мысли что сайт лежит уже начали посещать . Но он в итоге прогрузился спустя 10+ сек переваривания яваскрипта, это фиаско, а не победа, это ужасный пользовательский опыт.
Вы как то не так прочитали, вариант с серверным рендерингом грузился дольше чем вариант с клиентским рендерингом и вызвал ощущение зависшего сайта.
Опять фиаско, может вам сервер получше арендовать? 10сек на одного клиента это треш, у нас даже самые большие выборки в бд на проекте с 12млн аудиторией не работают так медленно, как всего 1 ваш шаблонизатор. Впрочем с ваших слов у нас мертвый стек (микросервисы на симфони в кубер кластере) и фронт на vue ssr без всяких nuxt/next
Вы так и не поняли. Это не время отрабатывания сервера. Это время отрисовки устройства. Очень медленно парсится страница и рендерится CSS.
вариант с серверным рендерингом грузился дольше чем вариант с клиентским рендерингом и вызвал ощущение зависшего сайта.
Так сервер в итоге работал медленнее клиента или нет? Как вы измерили, что например именно формирование CSSOM на клиенте сожрало основное время загрузки? Но это вроде чисто клиентская история и CSSOM на сервере не генерируется, там просто стили инклудятся в разметку
Сервер всегда работал хорошо и мгновенно. Дело в устройстве. Например хабру оно 5 секунд грузит html и сразу его рисует, потом еще 5 секунд работают скрипты, только потом оно шевелится. Статичный сайт сразу показал лоадер, через 5 секунд начал рисовать, к 10 секунде закончил и сразу стал юзабельным. SSR с регидрацией 20 секунд рисовал белый экран, потом сразу высветилась картинка и сайт был юзабельным.
Пререндеринг или Серверный рендеринг?