CLS новая пузомерка гугла

Сейчас они и не участвуют в ранжировании, ни новые, ни старые. Только если старые в крайних случаях занижают позиции.

Вообще пузомерки нужные, ранжирования хоть и пролетает, но ПФ и конверсия напрямую от этих показателей зависит.

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

Тут еще возникает две маленьких проблемки... Что бы уменьшить LCP, приходится пожертвовать временем загрузки первого контента, из-за того что нужно прелоадить доп часть фалов. В моем случаи иначе ни как, AMP ну ни как я не могу оптимизировать)) Если свои файлы js или картинки, то выход простой есть, через ngшnx push прелоадим и все. Конечно можно заморочиться и сделать рендеринг amp на стороне сервера и пользователю отдавать просчитанный и построенный конечных html, но нагрузку уже на сервер дает нормальную. Пока замкнутый круг, но по итогу 90% удалось сделать.

А вот с CLS просто, нужно убрать моргание или смешение блоков в верстке за пределы видимой области. Обратите внимание, ругаться не только на изменение элементов html может, но так же на обычную картинку меняющую размер блока, к примеру не указана высота и т.д. Сложного ничего в это нет, возможно самым простым будет у кого css большой и в файлах, сделать предзагрузку стилей в html, как давно и советуют.

У меня ругался на форму комментов, а она в самом низу страницы.

Весь css грузить в html - это бред, но по ходу гугл этого и просит. Одним словом, добро пожаловать в каменный век. И это когда в моём городе 5G (1Гиг можно скачать за пару секунд).

Гугл = препятствие прогрессу.

Сейчас на первом месте среди факторов ранжирования - правильный УРЛ. Обязательно должно быть вхождение ключей -pinterest и books

Обсуждали такой подход несколько лет назад. А в пример приводили как раз вёрстку Гугла и Яндекса, у которых всё было в коде страницы.

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

Зачем к многим, собери всё в один файл и кешируй везде и всюду.

Вроде технология (кеширования) не новая и хорошо себя зарекомендовала, зачем заново изобретать велосипед?

тут не согласен, он дал отличный инструмент, целый фреймрок AMP

В твоем случаи есть же решение, прелоад css либо nginx push css файла, но не через preload тег пушить, а через конфиг nginx. Разница в скорости, пуш и там и там идет, но в разное время. Если через конфиг nginx пушить, то пуш css файла идет сразу после отправки запроса к странице, не дожидаясь ответа сервера уже летит пуш файлов. А когда через прелоад теги пушит чуток по позже происходит, как только получает ответ сервера, ну и соотвественно сам html. Разница тут существенная получается. Через прелоад из-за того что одновременно с html пуш летит, бывает задержка из-за моб инета, типа нагрузка на сеть, либо из-за самого моб устройства происходят тормоза при обработке и это сказывается на скорости и порядке рендеренга.

Ну вот у меня все на AMP, сразу адаптив. И в нем сразу по умолчанию css только в теле html. Ничего плохого в этом нет, реально ускоряет рендеринг и загрузку, ну и я полностью сделал по его рекомендациям - выдаю на страницу только тот css который на ней нужен. Так же и с js файлами AMP и картинками из видимой части страницы в прелоаде и пререндер след страницы. Но с AMP эта мера была изначально необходима, было ограничение на объем css в 50 кб, правда сейчас его увеличили до 100кб, но у AMP есть файл js на сам движек фреймворка и на каждый компонент только отдельный файл js подключать. Вот и начинаешь экономить когда у тебя для карточки товара 15 js фалов AMP загружаются и пропушить их заранее никак, только относительные(со своего сервера,сайта) файлы можно. Скажу так - заморочки есть, но конверт вырос по итогу на 30%, а значит оно того стоило.

Скорость загрузки и первой отрисовки радует, 1 сек. без CDN и прочего, сервер в Европе, пользователь в Новосибирске.

но есть одна заморочка с тем же AMP и довольно значительная. В общем, весь AMP это набор компонентов, которые динамически изменяют и заполняют контейнеры html через js. Да и к том уже, основное удобство это загрузка контента через json запросы и обработка/генерация и вставка этих данных в DOM через шаблоны.

Так вот, ругается в десктопе на блок меню который ввиде аккардиона сделаен и как раз есть часть через эти json запросы. Смещение и все, ну конечно будет оно. Конечно можно решить и убрать json запросы там и соответственно не будет его, но какож хобота тогда теряется фишка технологии, так как уже основной контент из-за этой пузомерке пришлось в видимой части по старинке статически выводить в HTML, а все что ниже подгружать через json, казалось бы - мелочь, а вот и не мелочь на практике получается. Во-первых, вывод и генерация через json значительно уменьшает объем кода страницы, не забывайте, весь css в теле html по умолчанию всегда у вас, даже оптимизированный вывод только нужного css на странице при норм, не усложненном дизайне с учетом его адаптивности - ну от 40 кб мин уже будет, так как общий css для всех у меня 25кб и это без излишеств. + представьте сколько данных может не погружаться изначально, как вариант большое каскадное меню с выборками или сколько для блоков из декстопа будет срыто в мобильнике? В общем, казалось бы дебри, слишком глубоко зарываюсь. Нихера, тут 10кб, там 5кв, тут еще и т.д. чем больше пакет, тем дольше летит и доп 20кб у меня дают доп 100мс. Во-вторых, вся эта динамика как раз и позволяет не только с экономить место и начать отрисовку раньше, но на Индекс скорости загрузки и Блокировку до первого взаимодействия. В общем... Все каскадом, вся гибкость и фишка в труху из-за борьбы со смещением макета, дурь. Блин, ну прям лол. У меня в меню макет смещается в скрытом по умолчанию контейнере же для пользователя, ну в аккардионе все происходит.

