Сегодня я как раз изучал результаты нашего поиска в Google, и мы тоже заметили значительное падение трафика из поисковой выдачи на наш экземпляр Discourse (discourse.julialang.org) после 4 мая (около 30%). Я не обратил на это внимания до сих пор, потому что Discourse составляет лишь около половины наших просмотров страниц, а остальная часть сайта увидела рост трафика благодаря этому обновлению, поэтому общий эффект был лишь слегка отрицательным. Однако картина становится очень явной при разделении трафика на Discourse и не-Discourse в рамках одного домена. Трафик медленно восстанавливается, но примерно с той же скоростью роста, что и остальной сайт. Есть ли что-то, что можно сделать по поводу проблемы LCP? Это кажется хорошим кандидатом на то, что наказывается Google (и я также вижу десятки тысяч жалоб на LCP в нашей консоли поиска). Метрики Google показывают около 3 секунд мобильного LCP для многих наших страниц Discourse, что кажется довольно высоким. Это, похоже, универсальная проблема Discourse. Например, если я запущу отчёт по этой самой теме, я получу 3,3 секунды для LCP. К сожалению, я не веб-разработчик, поэтому у меня нет никаких конкретных предложений, но надеюсь, что кто-то, кто знает об этом больше, сможет что-то предложить. Было бы очень здорово вернуть эти 30% трафика 
.
Вот наш график показов в поиске с недельным сглаживанием, разделённый на Discourse и остальную часть домена (которая, как я предполагаю, имеет тот же рейтинг доверия на уровне всего домена). Обновление мая заметно выделяется. Иронично, что в ту же неделю у остальной части сайта произошёл всплеск трафика, не связанный с этим обновлением, но я бы сказал, что общая картина — это заметное снижение показов для Discourse и в основном стабильные показатели (если не учитывать несвязанный всплеск трафика) для остальной части сайта.
Именно на это я жаловался уже несколько месяцев, но администраторы не воспринимают это всерьез @Keno
Мы также начали экспериментировать с Vue.js, чтобы размещать часть нашего контента через Nuxt и улучшить производительность предварительного рендеринга в Discourse. Мы видим результат: обновление было опубликовано менее месяца назад, и за последние 2–3 дня количество показов удвоилось, вернувшись к уровню, который был до майского обновления.
Не уверен, совпадение это или нет, но, возможно, это связано с LCP. Я продолжу мониторинг ещё несколько недель, прежде чем делать какие-либо выводы.
Прочитав эту запись блога, понимаю, что это… крайне общие советы. Их можно вкратце свести к фразе «имейте качественный контент». Я даже не уверен, что конкретно мы могли бы изменить в Discourse, основываясь на этой записи блога? 
Не уверен, что речь только о качестве контента; это может быть связано с высоким временем LCP, которое, как я полагаю, можно исправить в Ember. Но я действительно не уверен, всё ещё экспериментирую с другими решениями, чтобы посмотреть…
Думаю, вы слишком сильно зацикливаетесь на одном показателе. Вы уделяете ему больше внимания, чем Google.
Они опубликовали информацию о LCP 28 мая и заявили: «Мы предоставим уведомление за 6 месяцев до внедрения этих изменений». Такое уведомление ещё даже не было предоставлено на сегодняшний день.
Как я уже говорил, у меня нет доказательств, да я и не фокусируюсь на этом. Я всё ещё экспериментирую с другими вещами и наблюдаю всплеск показаний, вернувшихся к уровню, с которого начинали, начиная с вчерашнего дня. Буду следить за этим, чтобы увидеть, как всё будет развиваться в ближайшие недели.
Да, не знаю, виноват ли LCP вообще, но именно он бросается в глаза в Search Console, где у нас отмечено около 20 тысяч ошибок для страниц с большим LCP. Независимо от влияния на SEO, улучшение времени LCP кажется достойной целью. Конечно, остаётся вопрос, насколько метрики Google действительно отражают реальность, но если они это делают, то начальное время загрузки в 5 секунд — это довольно много, и наверняка есть способ сделать лучше. Особенно для случая, когда пользователь не авторизован и пришёл из Google, кажется, что отдача предсформированных страниц через CDN могла бы быть весьма полезной.
Сообщается о LCP (наиболее крупный видимый контент), но, думаю, проблема в FCP (первый видимый контент)… обратите внимание на идентичные значения времени
Первая загрузка в Discourse медленнее последующих, потому что загружается само приложение, а не только первая страница. Поэтому, на мой взгляд, сократить время первоначальной загрузки до уровня «хорошо» по стандартам Google (< 1 с для FCP) на мобильных устройствах — задача гораздо более сложная, чем кажется.
Я думаю, что вы слишком сильно фокусируетесь на «технических» жёстких факторах. То, о чём Google не сообщает, — это то, что они также измеряют «воспринимаемую» производительность веб-сайтов.
Discourse, возможно, обладает потенциалом для улучшения «воспринимаемой производительности», и это должно быть сделано.
https://thepathforward.io/web-performance-how-to-affect-perceived-performance/
Существует множество способов сделать это, например, предварительный рендеринг скелетона до полной загрузки приложения.
По сути, всё, что отображается до полной загрузки приложения, помогает улучшить воспринимаемую производительность. Даже просто отрисовка заголовка (без содержимого, только правильный цвет) и фона с индикатором загрузки страницы до того, как всё приложение станет доступным, поможет при первоначальном просмотре страницы. Любые элементы, которые загружаются поэтапно, чтобы пользователь понимал, что что-то происходит, даже на медленном устройстве.
Например, для Meta что-то вроде этого можно/нужно отрисовывать мгновенно (это можно сделать с помощью простого критического CSS) до того, как полное приложение станет доступным браузеру:
Существуют сотни статей об улучшении воспринимаемой производительности одиночных веб-приложений. Возможно, стоит обратить на это внимание команде @team?
Страницу «Загрузка» можно реализовать в компоненте темы, если вы хотите. Попробуйте это сделать и сообщите, заметили ли вы какие-либо изменения на вашем сайте?
Я не думаю, что желаемый результат возможен с помощью простого компонента темы. Для этого мне нужен критический блок встроенного CSS в заголовке, который размещается до любых других скриптов и мета-тегов CSS. Кроме того, тег <body> рендерится только после полной загрузки приложения. Я не вижу, как компонент темы может быть использован для достижения желаемого результата, например, чтобы иметь критический блок CSS в заголовке и как минимум некоторые <div>, отрендеренные в теле страницы до полной загрузки приложения.
Есть вот это решение, которое добавляет лоадер немного раньше…
У вас есть источник, подтверждающий, что воспринимаемая производительность влияет на ранжирование в поиске, или вы имеете в виду FCP/LCP? FCP и LCP — это конкретные метрики с техническими требованиями, несмотря на то что они основаны на восприятии. Также обратите внимание: FCP не входит в «основные веб-показатели» (Core Web Vitals) Google, а LCP — входит.
Немного подробнее из https://web.dev/lcp/:
Как указано в спецификации API Largest Contentful Paint, для расчёта Largest Contentful Paint учитываются следующие типы элементов:
- Элементы
<img>- Элементы
<image>внутри элемента<svg>- Элементы
<video>(используется poster-изображение)- Элементы с фоновым изображением, загруженным через функцию
url()(в отличие от CSS-градиента)- Блочные элементы, содержащие текстовые узлы или другие дочерние элементы текстового уровня.
Если страница удаляет элемент из DOM, этот элемент больше не учитывается. Аналогично, если изменяется связанный с элементом ресурс изображения (например, изменение
img.srcчерез JavaScript), то этот элемент перестает учитываться до загрузки нового изображения.
Эти требования немного усложняют задачу. Возможно, сработает элемент загрузки с большим изображением или текстом, если вместо удаления из DOM просто скрыть его другим способом? Приведённый выше спиннер скрывает себя через z-index, так что, возможно, это сработает… но самого спиннера недостаточно, так как он не является изображением или текстом (это чистый CSS).
Согласен, что какой-то лоадер был бы полезен пользователям на медленных соединениях, но для Google есть ряд специфических требований, и мы не знаем, решит ли это проблему, о которой писал автор темы (OP).
Это потребовало бы переписывания Discourse снизу вверх, так что не стоит на это рассчитывать.
Я посмотрел на этот компонент, но не думаю, что он сильно влияет на результат, так как загружается слишком поздно, то есть когда приложение уже почти полностью запущено. Google не раскрывает, что именно они учитывают и так далее. Помимо контента, они наверняка измеряют субъективный пользовательский опыт (UX), даже косвенно, например, по возврату пользователей в свою поисковую систему. Длительное (воспринимаемое) время загрузки приводит к более высокому показателю отказов при первом посещении. Кроме того, даже если это не на 200 % релевантно для SEO, согласно официальным заявлениям Google, это всё равно важно с точки зрения UX и трафика. Ведь пользователь уйдет, если воспринимаемая производительность при первой загрузке страницы будет недостаточно хорошей.
Я полностью это понимаю. И должен признаться, что пока ещё не до конца понимаю процесс рендеринга приложения.
Честно говоря, если вы хотите выиграть в этой метрике, переходите на статические предварительно сгенерированные сайты, вроде всей этой истории с Google AMP.
Потому что вы всегда проиграете сайтам со статическими страницами.
Разговариваете со мной? Нет-нет, я очень доволен Discourse 
И хороший UX — это не только скорость первой загрузки страницы. Возможно, вы теряете что-то при первоначальной загрузке, но после того как приложение загрузится, пользователи определённо остаются дольше и возвращаются чаще по сравнению со скучными статичными страницами. И я уверен, что Google тоже как-то учитывает это.
Кроме того, с момента перехода на Discourse ни один пользователь не жаловался на скорость. А наш трафик из поисковых систем растёт по сравнению с нашей супероптимизированной страницей на Drupal, которая обеспечивала мгновенную первую загрузку благодаря полному HTML-кэшированию через Fastly и критическому CSS.
@codinghorror Ребята, я провел несколько тестов на двух своих доменах.
Оба пострадали от обновления от 4 мая:
Кейс №1: Полная фокусировка на качестве контента (как многие советовали выше)
В первом случае я сосредоточился на улучшении контента, ключевых слов, удалении любых плохих ссылок, внутренней перелинковке, добавлении нового качественного контента с большим потенциалом и так далее.
Как вы видите выше, все усилия оказались напрасными. Несмотря на то, что новые статьи были хорошо проиндексированы, тонкий контент удален, а старые статьи улучшены, вы едва ли заметите какое-либо улучшение. Складывается впечатление, что Google индексирует сайт достаточно хорошо, чтобы получать небольшой трафик, но не больше!
Кейс №2: Переход на Vue+Nuxt (немного улучшена структура + LCP и скорость рендеринга)
На втором сайте я просто перенес некоторые страницы в наше собственное кастомное приложение на Vue+Nuxt, которое обслуживает тот же контент с минимальными или отсутствующими изменениями в структуре через API. Никаких других усилий по улучшению не предпринималось (хотя в данном случае перенос сообщества на отдельный домен .com и обслуживание контента на основном сайте скорее навредит, чем принесет пользу, что и произошло в течение небольшого периода времени).
Не уверен, какой вывод можно сделать из вышесказанного, но я продолжу тестировать и наблюдать. Конечно, этот внезапный скачок интересен. Кстати, я проверил показатели до и после мая, а также после недавнего скачка, и заметил, что во всех этих случаях многие статьи потеряли показы, но затем почти те же самые статьи внезапно вернули такое же количество показов. То есть проблема затронула не одну-две статьи или страницы, а что-то, что заставляет Google штрафовать весь сайт целиком, и этот штраф остается на всем сайте, несмотря на усилия, вложенные в улучшение качества контента.
Надеюсь, всё понятно. Не стесняйтесь задавать вопросы, если они возникнут.
Всего наилучшего!
Если я не ошибаюсь, Discourse пытается отдавать статическую версию своих страниц поисковым роботам, верно? Было бы возможно отдавать эту статическую версию всем пользователям, не вошедшим в систему? Эти штрафы за LCP указывают на то, что Google видит нестатическую версию нашего форума.
Мы уже несколько месяцев периодически разбираемся в этой проблеме, включая привлечение внешних консультантов, и все результаты указывают на то, что наш форум подвергается серьезным санкциям со стороны Google за нарушения LCP после обновления от 4 мая.