Рендеринг SEO: как Google переваривает ваш контент

Это стенограмма разговора между Бартошем Горалевичем, Мартином Сплиттом из Google и Джейсоном Барнардом. Они провели вебинар, чтобы обсудить рендеринг SEO с практической точки зрения. Вы можете посмотреть запись вебинара здесь, но, поскольку в ней так много информации, мы надеемся, что эта расшифровка окажется для вас полезной!

Бартош: Сегодня мы рассмотрим рендеринг с точки зрения Google, который немного отличается от того, что мы видим в Chrome, и поэтому Мартин здесь, чтобы провести нас через эти мутные воды.

И вкратце, в нашем исследовании, и опять же, это не исходит от Мартина, мы начали видеть первые упоминания о рендеринге и макете в патентах Google примерно в 2011 году. И моя личная теория заключается в том, что именно поэтому обновления качества контента Google Panda и все эти замечательные вещи начало происходить примерно в этот день.

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

Как я уже упоминал, большинство патентов Google, которые мы получили по этой теме, и именно так все и началось, сосредоточены на компоновке.

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

Итак, это первое, и в течение многих лет мы фокусировались на JavaScript SEO, как упомянул Джейсон, и, углубившись, мы поняли, что SEO JavaScript было в основном таким: «Может ли Google правильно увидеть ваш контент, можете ли вы изменить этот JavaScript на HTML» и тому подобное. , но когда мы нырнули немного глубже, то увидели, что это только верхушка айсберга.

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

Поэтому мы, как агентство, немного отошли от JavaScript SEO и погрузились в Rendering SEO, который намного сложнее и интереснее. Тем не менее, сегодня мы постараемся сделать это проще. Джейсон, ты должен быть на страже этого.

Есть много интересных вещей, мы, наверное, не получим точных ответов от Мартина, он ненавидит этот слайд, извини, Мартин.

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

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

Что-то, что я хочу упомянуть, когда мы говорим сегодня, это то, что есть четыре оттенка вашего веб-сайта. Не зная, многие из нас скрывают контент, потому что ваш контент теперь выглядит по-разному на мобильных устройствах с JavaScript и без JavaScript, и это относится к большинству веб-сайтов в настоящее время, так что речь идет не только о веб-сайтах на основе React или Angular, но и о WordPress. , Wix, возможно, и Duda, и большинство этих более простых фреймворков. У нас такая же проблема с десктопом. Таким образом, существует так много разных способов взаимодействия с контентом, и в основном это связано с рендерингом, как этот код будет отображаться на конечном устройстве.

Без лишних слов, давайте начнем. У нас здесь Мартин, так что я не буду отнимать у вас слишком много времени.

У меня первый вопрос только для того, чтобы как-то завести. Итак, Мартин, может ли рендеринг SEO помочь мне повысить рейтинг? Я предполагаю, что это первый вопрос, который у всех в голове.

Это практично, это то, что принесет нам трафик, потенциальных клиентов, все эти забавные и классные вещи?

Мартин: Я имею в виду, что обычно я не отвечаю на рейтинговые вопросы, здесь я сделаю исключение.

Вообще говоря – нет. Но, в частности, если есть проблема, когда что-то ломает ваш рендеринг и контент не отображается, то Googlebot не видит контент или не видит его должным образом, то, знаете ли, это может на самом деле навредить вам в смысле , мы не видим содержимое.

Поэтому мы можем не индексировать страницу. Или мы можем проиндексировать страницу, но не ранжировать ее по интересующему вас контенту. Так что да, в конце концов, это может изменить ситуацию и оказать влияние — да, конечно.

Бартош: Одна вещь, которую я хочу сделать, прежде чем мы углубимся в вопросы аудитории, это то, где рендеринг находится во всем сценарии?

Мы можем быстро перейти к сценарию того, что было первым, курица или яйцо, но я всегда понимал, что Google создает очередь, а затем сканирует, отображает и, очевидно, опционально индексирует страницу — будет ли это чрезмерным упрощением?

Мартин: Это немного упрощенно, но в основе своей верно. Таким образом, мы получаем много URL-адресов, и мы получаем так много URL-адресов, что мы не можем сканировать их все одновременно по очевидным причинам. Хорошо, я не должен говорить по очевидным причинам. Мы не можем сканировать все URL-адреса все время одновременно из-за пропускной способности, поэтому мы можем использовать ограниченную пропускную способность Интернета.

Если у вас есть интернет-магазин, и вы заходите завтра в интернет с новым веб-сайтом интернет-магазина, и у вас есть миллион URL-адресов продуктов, ваш сервер может выйти из строя, если мы просканируем все эти URL-адреса одновременно, поэтому мы должны распределить это по времени. , так что существует очередь между обнаружением URL-адреса и фактически сканируемым URL-адресом.

Эта очередь относительно прозрачна в том смысле, что консоль поиска показывает, когда последний раз сканировался URL-адрес, а также она прозрачна в том смысле, в каком сообщает вам ваш сервер. Вы можете проверить, когда был сделан последний запрос к этому URL-адресу от агента пользователя и IP-адреса Googlebot, так что это очень прозрачная очередь.

