Будет или нет - не только от статьи завист, но и от домена на котором она размещена.
На прокаченном домене, качественном в глазах гугла - точно будет. И ссылочное не нужно на статью. Только вы не путайте типы запросов по которым она будет давать траф, по коммерческим врятли, не хватит мощи, так как там конкуренция выше. По информационным запросам - другой вопрос, особенно если тематика или запросы не имеют качественного контента в выдаче.
вы поймите, тут все относительно чего-то и кого-то, тут нет нет черного и белого, это было в далеком 2005м так...
тут не согласен, он дал отличный инструмент, целый фреймрок 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> вставлять, не используя файлы, так как если их вычистить и навести порядок на мобилах выигрываете значительно по времени.
Сейчас они и не участвуют в ранжировании, ни новые, ни старые. Только если старые в крайних случаях занижают позиции.
Вообще пузомерки нужные, ранжирования хоть и пролетает, но ПФ и конверсия напрямую от этих показателей зависит.
На LCP сильно заморачиваться не стоит, пока это еще не до конца отточенная методика определения загрузки контента и на некоторых сайтах лучше ориентироваться на рендеринг и скрины.
Тут еще возникает две маленьких проблемки... Что бы уменьшить LCP, приходится пожертвовать временем загрузки первого контента, из-за того что нужно прелоадить доп часть фалов. В моем случаи иначе ни как, AMP ну ни как я не могу оптимизировать)) Если свои файлы js или картинки, то выход простой есть, через ngшnx push прелоадим и все. Конечно можно заморочиться и сделать рендеринг amp на стороне сервера и пользователю отдавать просчитанный и построенный конечных html, но нагрузку уже на сервер дает нормальную. Пока замкнутый круг, но по итогу 90% удалось сделать.
А вот с CLS просто, нужно убрать моргание или смешение блоков в верстке за пределы видимой области. Обратите внимание, ругаться не только на изменение элементов html может, но так же на обычную картинку меняющую размер блока, к примеру не указана высота и т.д. Сложного ничего в это нет, возможно самым простым будет у кого css большой и в файлах, сделать предзагрузку стилей в html, как давно и советуют.
Смотри в вебмастере данные уже должны быть, так надежнее.
А вообще не понял, как у тебя переезд устроен? Через тег каноникл? Или ты говоришь про позиции до и после смены урл в выдаче?
Просто немного странно, если по стандарту 301 стоит то передача всех параметров должна произойти сразу и изменений особых не должно быть, если понизил старый, то и новому сразу же все передается. Либо не долетает то же ссылочное и позиции еще ниже будет.
Если закидываешь в индекс новый домен и клеишь канониклом, то какое-то время оба могут быть в топе и позиции будут отличаться по информативным запросам из-за статей, чисто ранжирование на качественном контенте, особенно если амп, разметки и т.д Хотя и будет по началу восприниматься не как первоисточник, новые реалии суровы.
Хотя даже если сразу 301 и позиции подросли, как я и говорил - не долетело ссылочное скорее всего, значит как долетит новый домен покатиться по топу стремительно в низ.
Ну и тогда, сообственно, уже четко будет понятно в чем проблема у тебя. Хотя, статьи во время склейки просто так не вырастают, думаю порезало тебя как раз из-за ссылочного.
ну для этого http://topvisor.com подойдет.
по сабжу - если нет конкретного вопроса с конкретными данными и проблемой, значит АХТУНГ.
как я понял, вы сами не поняли что у вас есть в топе, чего нет, под какие конкретно запросы оптимизирован текст и т.д. сколько ссылочного? какие анкоры? как давно стоит?
просто на уникальном тексте выехать захотели? яндекс с гуглом не сравнивайте ни в коем случаи, разная морфология русского языка + из этого вытекают различия по тошноте и как правило они противоположны и не применимые сразу для двоих, за исключением старых, хорошо вкаченных доменов.
че? трафик с директа влияеет на ПФ гугла? лол... пффф, сказать нечего🤪
Th? traffic on the FS Direct's vliyaeet google? lol ... pfff, say nechego🤪
Неа, они разные и их много. Варианта три - либо вручную список составляем работая с логами, но это не автоматический метод, постоянно нужно следить за актуальностью и с учетом "обширности" амазона и прочего - не реально. Либо работаем с https://www.nginx.com/resources/wiki/modules/rdns/ , но тут опять вопрос нагрузки на сервер и скорости отдачи документа, все-таки это отправка доп запроса на сторону. Ну либо не замачиваемся и ставим сайт за CloudFlare, с осени он хорошо таких ботов режет.
PS: есть еще один вариант, настроить проверку на ботов через js. Есть два способа - простенький, проверяет браузерное окружение http://webislife.ru/detektim-botov-na-javascript-v-brauzere/, либо сложнее - JS cookie challenge
Откуда инфа? Никогда такого не было. Проверил 4 домена - везде абсолютно разные IP, и 4ки и 6ки. Даже на поддоменах разные☝
по сабжу:
В клауде никогда на бесплатном акаунте не было привязки ip к домену или к акку или количеству самих ip . Так они говорят по мануалам. По факту так и есть, есть привязка IP к маршруту до сайта. Ситуация такая - ip может быть на акк много, как уже и говорил разные вплоть до поддоменов, ранее такой уникализации не было. Меняются редко, очень редко. Сейчас проверил на заблокированных доменах, в общем год продержались и 4ки и 6ки на 4х доменах.
Из разных geo точек будут разные IP, тут два момента влияют и тот что разные датацентры обслуживают и то как в самих датацентрах маршрутизация отлажена и то кто, как и откуда запрашивает контент.
У Вас IP меняется, почему? Потому что при разных запросах ваш провайдер можете по разному выстраивать маршрут к клауду. Как вариант через разных магистральных провайдеров, а того смотри по итогу из-за бугра стучится к клауду. Поизучайте трассировку, посмотрите через какие хабы запросы летят. Потрасируйте так же google, yandex(схема похожа, особенно у гугла, так как у Yandex есть свои фичи, все-таки местный парень) и разные сайты с clouflare и вы найдет много интересных маршрутов, а так же ряд уникальных, уже федеральных магистральных провайдеров.
Так же ip может сильно зависеть от вашего DNS сервера. Что за сервер? Яндекс, Гугл или провайдеровский? где он расположет и т.д....
Вот смотрите, я вам сказал, что проверил по записям из РКН ip и год они продержались, так? так вот, эти ip сохранились и отдаются по прежнему и РКН и Яндексу и мне, но это если я использую домашнего провайдера и не важно через какой DNS идет запрос - хоть с его местных хоть с Google DNS. А вот если я использую мобильную связь, то при DNS Google IP теже. В случаи DNS моб оператора уже нет - совершенно другой IP.
В общем, это нормально. Сайту ничего это не принесет - ни минусов, ни плюсов. Какие у Вас IP, NS-сервера, да те-же данные в whois - поисковикам не важны. И об этом неоднократно заявлял тот же Google. Да собственно это и логично. Единственное на что Google может обратить внимание - на владельца и содержимое домена в случаи если произойдет разделегирование домена и новая регистрация. И да.... бреет года два основательно "подобранные" и "подхваченные" домены((((
подскажите зачем тут map?
не супер эксперт в nginx, есть ли различия и какие если просто через if указать?
может кому нужен актуальный список, собирал сам около года.
обратите внимание на последнее $http_user_agent = "-" - очень много ботов вообще не подписывают юзер агент, такие тоже нужно "брить"
