Это не боты. Это поиск по картинкам, в котором при уточняющих кликах к запросу автоматом плюсуется альт-текст, и эти запросы попадают в статистику.
Недавно общал саппорт Директа, сознались, сказали, что разработчики уже работают над переделкой схемы уточняющего поиска.
Апплодисменты, самореализовался. Дальше первых строк поста не осилил? Да, дату не посмотрел. Но по сути написал. А Вы?
Глупость какая. Сайдбар визуально и сайдбар в коде могут располагаться относительно контента совершенно по разному.
Уже техник управления потоком документа существует вагон. И через флоаты, и через отрицательные марджины, и флексбоксом и еще...
А значит на десктопе сайдбар слева, в коде - после контента, на мобиле со своей стилевой таблицей - после контента...
Ну вот откуда такие вопросы... ну хоть немного учите вебтехнологии, а не просто тупо качайте шаблоны... нельзя юзать отвертку, не зная, зачем она...---------- Добавлено 26.01.2019 в 12:20 ----------По вопросу ТС
Думается, для инфосайтов сб должен быть условно под рабочую руку пользователя (правше - справа), без учета право-левостороннести письма (арабам и арамеям - все зеркально).
Потому что проще в голове, при поиске инфо навигация должна быть «под рукой»
При инструментальном интерфейсе сервиса, фильтры в каталогах - как минимум для правши слева, потому что тут работает паттерн операционной системы, что в Винде, что в Макос навигационный сайдбар традиционно слева.
Ranksense.com
keywordtool.io
Ubersuggest.io
При этом еще изменив ее размеры с 5000 на 5000 пикселей до приемлемых на экране десктопа ~1920 на 1920 максимум (а для теста пейджспида вообще до 1300 по моему) и до мобильных ~400 на 400
Ок, для ретины - все размеры в 2 раза больше (но через srcset и Гуглу не показывать)
Скорость загрузки - конечно не ключевой фактор. На старте проекта. Естественно.
Но! В случае прочих равных, она может влиять:
- со стороны сервера - на расход краулингового бюджета спайдером
- со стороны клиента + SERP факторов - на поведенческие (даже если сайт что-то вывел, но не дает пользоваться, потому что фронт тупит - посетитель свалил). А это dwell time - и вуаля, сайт тихонько тонет.
Потому при застывших топах с вылизанным контентом, обросшим ссылками, этот фактор является еще одним для ранжирования. Только и только в совокупности с остальными.
С новым PageSpeed Insights все предельно ясно.
Концепция сейчас какая? Правильно, Mobile First Index. Потому они и стресс-тестят сайты на эмуляции крайне слабой связи и на базе не самого нового смартфона.
И тут давайте по честному: топовые смартфоны у меньшинства. Связь тоже не айс в подавляющем большинстве случаем ВО ВСЕМ МИРЕ (а Гугл - глобальная система, не Москва и не Нью-Йорк, помним об этом).
Конечно, смешно, что качество связи, используемое в тесте, рассчитано на жителей лесных районов Танзании, пользующих смарты не моложе Nexus 5 (для эмуляции в DevTools Хрома в закладке Network выставьте качество связи Slow 3G и потом в Audits запустите тест Perfomance - почти оно). Но это реальность, как средняя температура по больнице.
Далее, что смотрит Гугл.
А смотрит он не СКОРОСТЬ ЗАГРУЗКИ файлов, как было совсем недавно, для этого есть теперь всего один производный показатель - Speed Index, и то косвенно связанный, так как отражает только полноту отрисованности картинки на экране (смотрим скриншоты в их отчете, все встает на свои места).
Важна СКОРОСТЬ ВЫХОДА вашего сайта В РАБОЧИЙ РЕЖИМ. То есть когда он полностью отрисован и все критичные для его функционирования элементы загружены и инициированы. И посетитель может уже с ним взаимодействовать.
А это нынче JS. Он не только грузится, он еще парсится и инициируется JS-движком браузера, на это часто времени уходит больше, чем на загрузку, в разы. О чем в отчетах (Диагностика) много, читайте.
Картинки тяжелые также занимают время основного потока. На их загрузку и растеризацию-отрисовку с ресайзами движком и т.п. тяжелыми операциями.
Сторонние виджеты (Facebook c 3...6 Мб загружаемого JS для вывода кнопки лайков - этожужас!) тоже сильно грузят. Опять же, тратится время как на выкачивание (да еще и с неэффективным сжатием и временем кеширования), так и на интерпретацию и исполнение JS движком.
Итого - выводите весь этот хлам из основного потока разбора и построения страницы.
В идеале по собственными сайтовым скриптам - не грузить разом все JS библиотеки и скрипты (тем более комбайненные в один файл), а для каждой страницы подгружать только тот набор функций, которые нужны ТОЛЬКО ДЛЯ ДАННОЙ СТРАНИЦЫ. То же самое относится и к CSS, хотя и менее критично, тут достаточно грузить необходимое для отрисовки страницы сразу в head, остальное догружать асинхронно с кешированием в догонку (и потом на остальных страницах ничего вообще грузиться не будет, из кеша по 304 возьмется).
Тут очень помогла бы модульная структура EcmaScript6, с генерацией конечного кода под конкретную страницу по правилам. Но таких решений из коробки для популярных CMS тупо нет, плагины тоже под это никто в своем уме не адаптирует, поддержка нативная браузерами хромает. В общем все сложно.
Да и на виртуальном хостинге без доступа к ОС мало чего понастроишь.
А ведь нужно еще реализовать server push и включить ssl/https + http/2 для оптимизации потоков отдачи контента браузеру. Все это существенно распараллеливает и ускоряет загрузку => браузер может быстрее перейти к разбору нагруженного в него. И выгода от HTTPS здесь не в пресловутой безопасности, а именно в работающем под ним HTTP/2.
Мысли о CDN упираются в тот факт, что все более-менее навороченные функции оптимизации начинаются от "очень дорого" на том же CloudFlare. И Rocket, и оптимизация картинок, и Server push, и прочие полезные навороты - от 200 у.е. в месяц + набегающим итогом поработное - большинство наворотов идет вне пакета, а на основе расхода ресурсов. И так на всех CDN.
И да, для CDN первична отдача контента по геопризнаку, остальные вопросы - это косвенные проекты, реализованы они зачастую весьма спорно и сомнительно. Геораздача - да. Секьюрность - ну... тоже да.
А вот скорость работы сайта... Много громких слов в описаниях, но когда дело доходит до тестирования рализации, выглядит все весьма не радужно. Оптимизация самого сайта - это не зона работы CDN. Точка.
Все эти описанные выше манипуляции существенно разгрузят парсинговый движек браузера и выход на отрисовку и интерактивность будет максимально быстрым. А значит и bounce rate сократится! Счастливый посетитель. И вот про эту единственную цель и сделаны все эти сервисы Гугла и все эти оценки. Прямая зависимость отказов от технической оптимизации сайта. Отказы по причине убогого контента - вне зоны рассмотрения, но улучшение dwell time чисто за счет получившего быстро целевой сайт посетителя - это уже СЕРПовый сигнал. С логичными дальнейшими последствиями для сайта.
Более менее универсальных проектов именно по оптимизации быстродействия сайта в сети можно перечесть по пальцам.
Я не говорю о узкоспециализированных плагинах к конкретным CMS типа W3TC для WP или аналогах. Их много разной степени навороченности и вредоносности для оптимизируемых сайтов :) Реализованных как в виде локальных плагинов с использованием возможно установленных на хостинге консольных утилит, так и в виде гейтов к онлайн-сервисам оптимизации (как PegaSaas). Но - они НЕ универсальны и опять же требуют дополнительного функционала типа того же CDN для распределенного хранения по геопризнаку или параллелизации загрузки с разных хостов. И еще наличия определенных установленных консольных утилит оптимизации на хостинге, что далеко не всегда есть.
Все выше сказанное написано для тех, кто готов самостоятельно либо с привлечением специалистов ввязаться в процесс технической оптимизации своих сайтов. Процесс реально не простой и много итерационный. Иногда требующий полностью переписать часть функционала сайта. Зная любовь всех к готовым решениям - это уже само по себе проблема :)
Теперь немного "рекламы" готовых решений :)
Стартап, в котором я принимаю участие, как раз работает над созданием подобной описанному выше универсальной системы оптимизации сайтов.
На данный момент реализован именно блок повышения производительности сайтов (хотя в планах автоматизация еще множества других аспектов реализации сайтов - структуры, кода, перелинковки, ЧПУ, семантической разметки и т.д.)
На тестовой выборке в полторы сотни сайтов, выполненных на разных движках, фреймворках, с разными наборами расширяющего функционала, размещенных на разных, зачастую весьма убогих хостингах - реальный прирост производительности на порядки. Вывод в зеленую зону оценок PageSpeed в 90% случаев, в первую очередь акцент на мобильных версиях.
Готовы предоставить доступ для тестирования системы представителям студий, работающих на Запад и имеющих достаточно большой пул клиентов, для которых очевидна необходимость технического импрува, либо частных вебмастеров с большим количеством сайтов в Бурж. Для агентств есть возможность white label сервиса.
Для небольших индивидуальных проектов ПОКА, увы, сервис предоставлять НЕ ГОТОВЫ, не стоит и беспокоиться. Массовый сервис и поддержку мы еще не готовы оказывать.
Дорвееводов тоже просьба пока :) не суетиться, врядли дружба выйдет плодотворной.
Всех интересующихся приглашаю в личку с примерами Ваших сайтов.
Активно проталкивают WebP и AMP - свое, родное.
Редирект должен быть 301, а не 302