Затем происходит следующее: как только мы его просканировали, мы можем просмотреть полученный HTML-код, мы можем просмотреть статус HTTP. Если это статус 404, то на этом обработка практически заканчивается. Если есть метатег robots с надписью noindex, то наша работа на этом также заканчивается.

Но если мы получаем кучу HTML-контента и можем продолжить его обработку и остальную часть конвейера, мы также затем ставим страницу в очередь для выполнения JavaScript, что мы бы назвали «рендерингом». Вторая очередь очень непрозрачна, в каком-то смысле вы действительно не видите, сколько времени у нас уходит на рендеринг, если мы вообще рендерим, когда мы рендерим, вы не знаете, и это не случайно, потому что теоретически мы рассматривайте все это как транзакционный процесс, на входе есть обнаруженный нами URL-адрес, а на выходе — проиндексированный документ или неиндексированный документ. Примерно так здесь может случиться.

И вы не так уж много можете сделать с рендерингом с точки зрения изменения позиции в очереди или с точки зрения выяснения того, что рендерится или что должно быть рендерится. Вы видите это и в Search Console, вы видите, что получается в результате рендеринга, если вы посмотрите на Просмотр просканированной страницы , вы увидите то, что мы там увидели бы. Таким образом, нет дополнительной очереди, которую вы пропустили, и есть еще несколько сложностей, где упрощенная модель не обязательно применима. Но вы можете предположить, что поток обычно обнаруживает, сканирует, ставит в очередь, отрисовывает, индексирует, а затем, возможно, ранжирует позже.

Джейсон: Это действительно ясно.

Бартош: Просто хочу прояснить одну вещь, потому что вы упомянули, что до того, как это попало в тему в Интернете, вы упомянули, что вы рендерите страницу, и вы также упомянули JavaScript, но что я понял из наших предыдущих разговоров, так это то, что рендеринг — это не только JavaScript.

Мартин : О, да, это правда.

Бартош : Так что, даже если у вас есть веб-сайт, не поддерживающий JavaScript, например, на нем нет строки JavaScript и ссылок на внешние скрипты, вам также следует побеспокоиться о рендеринге.

Джейсон: Я собирался задать вопрос: сколько из нас на самом деле обеспокоены рендерингом, потому что эта концепция, идея, что это только JavaScript, нас всех волнует…?

Мартин : Ага. Все веб-сайты рендерятся, и все вы в той или иной степени обеспокоены, да, это правда, это правильно.

Джейсон : По сути, если у вас нет JavaScript, стоит ли вам вообще беспокоиться об этом?

Мартин : Вам не обязательно об этом беспокоиться, но это все равно влияет на вас. Есть еще потенциальные последствия от рендеринга.

Джейсон : Хорошо, блестяще.

Мартин : Это связано с тем, что Бартош сказал ранее, например, текст на первой странице или где, по мнению Google, находится ваш основной контент и тому подобное.

Джейсон : Верно, да. Что блестяще. Я имею в виду, что в основном это говорит о том, что часть рендеринга в основном заключается в понимании того, какую роль играет каждый фрагмент страницы. Бартош показал нам скриншот, на котором некоторые элементы не были проиндексированы, некоторые из них были рекламой, некоторые из них были заголовком, а некоторые — нижним колонтитулом. Рендеринг — это момент, когда Google решает, какую роль играет каждая часть страницы, поэтому он может принять решение о том, индексировать ли ее и отдавать ли ей приоритет, с точки зрения того, что говорил Бартош — это основной контент?

Бартош : Все верно.

Джейсон : Но в основном, как это решает?

Мартин : Так что, может быть, нам нужно немного поговорить о том, что такое рендеринг? Потому что я не уверен, что все знают, что это значит, верно? Должны ли мы это сделать?

Бартош : Извините, Мартин, это очень хороший момент для всех, кто смотрит, чтобы задать все вопросы по каждому пункту, который вы не поняли прямо сейчас.

Мартин : Ага!

Бартош : Мы с Мартином понятия не имеем, в какой момент мы потеряем аудиторию, но то, что мы пытаемся решить, чтобы быть полностью прозрачными, обратная связь от нашего предыдущего разговора заключалась в том, что иногда мы становились слишком гиковскими, слишком занудными. , поэтому мы хотим сделать это действительно простым.

Джейсон : Блестяще сказано. Дайте определение рендерингу, что это такое, каков процесс?

Мартин : Верно. Если вы думаете о HTML как о рецепте, и у вас есть все ингредиенты, у вас есть куча текста, изображений и прочего. Но на самом деле у вас его нет в рецепте, рецепт - это лист бумаги со всеми инструкциями, как сделать вещь.

Ресурсы веб-сайта — это ингредиенты, такие как CSS, файлы JavaScript и изображения, видео, все то, что вы загружаете, чтобы на самом деле страница выглядела так, как она выглядит после.

