Глупость какая. Сайдбар визуально и сайдбар в коде могут располагаться относительно контента совершенно по разному.
Уже техник управления потоком документа существует вагон. И через флоаты, и через отрицательные марджины, и флексбоксом и еще...
А значит на десктопе сайдбар слева, в коде - после контента, на мобиле со своей стилевой таблицей - после контента...
Ну вот откуда такие вопросы... ну хоть немного учите вебтехнологии, а не просто тупо качайте шаблоны... нельзя юзать отвертку, не зная, зачем она...---------- Добавлено 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
Разрабам
Делать сайты надо на том, на чем умеешь, что досконально знаешь.
Желательно не быть «морской свинкой» (программист Битрикс, программист Вордпресс - держите меня, это что, языки программирования такие???)
Клиенту-владельцу бизнеса
Делать надо на основании «минимум затрат к максимуму результата» (только как пропорция)
Если сео контора не смогла продаинуть сайт на ВП - значит там нет ни одного вменяемого php программиста, либо ни одного разбирающегося в технология проджекта с навыками минимального QA и в кворке их забанили.
Раз не нашли способа допилить сайт, если это конечно ДЕЙСТВИТЕЛЬНО было нужно, а не провал продвижения крылся в чем то другом. А платформа сошла за отмазу.
А значит в современных реалиях это не seo компания, а очередной разводняк.
Повторюсь, если есть нормальный знающий разработчик, дальше важна только технологическая база платформы (цмс, фреймворка), а не конкретное название. Остальное решается головой и гуглом. Если и там не забанили.
Вот я не знаю вообще Питон - за сайты на Джанго и не буду браться. Это логично.
Но и Битрикс с его логикой, помойкой в коде и файловой структуре и никому не нужными наворотами и сообществом, состоящим в основном из полуграмотных, но крайне самолюбивых граждан «программистов 1С» связываться не буду. Ни как разработчик, ни как сеошник, ни как проджект. Ну эту помойку нафиг.
postavkin, ну закрытие может и не помогает, соглашусь. Хотя и не всегда.
Но если в JS будет НОРМАЛЬНО сделанный скрипт - то есть не document.write и без влобовую прописанных url страниц, а они будут хотя бы собираться по частям - тогда все в порядке будет.
Из того, что Гугл "находит" путем "анализа" страниц - это по паттерну "похожие на url" подстроки из js, css, html сайта. Данные свежестью месяца два-три - в рамках текущего разрабатываемого проекта много раз наблюдал такие косяки индексации в аналитике. Пока интересно было и мы не пофиксили попадание такой фигни в аналитику.
Lighthouse и headless браузеры - это круто конечно, но жесть как ресурсоемко. Так что про полный рендеринг страниц ботом гугла можно не напрягаться.
