Полностью согласен. Мои результаты быстрого поиска не были сутью дела и, конечно, не претендовали на роль авторитетного теста; и когда я их опубликовал, я тоже не делал таких заявлений. Я лишь задал вопрос, основываясь на результатах своего поиска. Мне следовало выйти из аккаунта перед поиском, потому что при выходе из системы я получаю те же «отсутствующие» результаты, ха-ха.
Единственный «осязаемый технический аргумент», который я действительно привёл, заключается в том, что Google публично заявил, что начнёт использовать LCP (и другие показатели веб-важности) с мая 2021 года.
Также я высказал деловой аргумент: Google не может делать подобные заявления и вводить людей в заблуждение. Для крупной публичной компании это было бы огромной ошибкой. Я полагаю, что они не совершают такой ошибки, и когда Google заявляет, что пока не использует LCP как сигнал ранжирования, у меня нет причин им не верить.
Если бы доброжелательные участники дискуссии, утверждающие, что LCP влияет на SEO, и уверенные в «своих выводах», призывающие Discourse внести структурные изменения в код на основе этих «выводов», имели доступ к коду для проверки — ведь проект с открытым исходным кодом позволяет каждому его изучить — то их «доказательства» после рецензирования могли бы быть убедительными.
Это вовсе не личное и не враждебное замечание, но на данный момент мы видели лишь несколько графиков и не видели кода, тогда как Google публично заявил, что пока даже не использует LCP как сигнал для SEO.
С точки зрения «технической справедливости» у нас фактически нет никаких «доказательств» того, что Google сейчас использует LCP как сигнал. Это лишь предположение, и нет кода для рецензирования, который мог бы его подтвердить.
Все здесь хотят знать, какие изменения необходимы для оптимизации SEO и увеличения доходов. Однако нам нужны осязаемые факты, код для проверки, который убедил бы нас в том, что Google действительно использует LCP как сигнал.
Google заявляет, что сейчас не использует LCP как сигнал и начнёт применять его как фактор SEO в мае 2021 года. Пока что у нас нет причин сомневаться в том, что Google публично заявил; и мы не видели никаких «рецензируемых твёрдых доказательств» обратного.
Так что, для всех тех, кто жаловался на май 2020 года, это было ничем по сравнению с тем, что, возможно, произойдёт в мае 2021 года? Я имею в виду, вы также говорите, что сообщества Discourse МОГУТ пострадать в результатах поиска в следующем году (мы уже увидим, что произойдёт).
Да, я полностью согласен с вами и со всеми здесь, кто обеспокоен LCP и тем эффектом, который окажут основные веб-показатели Google.
Кроме того, я высоко ценю всех, кто стремится найти ответы и решения этой надвигающейся проблемы.
Что касается краха SEO в мае 2020 года, то это произошло и у нас на серверах LAMP; следовательно, это отнюдь не проблема Discourse как таковая, и мы до сих пор не знаем точных шагов для исправления проблемы мая 2020 года, потому что если бы мы знали, что именно нужно исправить с высокой степенью уверенности, все мы могли бы это «исправить» и «настроить».
За эти годы мы все видели весьма странные результаты работы ИИ Google и то, как этот ИИ классифицирует контент и манипулирует результатами выдачи в поисковой системе.
Моя предыдущая мысль заключалась в том, что мне казалось необоснованным читать в этой теме призывы к команде Meta Discourse вносить очень существенные структурные изменения во всю их экосистему, основываясь на предположениях и догадках, а не на твёрдых фактах, подтверждённых проверяемым кодом.
Тем не менее, LCP в любом случае станет крайне важным показателем в одно мгновение.
Новое в том, что LCP фиксируется на Android-смартфонах пользователей. Android — самая медленная платформа, на которой мы работаем, и это влияет на нас непропорционально сильно.
То, что предложил @sam, также предполагало отдачу этого представления некоторым анонимным пользователям через плагин, но мы не собираемся делать это в ближайшее время.
Хорошо. Мне не хватает знаний о том, как это работает точно (но, похоже, первоначальная загрузка всё ещё требуется, и она могла бы быть быстрее. Отсюда и вся эта тема). Это обсуждение уже частично велось 14 октября выше. Сам Джефф предложил эту идею:
Почему бы не взять контент и не создать полностью предварительно сгенерированный статический сайт. Что-то максимально быстрое. И отправить это в поисковые системы вместо самого форума? Идея в том, что здесь важнее всего контент, а не опыт взаимодействия. И сосредоточиться на скорости доставки, поскольку, как кажется, именно это важно для поисковых систем.
Бесконечная прокрутка в последнее время не подвергалась критике, но вы создадите статические предварительно сгенерированные страницы без бесконечной прокрутки. И вы будете проектировать это как гоночный автомобиль: от каждого грамма веса, который не является строго необходимым, вы избавляетесь. Никакого гамбургер-меню, никакого логотипа, никаких аватаров авторов. Вы сосредотачиваетесь исключительно на контенте и скорости.
Это было бы похоже на хороший ресторан (=форум Discourse), где вы организуете drive-in с заказами на вынос. Та же отличная еда (=контент), но без всего опыта обслуживания. Вы делаете заказ у динамика при въезде (=ваш поиск в поисковой системе) и получаете еду, упакованную и брошенную в ваше окно. Вся идея в том, что важно именно то, что требуется, и важны только еда (=контент) и скорость доставки. Если людям понравится еда, возможно, они вернутся и насладятся полным опытом внутри.
Впоследствии каждый владелец (=администратор) сам решает: считаете ли вы, что drive-in вредит вашему бренду, и отказываетесь от этого, или идёте этим путём, чтобы привлечь больше людей, зная, что многие могут никогда не зайти внутрь поесть (многие уже не заходят, но это может стать ещё хуже. И, возможно, ваш ресторан будет казаться гораздо менее привлекательным в таком представлении). Но, возможно, тот известный сайт с рекомендациями ресторанов направит к вам больше людей (остается только проверить, насколько это эффективно).
Что потребуется, так это плагин или модуль для генерации этих статических страниц по мере добавления контента на форум (думаю, это не должно быть чрезмерно сложно). Вы просто добавите здесь и там ссылки на ваш реальный форум (настроенный на «не индексировать» для поисковых систем). Каждый администратор сам решит, использовать ли это решение или нет.
Если всё сказанное выше верно по сути, и эта проблема может усугубиться в будущем, то это кажется мне приемлемым решением. Или, возможно, я плохо понял. (Примечание: всё это будет ТОЛЬКО ДЛЯ ЧТЕНИЯ, разумеется)
Хорошо, но тогда я не понимаю: в таком случае никто не получает преимущества, верно? Почему это должно влиять на результаты поиска? Если сайты на Discourse работают так же хорошо (или так же плохо ), как и другие. Разве другие сайты тоже открываются на Android?
Android уступает средним показателям по производительности в однопоточном режиме, что влияет на ресурсоёмкие одностраничные приложения, такие как Discourse. Мы подробно разбираем эту тему в статье Состояние JavaScript на Android в 2015 году — … плачевное
Топовый iPhone в 10 раз быстрее последнего Pixel при рендеринге Discourse. Google не учитывает рендеринг на iPhone в метрике LCP, поскольку это невозможно из-за отсутствия настоящего Chrome в iOS.
Так что, возможно, действительно есть преимущество в том, чтобы генерировать сайт из «маленьких страниц» для отправки в поисковые системы. Не стоит ли это того? (может, и нет). Или администраторам нужно предлагать своим пользователям новые флагманские телефоны? В этом ли смысл всех этих объявлений о том, что вы выиграли новейший iPhone?
From quickly skimming this Обзор Crux | Chrome UX Report | Chrome for Developers it looks like Google gets the information from spying on users (with permission) so you’d have to persuade a lot of them to use your poor man’s Discourse
Кажется, вы путаете Ember и Ember CLI. Ember — это фреймворк, который мы уже используем (и используем уже более 8 лет). Ember CLI — это инструменты командной строки, к которым мы переходим вместо использования конвейера активов Rails. Я упоминаю об этом, потому что некоторые ваши утверждения (например, что версии до 3 требуют переписывания) неверны для Ember CLI, но могут быть верны для самого Ember.
Снова повторюсь: Ember CLI не занимается рендерингом. Этим занимается Ember, и иногда у него возникают проблемы с производительностью. Обратите внимание, это не специфично только для Ember — у всех современных фреймворков есть ловушки производительности, о которых нужно знать. За годы работы с Ember мы выявили два критических участка (заголовок и просмотр темы), требующие улучшения производительности, и перешли к подходу на основе виртуального DOM.
Возможно, нам не всегда придется это делать, в зависимости от того, как сложится ситуация с Glimmer и Ember Octane, но код сейчас довольно стабилен и работает быстро даже на старых мобильных устройствах.
Ember Octane был представлен в версии 3.15, и с тех пор вышло два LTS-релиза (3.16 и 3.21). Мы будем обновляться до него, но поэтапно. К счастью, команда Ember позволяет вам выбирать формат (даже на уровне отдельных файлов!), который вы хотите использовать.
Сказав всё это, стоит отметить, что в Ember есть много чего критиковать. Раньше, когда производительность была для Discourse более серьёзной проблемой, было обещано несколько релизов, которые в итоге навредили нам вместо того, чтобы помочь. Это было непросто. Нам приходилось очень внимательно следить за ним долгое время, чтобы удовлетворить наши потребности.
Сегодня он также имеет лишь долю популярности по сравнению с более новыми фреймворками, такими как React. Однако React не существовал 8 лет назад! Нашим единственным выбором были Angular, Ember и Knockout. Если вы считаете обновление Ember сложным, посмотрите, через что прошла Angular при переходе с версии 1 на 2 (не говоря уже о её побочных проектах с Dart!).
Обновление Ember на протяжении многих лет требовало огромных усилий, но хотя бы это было возможно! Ни один из других фреймворков не предлагал никакого пути обновления подобного рода.
Что касается переписывания на Vue/Next/React, я думаю, люди серьёзно недооценивают, сколько у нас кода, который работает отлично. Это была бы невообразимая по объёму работа.
Я обдумываю это, @justin и @awesomerobot, но сначала хотел бы услышать мнение Робина по конкретным деталям Ember CLI.
В основе всего этого лежит своего рода парадокс «Что произойдет, если непреодолимая сила столкнется с неподвижным объектом?» .. мы сознательно являемся JavaScript-приложением (или SPA), и это влечет за собой компромиссы, которые мы приняли в 2012/2013 годах, исходя из наших лучших предположений о том, как будет выглядеть будущее в 2022/2023 годах. Хотя я, разумеется, предвзят, скажу, что наше предсказание «ну, производительность браузеров на мобильных устройствах станет неотличимой от производительности браузеров на настольных компьютерах» оказалось точным.
Более того, даже лучше: большинство современных телефонов Apple быстрее ноутбуков и настольных компьютеров. Это я не предвидел!
Хотя мы продолжим улучшать то, что можем, в части скорости первоначальной загрузки — и скорости в целом — я считаю, что наша история здесь достойна похвалы. Во-первых, в 2015 году мы получили столько внимания, что Google внутренне внедрил ряд улучшений в V8, Chrome и Android, чтобы устранить слабую производительность чипов Qualcomm SoC, измеренную в JavaScript.
Нашей ахиллесовой пятой были .. чипы Qualcomm. К сожалению, Qualcomm пока не добился больших успехов в области производительности: «лучшее» по производительности Android-устройство находится примерно на уровне iPhone 7. Старым Android-устройствам требуется много времени, чтобы покинуть рынок, но модели 855 и 865 были достойными игроками, примерно соответствующими уровню iPhone 7:
Мне приходится прокручивать страницу ниже, чтобы найти устройство Apple, которое было бы таким же медленным, как самое быстрое Android-устройство, но если я это сделаю, ближайшим соответствием окажется iPhone X / iPhone 8 с результатом ~910 в Geekbench. К сожалению, 865, по причинам, которые я до конца не понимаю, немного уступает в веб-сценариях, поэтому мы всё ещё находимся на уровне производительности iPhone 7 в Speedometer:
Я бы хотел, чтобы мы жили в мире, где Android-устройства выпускались бы на различных чипах SoC от разных компаний, которые конкурировали бы за создание самых быстрых и мощных чипов.. С другой стороны, производительность iPhone 7 для Discourse достаточна, и я рад, что в конечном итоге все Android-устройства, даже старые, будут «как минимум такими же быстрыми, как iPhone 7». Также я держу кулачки за предстоящий Snapdragon 875; в ближайшие месяцы должно появиться больше деталей.
Согласно результатам Geekbench 5, видно, что Xiaomi Mi 11 работает на 5-нм чипе Snapdragon 875 (на что намекнул никто иной, как исполнительный директор Xiaomi Лу Вэйбин). Грядущий Xiaomi Mi 11 набрал 1 102 балла в тесте однопоточной производительности и 4 113 баллов в многопоточном тесте.
Если это правда, то это соответствует уровню A12, и, надеюсь, это отразится и в веб-сценариях!
В любом случае, в Discourse есть ключевое архитектурное решение быть JavaScript-приложением .. и мы полностью привержены этому пути на обозримое будущее.
Для тех, кто следит за своей статистикой, вот ещё одна дата для записи. Будет интересно посмотреть, что произойдёт в ближайшие недели в связи с последним основным обновлением Google за декабрь 2020 года.
Нельзя забывать о недавно анонсированных Mac на чипах Apple Silicon!
Из чистого любопытства, откуда взялось это внимание?
Чип A10 всё ещё держится на волоске.
На всякий случай я не жду чуда. Apple всегда была впереди.
Тем не менее, смартфоны на Android всё ещё пытаются догнать их. Это просто абсурдно. У Apple уже есть чип A14, и, вероятно, они сейчас работают над чипом A15 на следующий год.
Спасибо, что поделились. Вот несколько важных моментов из статьи, которые стоит выделить в этом обсуждении:
Что делать, если ваш сайт попал под обновление. Google ранее давал рекомендации о том, что следует учитывать, если вы столкнулись с негативным влиянием основного обновления. Конкретных действий для восстановления не существует, и, более того, падение позиций может не означать, что с вашими страницами что-то не так. Однако Google предоставил список вопросов, которые стоит задать, если ваш сайт пострадал от основного обновления. Google также отметил, что можно наблюдать некоторое восстановление между основными обновлениями, но самые значительные изменения проявятся после следующего основного обновления.
На мой взгляд, когда речь идёт о SEO, то есть об оптимизации результатов поисковой выдачи по сравнению с другими сайтами, обсуждение аппаратного обеспечения пользователей в основном не имеет значения.
Почему?
На самом деле всё довольно просто.
Возьмём пример одного человека и его результаты поиска на переносном устройстве.
Независимо от скорости устройства или типа чипсета, производительность будет примерно одинаковой на всех веб-сайтах, потому что конечный пользовательский опыт (производительность) одного устройства в сети будет, в основном, одинаковым для всех сайтов сопоставимой производительности. Более быстрые сайты будут работать быстрее, а более медленные — медленнее, независимо от чипсета и других характеристик устройства пользователя. Поднимающийся прилив поднимает все лодки, а опускающийся — опускает все лодки. В SEO устройства конечных пользователей являются «шумом» по сравнению с серверным приложением, которое и оптимизируется в рамках «SEO».
Таким образом, даже если мобильный телефон является самым быстрым во всей вселенной, все веб-сайты будут быстрыми (или медленными) в зависимости от скорости сети и дизайна сайта. Фокус SEO направлен на оптимизацию веб-приложения и его доставки, а не на устройства конечных пользователей. Если веб-приложение работает «потрясающе» на одном чипсете, то и все остальные сайты схожей конструкции будут работать так же. Фокус SEO — не на устройстве пользователя, а на оптимизации веб-приложения, контента и времени загрузки, зависящего от сервера, а не от клиентского устройства. Клиентские устройства посещают, теоретически, все веб-сайты, поэтому всё это является «шумом» в соотношении сигнал/шум в SEO.
С точки зрения SEO веб-сайта, ваша оптимизация поисковой выдачи, основанная на пользовательском опыте, будет одинаковой во всей сети для всех пользователей одного класса (по характеристикам производительности) всех мобильных устройств конечных пользователей. Единственное, что даст веб-сайту преимущество в SEO перед другим сайтом, — это производительность самого сайта (и его сети), а не устройств конечных пользователей.
Почему?
Потому что устройства конечных пользователей будут работать одинаково на всех веб-сайтах, если говорить в общем. Если мобильное устройство пользователя работает медленно из-за недостатка памяти или чипсета, то оно будет медленным на всём киберпространстве веб-сайтов. Иными словами, обсуждение того, как устройства конечных пользователей влияют на SEO, бессмысленно. Оптимизация поисковой выдачи — это серверная операция, а не клиентская.
Что важно, так это контент, представление и производительность, а также то, как ИИ Google оценивает эти факторы во всём киберпространстве. Например, если все люди во всём мире перейдут на мобильные телефоны с квантовыми вычислениями, SEO останется прежним, потому что у всех конечных пользователей будут одинаковые «кривые производительности устройств». Оптимизация происходит на стороне провайдера (веб-сайта). Точно так же, если всё киберпространство деградирует до медленных чипсетов в мобильных телефонах, ранжирование в поисковых системах останется в основном прежним, поскольку оптимизация, которая необходима, осуществляется серверами, предоставляющими веб-контент.
Конечно, Discourse как SPA, управляемое JavaScript, будет работать лучше после загрузки, если мобильные устройства станут быстрее. То же самое относится и ко всем остальным веб-сайтам! В целом, для SEO важна производительность сети, а также производительность сервера, а не устройство конечного пользователя. Это не моё мнение, это научный, инженерный факт. Моё мнение или эмоциональная привязанность к JavaScript или EmberJS не меняют того, как работает SEO. Для SEO важны контент и производительность веб-приложения.
В заключение: Google использует передовой ИИ, в основном искусственные нейронные сети, для определения того, как Google ранжирует и индексирует веб-контент. Оптимизация поисковой выдачи основана на том, как ИИ Google ранжирует сайт, на производительности сайта и на «привлекательности сайта для ИИ Google». Насколько мы любим JavaScript, Ruby или Python, или насколько нам нравится элегантность и механика любого веб-приложения, которое мы предоставляем конечным пользователям, не имеет значения, если только наша страсть к приложению не привлекает ИИ Google и если мы создаём уникальный контент, который хорошо представлен ИИ Google, и как ИИ Google воспринимает производительность, а не как мы воспринимаем производительность и контент.
Мы не ранжируем сами свои веб-сайты. Ранжирование выполняет ИИ Google.
Как публично заявил Google:
«Один из способов понять, как работает основное обновление, — представить, что вы составили список из 100 лучших фильмов 2015 года. Через несколько лет, в 2019 году, вы обновляете список. Он естественным образом изменится. Появятся новые замечательные фильмы, которых раньше не существовало, и они станут кандидатами на включение. Вы также можете пересмотреть некоторые фильмы и понять, что они заслуживают более высокого места в списке, чем имели раньше. Список изменится, и фильмы, которые ранее были выше в списке, но теперь опустились, не стали плохими. Просто появились более заслуживающие внимания фильмы, которые теперь опережают их», — написал Google.
Компания предложила следующий список вопросов для рассмотрения при оценке вашего контента:
Предоставляет ли контент оригинальную информацию, репортажи, исследования или анализ?
Предоставляет ли контент существенное, полное или всестороннее описание темы?
Предоставляет ли контент глубокий анализ или интересную информацию, выходящую за рамки очевидного?
Если контент использует другие источники, избегает ли он простого копирования или переписывания этих источников и вместо этого предоставляет существенную дополнительную ценность и оригинальность?
Предоставляет ли заголовок и/или название страницы описательное, полезное резюме контента?
Избегает ли заголовок и/или название страницы преувеличений или шокирующего характера?
Это тот тип страницы, который вы хотели бы добавить в закладки, поделиться с другом или рекомендовать?
Ожидали бы вы увидеть этот контент в печатном журнале, энциклопедии или книге или увидеть ссылку на него?
Это и есть SEO, и основная деятельность Google — создание алгоритмов, позволяющих машинам оценивать и классифицировать веб-сайты.
Это противоречит фактам — мы знаем, что Google собирает реальные показатели времени загрузки страниц с устройств Android и использует их для ранжирования страниц.
Да, но все устройства Android (одного типа) показывают практически одинаковые результаты на всех сайтах (одного типа). Иными словами, если вы оптимизируете веб-сайт на JavaScript, использующий webpacker и bundler, то с точки зрения SEO вы конкурируете со всеми остальными сайтами, которые являются SPA на JavaScript с использованием webpacker и bundler и т. д.
Я не утверждал, что Google не собирает эту информацию. Я пытаюсь объяснить, что фокусировка на клиентском устройстве не решит проблему производительности SPA в контексте SEO. «Возвышающийся приподнимает все лодки»: более быстрый процессор, который эффективно обрабатывает сжатый JavaScript (быстрый, оптимизированный и т. д.), будет показывать хорошие результаты на всех аналогичных веб-сайтах.
Иными словами, SEO находится на стороне сервера (как я подробно изложил выше), а не на стороне клиента.
Кстати, это хорошо задокументировано.
Ладно :). Я предпочту не обсуждать это здесь, на meta. Спасибо.
Google очень четко обозначил, какие сигналы для SEO они считают важными сейчас и в 2021 году. Они будут постоянно переделывать свой ИИ, исходя из событий и ситуаций в киберпространстве.
С точки зрения SEO вы действительно конкурируете с технически похожими сайтами.
Однако с точки зрения бизнеса вы конкурируете с другими сайтами на вашем рынке, независимо от их технологий. Это может побудить людей задуматься о переходе на технологию, которая воспринимается как «более эффективная» с точки зрения SEO. Именно в такой ситуации оказываются некоторые люди.
Я имею в виду, вы также говорите, что сообщества Discourse МОГУТ пострадать в результатах поиска в следующем году (мы уже увидим, что произойдёт).
Это я не предвидел!
С другой стороны, производительность iPhone 7 для Discourse достаточна, и я рад, что в конечном итоге все Android-устройства, даже старые, будут «как минимум такими же быстрыми, как iPhone 7». Также я держу кулачки за предстоящий Snapdragon 875; в ближайшие месяцы должно появиться больше деталей. 