Веб-сайт, который вы знаете и используете в своем браузере, вы видите в своем браузере — это последнее блюдо.

Рендеринг — это в значительной степени кулинария, процесс подготовки.

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

И затем рендеринг — это процесс, когда рендеринг говорит: «Ага, интересно! Краулер, ты можешь достать мне эти 10 ингредиентов?», и краулер удобно говорит: «Да, я принес тебе эти 10 ингредиентов, которые тебе нужны», и мы начинаем готовить, вот что такое рендеринг.

Таким образом, рендеринг анализирует HTML. По сути, HTML, когда дело доходит до сканирования, представляет собой просто набор текста, удобно отформатированного, но текст.

Чтобы превратить это в визуальное представление, которое на самом деле является веб-сайтом, нам нужно отобразить его, что означает, что нам нужно получить все ресурсы, нам нужно в основном понять, что говорит нам текст.

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

И весь этот процесс сборки, это понимание того, что это такое, и сборка этого в визуальное представление, с которым вы можете взаимодействовать в окне браузера, — это рендеринг.

И в рамках рендеринга, на самом первом этапе — выполняем JavaScript.

Поскольку JavaScript — это, по сути, рецепт внутри рецепта, JavaScript может быть таким: «а теперь нарежьте этот лук». Таким образом, у вас есть сырые ингредиенты, то есть лук, но вы не кладете лук целиком в блюдо, а нарезаете его, и для этого нужен JavaScript.

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

Можете ли вы сказать, что я только что приготовил ужин и сейчас очень голоден? Мне очень жаль!

И выполнение JavaScript — это просто часть рендеринга, но затем, когда выполнение JavaScript завершено, или если нет выполнения JavaScript, это тоже хорошо, но что тогда происходит, мы собираем, выясняем эти кусочки и то, как нам нужно, например, собрать их на странице, и это приводит к тому, что называется деревом макетов, а дерево макетов говорит нам, насколько велики объекты, где они находятся на странице, видны они или нет, находится ли одно за другим. .

Эта информация важна для нас так же, как и выполнение JavaScript, потому что JavaScript может изменить, удалить или добавить контент, которого не было в исходном HTML, поскольку он был доставлен сервером.

Итак, это рендеринг в двух словах. От «У нас есть немного HTML» до «У нас потенциально есть куча пикселей на экране». Это рендеринг.

Бартош : Я хочу добавить несколько вещей, о которых Мартин не говорит, потому что он работает в Google. Глядя на это с технической стороны SEO, рендеринг обходится довольно дорого — как именно это влияет на Google, остается большой загадкой, и мы продолжаем исследовать это, мы даже запустили отдельную компанию, инструмент для этого. Короче говоря, рендеринг для мобильных устройств обходится Google довольно дорого. Если у вас есть как Alcatel 1X, как старый телефон, может быть, более дешевый телефон, он будет бороться с такими веб-сайтами, как BBC, The Guardian, которые содержат много JavaScript. С чем Google тоже будет бороться. Но, короче говоря, рендеринг стоит дорого. И по нашему опыту, некоторые скрипты, некоторые веб-сайты не оптимальны для Google, и в конечном итоге они не воспринимаются должным образом по ряду причин.

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

То, что мы довольно часто видели бы в качестве признака проблем как с рендерингом, так и с индексацией, это, например, то, что у вас очень динамичный веб-сайт, у вас есть тонна Javascript, и вы видите, что ваш контент загружается очень медленно. Например, вы публикуете новое объявление на сайте недвижимости и видите, что Google подхватывает его через 3 недели, а ваши конкуренты — через день. И это сценарий, когда мы сели бы и посмотрели, что здесь происходит, почему Google борется с этим аспектом?

Как вы относитесь к этому Мартину?

Мартин : Мне нравится этот вопрос, потому что он создает здесь интересный момент.

Потому что, если подумать, в этом случае Google Search сталкивается с той же проблемой, что и реальный пользователь. Потому что для реального пользователя, даже если вы используете современный телефон, а также действительно быстрый, фантастический и дорогой телефон, более высокая производительность также всегда означает большее энергопотребление.

Были люди, которые называли JavaScript углекислым газом Интернета. Я не думаю, что это совсем неправильно. Очень красивое и удачное сравнение.

Вот поиск Google, а вот пользователи, которые на самом деле используют ваш сайт, и мы в одной лодке. Чем дороже вы его делаете, тем хуже для нас это опыт. Google Search на самом деле не заботится, нам просто нужно инвестировать в ресурсы, которые нам нужны, и мы делаем много оптимизаций, чтобы убедиться, что мы тратим как можно меньше времени и энергии. Но очевидно, что если вы оптимизируете это, приятный побочный эффект заключается в том, что ваши пользователи, вероятно, также будут счастливее, потому что им нужно меньше батареи, их старый телефон по-прежнему будет нормально работать с тем, что вы туда вложили, и они смогут потреблять ваш веб-контент и, возможно, не ваши конкуренты, потому что вашим конкурентам просто все равно, и они фактически производят что-то, что менее удобно для использования на их телефонах. Так что это не то, где вы противопоставляете Google и UX, это вроде как одна и та же проблема или одна и та же проблема, и мы все сталкиваемся с ней, включая Google Search, так что это хорошо.