Вот тебе и технология. Все сырое, все на глаз. Если даже их же AMP, одна из флагмоновских технологий и по факту самая быстрая проседает по всем параметрам. Дело в том что есть компоненты, которые по умолчанию фактически генерируют HTML уже в браузере. К примеру любой слайдер, это может быть большим куском HTML, который генерируется уже в браузере и вставляется в DOM... Так вот, для примера этот слайдер может иметь много элементов. Но генерироваться и просчитывать и отображать всего 1 элемент, далее как с тем же примером акардеона в скрытом от взора блоках идет рендеринг и прогрузка... а LCP дикая - от 3.7 почему она считается так я хз... то-есть если в слайдере 20 элементов, на обработку и вывод нужного нам первого уходит макс 1с, а LCP будет считаться пока не закончиться обработка всех 20 элементов.

И они еще говорят что из-за короны не запустили эти факторы в алгоритм? Да не будут они и в след году иметь значения. Технологии и методики оценки этих показателей сырые, не стандартизированные, так как это пипец же индивидуально, как не ошибиться и не занизить в выдаче невиновных? Все на глаз + пальцем в небо = Web Vitals

Не пойдут они на это, главное уже произошло - громкий анонс. В этом вся суть Американцев.

Тоже самое пару тройку лет и про скорость отдачи и про загрузки говорили. Блин, В 2014 точно помню уже были все стандарты приняты гуглом и описаны в рекомендациях по созданию и оптимизации страниц, типа - первый байт до 200мс, завершение отдачи макс 800мс, старт отрисовки не познее 1с, макс время на загрузку страницы 3с и т.д. и т.п... Ну и? Где этот фактор? так тут все проще было, все работало, оценивалось и мы на эти показатели теребонькали последнии 5 лет в PageSpeed Insights...

так что не заворачивайтесь, смотрите и делайте не для циферки в PageSpeed Insights, а для пользователя

---------- Добавлено 12.06.2020 в 23:46 ----------

Вопрос не в изобретении велосипеда, а в порядке применения стилей.

К примеру, у вас ботсрап css. Гребанная куча мусора у всех по 10 000кб. Пусть даже браузер взял его из кеша важно когда он его обрабатывать будет и сколько это займет по времени. Если он в header указан, то пока не обработает все стили он не начнет дальше все что ниже по html отрисовывать, что сказывается на времени загрузки видимой части и первого взаимодействия, не говоря уже что моб браузеры по ресурсам забиваются. Поэтому и header в тег <style> нужно поместить все что требуется для отрисовки видимой части экрана, а ссылку на остально css файл за </html> поставить и асинхнонка в header не поможет, так как как только файл css загрузился - чтение и отрисовка html на паузу встает, до завершения обработки css файла. Да и в этом случаи вообще правильно не засирать ограниченные ресурсы моб браузера и вычистить лишнее. Как правило с ботсрап используют 1/10 от того что грузят. А это просчет для каждой страницы лишний.

Потому в теле и лучше css в <style> вставлять, не используя файлы, так как если их вычистить и навести порядок на мобилах выигрываете значительно по времени.

Хм, когда год назад тестил у себя разницы не заметил между прямо из конфига nginx или с помощью preload.

Но вот что заметил - если с помощью preload то со второго раза отправленные server push js и css попадают в кеш браузера пользователя. А вот если из конфига nginx сразу отправлял то в кеш браузера пользователя не попадали js и css.

Ребят, а есть какой-нибудь сервис, который определяет, где именно на странице, или из-за чего, происходит смещение макета? Анализировал два сайта. Шаблон и csm одинаковые.. На одном реклама РСЯ на втором Адсенс. У первого смещение 0.14, у второго 0.38.. Первый выше в гугл.. Второй топ 1 в Яндекс. Зависимость? Может быть.. Вот сейчас хочу в этом убедиться и понизить смещение у второго сайта, без потери дохода конечно (рекламу снимать не будем).. Знаю, что многие писали, что это никак не влияет на выдачу.. Но всё же эксперимент имеет место быть.

Я юзал хром инструмент разработчика.

В общем чушь эта вся тема! В этом году серьезный проект запустили, по гуглу показывает загрузку всё в красной зоне. И что? Купили самый тематический жирняк в плане ссылок. Плевать на всю загрузку. В итоге с каждой недели трафф только растёт. Кароче полнейшая чушь все эти мерки / пипирки. Кстати в Яндексе так же не хило стал расти. Трафф 60/40. Где 60 - это Гугл.

---------- Добавлено 13.06.2020 в 00:47 ----------

На здесь почитай: https://vc.ru/seo/133544-uluchshenie-skorosti-zagruzki-sayta-chast-2-optimizaciya-css-i-javascript-faylov