Джейсон : С моей точки зрения, вы говорите: оптимизируйте, упростите работу Google — какую награду дает нам Google? Просто для вас это быстрее, следовательно, вы можете делать больше одновременно?

Мартин : Не совсем так, потому что рендеринг происходит снаружи, рендеринг асинхронный, поэтому это означает, что мы не ждем, пока не произойдет рендеринг, а затем обрабатываем, мы в основном пытаемся сделать как можно больше параллельно. Например, если в исходном HTML-коде есть структурированные данные, мы можем подобрать их сразу после сканирования, пока происходит рендеринг, поэтому вы получаете маргинальные преимущества. Вы могли бы на самом деле получить большие преимущества там.

Если у вас есть что-то, где контент постоянно меняется, то сделать это доступным как можно раньше в процессе, и то же самое касается канонических элементов, заголовков, метаописания, структурированных данных — как можно раньше, это хорошо для вас с точки зрения выбора нами. это чаще или быстрее.

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

И вы упомянули разметку схемы, и вы говорили о дереве компоновки, и я невероятно заинтригован, потому что вы получаете это дерево компоновки, разметка схемы потенциально является частью этого дерева компоновки, и вы в основном говорите, что это схема, это объявления, это заголовок, это правильно? Является ли схема частью этого?

Мартин : Схема не является частью вашего дерева компоновки, потому что это не визуальный элемент. Таким образом, все, что визуально или потенциально видимо, является частью дерева компоновки. Разметка Schema никогда не будет видна.

Здесь задействовано множество деревьев, и я не хочу всех запутать. По сути, происходит то, что в первый момент, когда у нас есть текст, мы разбиваем его на отдельные элементы и создаем объектную модель документа — это DOM, на который ссылаются люди. DOM — это, по сути, просто способ браузера сказать: Итак, у меня есть этот заголовок, внутри которого есть текст, это еще один узел в этом дереве, а затем у меня есть этот текстовый блок, а внутри текстового блока есть ссылка, внутри которой есть текст. ссылка, затем здесь изображение, и вы знаете, это все, что есть на странице, включая разметку схемы, а также все метатеги, заголовок и все такое.

Все, что невидимо, например метаинформация, схема, JavaScript и CSS, не является частью дерева макета. CSS косвенно, по своим эффектам, также анализируется в дереве. На всякий случай есть еще CSSOM, и это то же самое, что и для HTML, но для CSS. И он сопоставляется с DOM, чтобы создать внешний вид, который вы создали в CSS для элементов DOM, для элементов HTML. Но сам по себе он не будет отображаться в дереве компоновки.

Джейсон : Бартош, ты показывал неиндексированные элементы. И это, предположительно, дерево компоновки, вы принимаете решение, прежде чем перейти к этапу индексации: «Нам это не нужно, это неинтересно, слишком длинно или слишком легко». Вы так это понимаете, Бартош?

Бартош : Существует ряд причин, по которым часть контента может не индексироваться. Это не всегда вина рендеринга, это ключевой момент, о котором нужно помнить.

Иногда это частично вина рендеринга. Если вы смотрите на контент, который виден на десктопе, но не виден на мобильных устройствах, это происходит из-за рендеринга, но проблема не в том, что Google отрисовал его неправильно, проблема в том, что вы не показываете один и тот же контент на десктопе и для мобильных устройств, что происходит довольно часто, например, для магазинов электронной коммерции.

Таким образом, может быть ряд причин, иногда, как мы полагаем, и это то, что Мартину придется либо подтвердить, либо опровергнуть, мы предполагаем, что Google пропускает элемент страницы, который каким-то образом не очень важен или не имеет отношения к содержанию. Итак, если у вас есть контент, я думаю, это то, о чем мы говорили в прошлый раз, Мартин, о собаках, и ниже у вас есть куча рекламы велосипедов в качестве «Похожих товаров», то довольно часто они не будут подхвачены Google. И почему это происходит, вероятно, потому, что у Мартина немного больше знаний.

Мартин : Это не рендеринг, мы просто анализируем контент. Я не знаю, что мы публично говорили об этом, но я думаю, что упомянул об этом в одном из эпизодов подкаста — например, у нас есть вещь, называемая аннотацией центральной части, и есть несколько других аннотаций, которые у нас есть, где мы смотрим в семантическом контексте, а также, возможно, в дереве макета.

Но в принципе мы уже можем прочитать это из структуры контента в HTML и понять это. «Похоже, что из всей обработки естественного языка, которую мы сделали для всего этого текстового контента, который мы получили здесь, похоже, что он в первую очередь касается темы А — корм для собак, а затем здесь есть еще одна вещь, которая кажется ссылками на связанные продукты, но на самом деле это не центральная часть, это не совсем основной контент здесь, это, кажется, дополнительные вещи, затем есть куча шаблонов», поэтому мы выяснили, что меню выглядит примерно одинаково на всех этих страницах, и это похоже на меню, которое есть на всех других страницах этого домена, или мы видели это раньше.

Мы даже не идем по домену или «О, это похоже на меню». Мы выясняем, что выглядит как шаблон, и это также получает разные веса.

Поэтому, если у вас есть контент на странице, который не связан с основной темой остального контента, мы можем не уделять ему столько внимания, как вы думаете. Мы по-прежнему используем эту информацию для обнаружения ссылок и определения структуры вашего сайта и всего такого, но если на вашей странице 10 000 слов о корме для собак и примерно 2000–3000 слов о велосипедах, то, вероятно, это не очень хороший контент для велосипедов.

Джейсон: Помогает ли вам семантический HTML5?

Мартин : Это помогает нам, но это не единственное, что мы ищем, да.

Джейсон : Хорошо, хорошо. Это небольшое подспорье, но это не что-то серьезное, ради чего мы должны перестраивать весь наш сайт, потому что вы можете догадаться.

Мартин : Да.

Бартош : Итак, чтобы закрыть эту тему и двигаться дальше, иногда вы также будете видеть часть этого контента, например, связанные элементы — это довольно часто зависит от JavaScript. Очень часто на большом количестве JavaScript.

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

Вы также делаете, вы взвешиваете это иногда, у вас есть, это будет очень сложный вопрос, чтобы ответить, у вас есть алгоритм, который скажет хорошо, это стоит тонны для рендеринга, но это не приносит этого большое значение, мы должны пропустить его. Это то, о чем вы можете говорить? Я не уверен, следует ли избегать этого вопроса?

Мартин : Это не тот вопрос, которого нам следует избегать, это интересный вопрос.

Насколько я могу судить, нет. Мы не говорим: «О, это сложно визуализировать, мы пропустим это, потому что это не добавляет большой ценности», это было бы интересной эвристикой для рассмотрения, но я не думаю, что мы делаем это на данный момент. Что мы делаем, однако делаем, так это то, что в конце концов, и я говорю в конце концов, очень конкретно, и я намеренно расплывчат здесь, потому что нет очень четкого момента отсечки, а если бы он был, я имею в виду, что он есть, но это подлежит меняться, и я не хочу, чтобы люди сосредотачивались на чем-то бессмысленном.

Есть момент, когда мы говорим: «Хорошо, это уже достаточно долго рендерится, я думаю, у нас все хорошо». Опять же, есть куча эвристик, но в основном, если реальный пользователь сочтет, что «это слишком долго», то мы тоже сочтем это слишком длинным.

Так что да.

Бартош : Итак, я думаю, что для аудитории нужно немного подчеркнуть одну вещь, это то, о чем мы говорили перед вебинаром, вы довольно часто упоминали ресурсы. О каких ресурсах нам следует позаботиться, чтобы облегчить жизнь Google?

Мартин : Честно говоря, больше всего я беспокоился бы о файлах JavaScript.

Бартош : Нет, ресурсы вроде ресурсов сервера. В прошлый раз вы объяснили это довольно хорошо, и я думаю, что это принесет пользу аудитории.

Мартин: Что я тогда сказал?

Бартош: Вы упомянули, что вам не так важна оперативная память, например, вы беспокоитесь о процессоре. Я не помню, что вы говорили о хранении, но это тоже было где-то в разговоре. Но, по моему предположению, ЦП является ключевым элементом, за которым нужно следить прямо сейчас, поэтому, если вашему веб-сайту требуется много процессорного времени для рендеринга, это то, на что нужно обратить внимание, это то, что нужно оптимизировать. Это было бы правильно?

Мартин : Да, так что теперь я знаю, к чему мы клоним, большое спасибо за помощь, Бартош.

Да, как я уже сказал изначально, в браузере и в поиске Google рендеринг — это грубое преобразование текста в пиксели на экране.

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

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

Джейсон : И здесь также один вопрос, продвигаясь вперед: чем больше вы видите определенный тип сайта, тем легче его визуализировать? Или нет никаких последствий использования такой платформы, как Duda или WordPress? Это помогает или это совсем нестандартно?

Мартин : Это может помочь, а может и не помочь. Причина этого в том, что теоретически хорошая вещь в платформах заключается в том, что всякий раз, когда они оптимизируют реальную платформу, вы получаете эту оптимизацию бесплатно. На самом деле вам не нужно ничего с этим делать, так что это хорошо. Если вы строите что-то свое, то вам придется выполнять работу по оптимизации, и никогда еще какая-то оптимизация волшебным образом не падает вам на колени, и все становится лучше. Но это верно практически для любой готовой, открытой или общедоступной CMS или платформы. С другой стороны, платформы, из-за того, что они такие широкие и универсальные, часто несут много мертвого груза просто потому, что некоторые веб-сайты могут использовать определенную функциональность, а если ваш веб-сайт не использует, то он фактически несет этот вес. тем не менее, и это может быть не здорово.

Джейсон : Важно ли для меня как для веб-мастера или разработчика избавиться от мертвого груза, даже если он ничего не делает, просто избавляясь от него, чтобы он не мешал?

Мартин : Извините, вы не могли бы еще раз пропустить это мимо меня?

Джейсон : Вы говорили о мертвом грузе, если я смогу убрать его, это будет для меня феноменальной победой?

Мартин: Да, но проблема с платформами в том, что обычно вы не можете…

Бартош : Итак, я думаю, мы также можем сделать крошечный шаг назад к бюджету краулера, о котором упоминалось. Итак, одна вещь с рендерингом заключается в том, что иногда, скажем, это то, на что мы не обращаем внимания при рассмотрении бюджета краулера, и мы, оптимизаторы, что это касается не только основного HTML-файла, но если у вас есть JavaScript файл, который будет расширяться, который будет обработан, и запросит еще около 10 файлов, это все, насколько я понимаю, они также входят в бюджет краулера.

Так что, насколько я вижу, есть большая ценность в уменьшении количества запросов. Очевидно, что это немного сложнее, чем просто уменьшить количество запросов и создать один огромный файл, но есть большая ценность в упрощении кода, количества запросов и веса — в основном, стоимости рендеринга.

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

Мартин : Хорошо то, что служба веб-рендеринга использует инфраструктуру сканирования для выборки ресурсов, а это означает, что она использует инфраструктуру, специально созданную для сканирования сети в масштабе.

Так что сетевая часть не самая плохая. Что сложного, так это по порядку, так что, ладно…

Здесь возникает еще одна проблема или еще одна проблема, а именно проблема времени и порядков.

Если вы пишете компьютерную программу, программы, как правило, выполняют одно из двух действий: либо они привязаны к процессору, либо к операциям ввода-вывода. Что это обозначает?

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

Это операция, которая потребует просто обработки чисел в ЦП. ЦП создан для обработки чисел, поэтому он будет очень быстрым, но наша программа будет, что называется, привязана к ЦП.

Это означает, что скорость работы программы и время, которое требуется программе для выполнения своей работы, зависит от того, сколько ресурсов ЦП вы можете выделить для нее, что, как правило, более предсказуемо, чем то, что связано с вводом-выводом.

Что означает IO-bound?

IO-bound означает, если я скажу: «Напишите мне программу, которая перечисляет все файлы на моем жестком диске, на этом компакт-диске или на этом USB-накопителе».

Этой программе больше не нужно, например, запускать ЦП, и в основном она просто переворачивает числа в ЦП. Но на самом деле моя программа запрашивает внешнее оборудование, под внешним я подразумеваю за пределами ЦП.

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

По сути, он читает первый каталог и находит первый файл в каталоге, читает его, файл возвращается, теперь ему нужно прочитать второй файл… И это то, что IO — ввод-вывод — связан.

The choking factor, the thing that determines how fast something can be done here is no longer the CPU, it's the input-output, how long does this take.

The fastest is… if you talk to what is called a CPU cache, that memory that's usually inside what we would call the CPU, the central processing unit, the second fastest is if you read from local memory, from RAM. The next fastest would be a local SSD drive. And so on and so forth.

Network, unfortunately, is thousands and thousands of times slower than any of these local file accesses and these are a thousand times slower than memory access, and that's thousands of times slower than the access of the cache in the CPU.

And be careful, when I say cache, I mean a very specific tiny type of memory chip.

There is another cache, which we are using because we are IO-bound, as you can imagine, we have to fetch the resources. So it's not about the CPU or executing the JavaScript.

What takes a lot of time is going to the network and fetching the JavaScript from your server and getting that back, that is always going to be thousands of times slower than having it stored somewhere on a, let's say, hard drive, on an SSD drive somewhere in our data center.

So, we have a completely different cache, not the cache I mentioned earlier, that's a CPU internal bit and piece and we don't care about that.

We have a cache where basically whenever our crawler infrastructure fetches a resource, we store it on a drive inside our data center. So we are reducing these thousands of thousands of seconds down to a few seconds. And the problem is that if you split up your application across lots of files, let's say, a dozen files, a dozen of JavaScript files specifically, then we have to fetch all of these, now we only have to fetch these once probably and we can cache them.

But what if these files constantly change? Then we can't cache them. What's worse is, you may think “Oh, that's just one big file and all of it is in one file and that's better to cache!” No!

Because if you split it up the right amount, let's say instead of dozens of files, you now have 4 files, and from these 4 files only 2 change on a daily basis or on a weekly basis, then we can use the cache for at least the other files that never change. Good job.

But if you have all of this in one big file and it will constantly change and we can never make use of our cache. So we always have to go through the much slower network – that's a consideration that's very tricky to navigate.

And I can't give you hard and fast rules or numbers for it either.

It's a case-by-case basis, you wanna figure out how much of the stuff really has to change a lot, what other stuff is kind of stable and doesn't change as much, you wanna separate these two things.

Jason : Does that also mean that the network, the slowness of the network if you're pulling in files from different sites? That also?

Martin : Yes.

Jason : Which brings us to the question from Simox Cox, which is aimed at you, Martin: what can we do to help render Google's own scripts, analytics, and fonts?

Martin : You don't have to worry about analytics, because as far as I'm aware we are skipping analytics, with fonts, I think we are skipping them as well.

Jason: So we don't have to worry about them from the rendering perspective.

Martin: No, not from the rendering perspective, let's stick with that.

Bartosz : Just to add to that, one thing, at least to my knowledge, that you don't have to worry about with that is image fetches. That's why it's worth having image dimensions in the code because WRS – Web Rendering Service – also doesn't request images.

If you think about that, if you have a lean website of just HTML, CSS, like a lean JavaScript file, this does the trick. In our experience, this can improve rendering, indexing, crawling quite a bit just by cleaning up, a little bit of code-housekeeping, let's call it that.

Jason : You said about images though, it's very interesting because from a rendering, and getting the layout tree perspective, setting the size of the image or specifying is phenomenally important, and most lazy developers like myself don't bother doing it.

Bartosz : So, if you do that, according to my knowledge, Google doesn't have to request those files. So that's quite cool because you also cut the time of those requests, and you make Google's job a bit easier. Let's go to other questions.

Jason : Johann had a question: Is the rendering stage mandatory for a page to get indexed or could it be considered for indexing without the rendering stage?

Martin : It could hypothetically happen, but in practice it normally doesn't.

Jason: So all pages need rendering, with 1 or 2 exceptions, but none of us are likely to be concerned by that specific exception.

Bartosz: So I'm assuming this comes from those two waves of indexing. So Martin, what's the status on that right now? It's complicated as far as I can remember.

Martin : So I joined Google in April 2018, I remember that. Once I did my onboarding, Google onboarding, all of that lovely, cuddly nice time that you get when you get onboarded at Google, once that was over I sat down at my desk, and then I talked to John, Maria, Tom, and eventually, they were like, “We're prepping for Google I/O” and I saw the slide deck and I looked at two waves of indexing and I said to John, “Are you sure we wanna go with that?”, and he's like, “Yes, I think that makes it clearer, what happens”, and I'm like, “Yes, okay, I can see that it's a nice and easy explanation.”

And at least I, I know that John wasn't surprised, but I was surprised by the conclusions people drew from that.

And I was like oh God, okay, lesson learned here, that was an oversimplification. It was making what happens behind the scenes to simple and it implied a bunch of stuff that were not meant to be implied, for instance there's like “Yeah, things get indexed without the rendering happening, and then the rendering happens afterwards and changes the indexing.”

Jason: But that isn't the case?

Martin: It can be in certain cases, but it's very rare. It's also my fault because I looked at it and I said, okay, that's good.

Bartosz: To be fair, we saw, and everyone in the community dealing with JavaScript saw, quite often JavaScript would change metadata. Why you'd do that is beyond me.

Anyhow, sometimes you have one title, or one meta description with JavaScript disabled, without rendering, and you have a different one when Google renders.

And we saw websites when different pages were indexed differently. And that's why many people in the SEO community were like, okay, this page is waiting for the second wave of indexing.

Anyhow, Jason, let's go with another question.

Jason: No, right, the question you were asking there, people rewriting titles, for example, people do it with Google Tag Manager because they can't get their hands on their titles because they can't get the access to it.

That is a phenomenal problem for you guys. I mean, what you're saying is, from what I understand, sometimes you pick up the original one, sometimes you pick up the one inserted by Google Tag Manager.

Martin: Yeah, yeah.

Bartosz: And this goes beyond just meta title and description. You will see JavaScript rewriting the links, rewriting the whole structure, breadcrumbs, and with this happening, this must be really difficult to index that page and crawl that page quickly and efficiently.

Jason: So maybe we can change that to the question about, when a page changes overtime with the JavaScript even as it's loading which is the case with the meta title I just gave, how much of a problem is that for Google, so we're turning that into a more general question?

Martin: Sorry, can you run that past me again?

Jason: The fact that as the page, the page loads and things change before the users even interact with it, because you coded the things in to override because you're not very good at your job. How much of a problem does that cause?

Martin: Unless you have proof that it really is a problem for you, I wouldn't worry about it.

Normally it shouldn't be that much of a problem because normally, the clearly better content and information should definitely be there after rendering and might or might not be there previous to rendering.

What is tricky is when that's not the case, one, and the other thing is coming back to what I said earlier, the earlier you can get us data, the better, and I'll append to that.

Because when you think about it, if we were having a conversation, and I tell you oh, by the way, the restaurant to the left is terrible and the restaurant on the right is really, really good, but then 10 seconds later I'm like, no, actually, the restaurant on the left is amazing, the restaurant on the right I wouldn't bother with.

What do you do with that? That's kind of the same, if I have a title and a canonical at the beginning of the process and then that changes, then which one is the right one? How do we find out?

Bartosz: One thing to remember is, if you're leaving that decision to crawlers, and I'm not only talking about Google, because that also goes to Twitter, Facebook, Bing, all the other creatures of the web, if you leave that decision to Google, you create like a layer of chaos in your structure.

Because you don't know which pages are gonna be picked up which way, and even if just some of them won't be picked up properly, which again, sorry Martin, probably I'm not helping, but we're seeing a lot of cases where the signals from your end, so you have one version with HTML, one version with JavaScript – oversimplifying – then we're seeing different artifacts when this website is being crawled and rendered and indexed.

And I think this is proper development, this is something we need to, that's why we try to talk about these topics with Martin quite a bit, because this is something in the gray area between SEOs and devs.

Because, you know, it's a very difficult topic right now, is this something that technical SEOs should focus on? Not all companies have the luxury of technical SEOs in-house. Or is it something that the dev team should worry about? I guess the main topic is to look into that.

We have a tool – What Would JavaScript Do? – and if you google the tool, you can see, okay, which elements of the page are being changed with JavaScript. So this is very simple, just do that, look into those elements, just match those two and you're good. Even if you have to depend on JavaScript.

Martin: To be the devil's advocate for the developers, if all you have is client-side rendering and there are situations where you might for some reason have to do that, then it's not super easy to provide something server-side first, like in the initial HTML, and then updating something that is missing or that's very generic into something more specific and more high-quality, with JavaScript, is still a good thing over not doing it at all.

I'm not saying it's good, I'm not saying it's optimal and I absolutely 100% agree with Bartosz that you should make it match, but if you really can't, it is a way of doing things, it's just more shaky and error-prone than if you can avoid that.

Jason : One question many people are asking is, do authoritative sites get more “rendering” resources from Google or it doesn't matter?

Martin: No. You have to have this one meta tag, meta cheese=”” and then your favorite cheese, if it's the right kind of cheese and it changes weekly, then you get more rendering resources from John personally.

Bartosz: To support Martin's statement, being 100% serious right now, we're seeing websites, like home pages of newspapers, of huge eCommerce stores where you'd see main content not being picked up and we're seeing small websites indexed properly with similar technological stack, so I have to confirm, we're also not seeing like huge websites or heavily linked websites having some kind of benefit.

(…)

Bartosz : In general, something that we talked about with Martin. Rendering is so crucial with all the websites pushing so much JavaScript right now. And I guess, Martin, what would be…

Is there any way we can make rendering more interesting, more sexy in a way as SEO community?

I think this is something we talked about it so many times. We both know that rendering is so important and for the first time Google is not that black box anymore, we have so much data, Martin is available with all the answers, just… Not too many people seem to care about it.

We launched the Rendering SEO manifesto like June last year, I was thinking this would change the industry, I was thinking, this was gonna be this explosion within the industry, but this is not being picked up. And Martin, is there anything we as SEOs can do to push the envelope on this one?

Martin : That's again a tricky one because technically, I spoke to the rendering team about this, and they're like, “We like that rendering is not sexy”, and I'm like “Yeah, but there are people very worried about it and there is a bunch of stuff where you can miss out.”

I would just love people to experiment more. There are a few people in the community that are experimenting a lot, Giacomo Zecchini being one of them, I know that Dave Smart is experimenting a lot. And it's just really, really cool to see people experimenting and telling me what they're observing and checking in why what they're observing is what they're observing.

Я приведу очень простой пример. Адам Гент был первым, кто очень публично указал, что они видят функции, поддерживаемые роботом Googlebot, в рендеринге JavaScript, которые не поддерживались ранее, поэтому он был тем, кто публично застал нас в развертывании вечнозеленого робота Googlebot, и это заставило меня очень счастлив. Потому что куча людей только что спросила, когда это произойдет, и я не могу точно сказать, потому что мы не можем объявить что-то заранее, потому что объявление может сместиться во времени или с ним могут быть проблемы. Но если кто-то скажет: «Эй, Мартин, мы видим эту штуку. Что здесь происходит?», тогда я могу сказать: видите, вот что происходит прямо сейчас: мы увеличиваем процент рендеров, использующих вечнозеленого робота Googlebot. И эта страница, которую вы только что видели, была той, на которой действительно был виден новый вечнозеленый робот Googlebot.

Я думаю, что Джакомо Дзеккини поймал меня на странном поведении веб-воркеров, что действительно интересно, потому что я долго говорил об этом с командой рендеринга, и они говорили: «Никто этим не пользуется, перестань Это!" и теперь люди начинают его использовать, и я думаю, нам нужно изучить его.

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

И я просто хотел бы, чтобы больше гиков присоединились к нам и просто, знаете ли, поиграли и исследовали.

Джейсон: Это касается всех аспектов SEO. Чем больше мы экспериментируем, изучаем и делимся, тем больше узнает наше сообщество, а также тем больше вы узнаете о том, как мы подходим к этому, и как вы можете помочь нам помочь самим себе.