Сегодня компания Google выпустила в свет новый алгоритм ранжирования веб-ресурсов Mobile Friendly. Что ждать от него? Попробуем разобраться:
О планируемых изменениях Google предупреждали заранее - всем пользователям инструмента Google Webmaster были отправлены соответствующие письма.
Для проверки сайтов на соответствие новым требованиям компания Google предлагает специальные тесты: "Проверка удобства просмотра на мобильных устройствах" и "PageSpeed Insights".
Все сайты, которые в результате проверки по первому тесту получат результат "не оптимизировано для мобильных устройств", с очень высокой долей вероятности значительно потеряют свои позиции в результатах поисковой выдачи Google.
То же самое касается и второго теста, только в нем желательно добиться нахождения в "зеленой зоне" по всем параметрам, проверяемым для конкретного сайта.
Примеры для первого теста:
Коллеги, данное нововведение коснется абсолютно всех сайтов, в том числе выполненных и на CMS "1С-Битрикс". Со своей стороны мы уже внесли в продукт несколько улучшений: в SEO модуле вышли рекомендованные настройки robots.txt, а также в главном модуле вышли минифицированные все CSS и JS. Все они доступны для установки в административной части сайта, при условии, что лицензия сайта активна (сайт получает обновления).
Что вы можете сделать уже СЕЙЧАС для ваших сайтов, выполненных на платформе "1С-Битрикс":
1) Протестировать сайт двумя предложенными инструментами от Google
2) Установить обновления главного модуля в административной части вашего сайта
3) Выполнить рекомендации в файле robots.txt
В свою очередь, мы готовим подробную статью с пошаговой инструкцией - как можно еще лучше подготовить ваш сайт и сайты ваших клиентов под соответствие новым требованиям от Google.
Ожидайте подробную статью в самое ближайшее время.
.
А что на счет параметров defer, async для CSS, JS файлов?
Пример -
Пример -
Как бы тут нечем хвастаться. зеленая плашка это прелестно но сайт нежизнеспособен по снимкам. Либо вместо сайта меню, либо полное отсутствие графики и стилей.
Цель данного поста не похвастаться, а информировать о грядущих проблемах, и донести мысль, что в продукте тоже сделаны изменения которые помогут улучшить сайт и соответствовать новым требованиям (веяниям).
Вставлять же в статью один из своих проектов, на котором все чуть лучше, я посчитал не полит корректным. Мы соревнуемся с ребятами Антона, кто сделает больше пунктов, пока я вел, но у них есть больше шансов победить, их просто больше, и для меня это не основная задача.
А здесь еще чуть лучше:
В комментариях приветствуются ссылки на ваши тесты, будем вместе стараться сделать хорошо. Мы за счет продукта, вы советами.
.
Про метод который описан в блоге знаю. Планируется ли дать возможность управлять подключением скриптов и стилей разработчикам ?
Хотя по сути контент и его оптимизация не совсем в ведение нас как разработчиков платформы. Но и это мы готовы стараться решить, за владельцев сайтов, так как они этого могут не понимать и не делать не чего в этом плане.
Но заставить не грузить картинку на 5 мегабайт в разрешение 3000 на 3000 пикселей, где достаточно 300 на 300 мы не можем.
Мы не знаем какая картинка требуется в какой момент, об этом должен позаботится сам владелец, хотя в какой та мере мы постараемся и это решить, показав новый интересный контрол загрузки картинок в инфоблоке, дождитесь нового релиза Управления Сайтом.
Это целостный тест и рассматривать его нужно не как конкретные сообщения, а как изменение в общей картине, ведь нужно добиться хотя бы 85-86 пунктов и это будет зеленая зона.
до
после
Но если вы уверены, что это не повлечет за собой проблемы, вы и сейчас сможете добавить такой параметр через:
AddHeadString
Но в нем есть один минус, не работает наше сжатие с ним и параметрами которые можно передать. Но если вы не используете наше сжатие, то вполне можно.
Юрий, мы как раз переделали свой сайт (который на Битриксе ) , в том числе под требования гугла
мы (а конкретно мой коллега Алексей Шкарупа) с удовольствием поучаствовали бы в дискуссии на эту тему, особенно если бы она началась не после, за несколько месяцев до выхода нового алгоритма
в частности, темой правильного склеивания скриптов и css мы мучаем вас давно и не очень успешно
После установки все хорошо, файлы ужатые, спасибо.
<sc ript type="text/javascript">BX.setCSSList(['/bitrix/js/main/core/css/core.css?14296402352854']) ; </sc ript>
Из всего что проверяет PageSpeed Insights в битриксе НЕВОЗМОЖНО (силами разработчика) реализовать только 2 вещи.
Первая и наиболее критичная - перемещение скриптов в подвал. Самое странное, что разработчики с фанатичностью отказывают нам в таком API. Так что я просто оставлю это здесь
Вторая - не столь критичная, но она была бы как вишенка на торте - минификация js/css. Да, я слышал что теперь скрипты главного модуля будут минифицированы, но это не то. А "самое то" было бы если бы при объединении css/js минифицировались объединенные файлы.
Но за скрипты в футере - это действительно сложно, если это магазин, и битрикс никак помочь не хочет....
Важно, чтобы сайт хорошо отображался на мобильном телефоне? конечно важно, но не об этом речь. На мой взгляд маленькие разрешения 240x320, 320х480 постепенно уходят из обращения. Появляется все больше устройств с шириной >800. Ну хотя бы можно зайти сюда:
и посмотреть количество продаваемых смартфонов и их разрешения экрана. Получается, что в относительно небольшом будущем уже не будет смысла в адаптивной вёрстке, так как экран мобильника будет как экран десктопа и будет начинаться от 1024. Тогда адаптивная вёрстка уйдёт в прошлое? Получается, что адаптивная вёрстка это технология на несколько лет, пока с рынка не уйдут маленькие разрешения. Понятно, что будут всякие i-watch, но вряд ли кто-то будет выходить с них в сеть, когда есть мобила в кармане.
По статистике сайтов по Яндекс-метрики увидел рост заходов с 320 и 360 разрешениями.
В 2013/2014 разрешений 320 было 8.5%, в 2014/2015 стало 14.5%
В 2013/2014 разрешений 360 было 0%, в 2014/2015 стало 6%
Я считаю, что это временный рост маленьких разрешений, потом будет стагнация.
Какое ваше мнение?
То что растет разрешение это конечно хорошо, но размер физического экрана больше 5,5-6 не будет, или это уже не телефон, а планшет.
Соответственно как верно ниже сказал Алексей Уколов, адаптивная верстка это не только размер экрана, это и поведение пользователя, и схема нажатий (мышка, палец), это и скрытие или показ различных блоков, в разной последовательности, в зависимости от типа устройства.
Например на мобильном устройстве, может быть не нужен баннер, или хлебные крошки, и их нужно будет скрыть, а на планшете - удобней окажется сйтбар внизу, а не справа или слева.
Партнёры сами могут это сделать.
Вы же не требуете чтобы битрикс вас снабжал всеми кратинками, а обращаетесь к дизайнеру.
Я честно говоря не вижу проблем в реализации этой задачи для каждого конкретного проекта.
Судя по комментариям очень давно.
У нас давно уже есть куча адаптированных компонентов, и меню, и каталожные компоненты.
В новом релизе мы сделаем облегченную схему создания шаблонов страниц, и их сетки. Добавятся обновленные хлебные крошки с новым дефолтным компонентом, компоненты новостей, баннеров.
Что даст облегчение в создание шаблонов и сайтов.
В моем примере я например использую все дефолтные компоненты, не модифицированные.
К счастью типовыми ШАБЛОНАМИ не приходится пользоваться (дефолтные шаблоны компонентов как раз-таки очень люблю, а вот ваше "решение" недолюбливаю за громоздкость). А то оказывается компоненты для инфоблоков - это тоже не рабочие решения, а "примеры работы АПИ".
В общем, не вижу причин почему вы должны сделать нормальный шаблон (раз уж всё равно не умеете).
8)
В новом релизе мы сделаем облегченную схему создания шаблонов страниц, и их сетки. Добавятся обновленные хлебные крошки с новым дефолтным компонентом, компоненты новостей, баннеров.
Что даст облегчение в создание шаблонов и сайтов.
Битрикс - это CMS, платформа, а не готовый идеальный сайт. Исправьте давно известные проблемы и это даст куда больше для SEO и скорости сайта, а уж красивую вёрстку и адаптивность сами как-нибудь натянем. Всё равно сейчас для каждого сайта приходится полностью перевёрстывать шаблоны всех компонентов, чтобы избавиться от 100500 уровней вложенности DOM, лапши стилей, убрать явно лишнее (в рамках конкретного проекта) и т.д.
Из того, что сейчас вспоминается:
- Кривое многоуровневое ЧПУ в каталожных компонентах, из-за чего страница имеет более одного адреса, а это большой касяк для SEO. Кроме того, такое ЧПУ не работает/работает криво для простых каталожных компонентов
- Непонятно как криво работающее 404 в комплексных каталожных и новостных компонентах
- Невозможность гибко управлять подключением стилей и скриптов
- Неправильное автоназвание файлов анонсных и детальных картинок элементов инфоблоков по SEO-шаблонам
- Изобилие и большой вес подключаемых и инлайн системных стилей и скриптов
- Невозможность вмешаться в создание карты сайта (отсутствуют необходимые события)
- Избыточная сложность и недостаточный функционал вебформ, голосований и форумов.
- Откровенные ляпы в коде, снижающие быстродействие.
Отдельно отмечу необходимость тестирования и CI в целом для каждого апдейта, чтобы не было фейлов, когда в бету и даже релиз выходит нечто, ломающее сайт.Всё это многократно обсуждалось на форумах, писалось в ТП, но в половине случаев ответ "Ошибкой не является, исправлять не будем", а в другой половине - "Отправлено в разработку, когда сделаем не скажем, т.к. сами не знаем". Я прекрасно понимаю, что работы здесь не на один день и даже не на неделю, ну так и 1С-Битрикс не кучка студентов.
Однако исправив эти ошибки и реализовав недостающий функционал, можно получит гораздо больше плюсов от Гугла/Яндекса и благодарностей от посетителей сайтов и, соответственно, больше продаж продукта, нежели от пресловутого адаптивного меню и хлебных крошек с семантикой (это и так сами всё делаем).
рекомендую создать несколько отдельных постов в
Притом в ветках форума просите участников голосовать за идеи... Не скажу, что это отработает на 100% и ваши идеи будут внедрены. Мои идеи например еще не внедрили
Часть таких проблем закрывается локальными решениями на уровне шаблонов компонентов или полностью своих компонентов, либо строятся обходные пути. В редких случаях просто приходится говорить клиенту, что Битрикс так не умеет, либо умеет, но будет тормозить, либо переделка будет дорого стоить.
P.S. Лично моё мнение касаемо "Идей" - это раздел для отвода глаз и имитации деятельности. Вроде как "мы вам дали песочницу, вот и играйте в ней, т.е. пишите в неё". До неё были и есть форумы, в т.ч. закрытые партнёрские, группы разработчиков, но ситуация не меняется.
Ok, вот некоторые идеи (не мои):
Публичный багтрекер ноябрь 2012 года, Создание баг-листа декабрь 2013 года и Сделать bugtracker открытым май 2013 годаПачка просьб исправлять ошибки вместо гонки релизов. Особенно доставляет фраза Вадима Думбравану "Мы меняем наш подход, я докладывал об этом на партнерке. Надеюсь, в ближайшее будущее проблема ошибок исчерпает себя." от 30.01.2012.
ВотСайт идей отлично работает и идеи в нем выполняются, и закрываются, что видно по статистике.
Но сайт идей не говорит о том, что все идеи на нем будут выполнены. Естественно всегда останется куча идей до которых не когда не дойдет, они или не отражают текущие потребности, или не являются приоритетными. Не все, что лично вы считаете приоритетной проблемой - может поступить в работу у нас.
Каждая идея должна быть обособлена. Конкретно в вашей есть кусочек про лабораторию, ее и закрыли как раз, для перезапуска с улучшениями, которые высказаны в вашей идеи, и в скором времени она опять войдет в строй. Но как мне закрыть идею после ее завершения? Да не как, так как в ней десяток идей, и все они в купе не будут выполнены с очень высокой долей вероятности.
Верно говорит Алексей выше, каждая идея должна быть в отдельной идеи, все идеи просматриваются моим отделом, по интересным или идеям которые готовятся уйти в работу я всегда оставляю комментарии, а в некоторых случаях начинается бурное обсуждение.
В 14.х версии упор в основном делался на компонентах. Шаблон лично по мне не очень удачен, есть очень большие сложности с сеткой. В новом релизе мы выпустим, удобный шаблон с удобной сеткой, который будет знаком многим разработчикам. Это будет попытка не изобретать велосипед, а показать как легко можно использовать современные решения в продукте.
Дальше лень что-то делать. Надо css впихнуть в тело страницы, а эти файлы вниз убрать, а так же убрать Яндекс.Метрику и картинки сжать до размеров мобильника, сэкономив 5КБ (не вижу смысла, т.к. большая часть пользователей тогда проиграет в качестве). Уже пол года такая картина. Рецепт прост:
1) Отключаем композит (для особых мазахистов разместить свой js для композита внизу страницы)
2) Отключаем все скрипты Битрикса, заменяя попутно на собственные (благо админские трогать не надо, пользователи и поисковики их всё равно не видят). Мне пришлось переписать скрипт продления сессий. Остальное не понадобилось из стандартного.
3) Делаем всё остальное, как рекомендует Google.
Достаточно было простенькой проверки и скрытия баннера на главной. И мелких улучшений вышедших в продукте.
Но я как и вы согласен, что дальнейшее улучшение излишне, у вас прекрасный результат, и я не думаю, что ваш сайт, также как и мой попадет под писимизацию.
Хотя моему повезло больше он демонстративно попадал на две недели, Гугл выбрал его среди 6 моих проектов, за объем мобильного трафика и для примера пессимизировал. Сайт вернулся из пессимизации, но позиции пока восстанавливает вяло, трафик просел почти на 40%.
И вот что я скажу. Когда я добился всё-таки 100% результата в расширении. то в сервисе показывался результат около 70. Я улучшил результат в сервисе до 79, а в расширении от тех же действий он упал со 100%.
В итоге увидел, что в расширении и сервисе есть противоречивые пункты. Удивительно, что Гугл рекомендует проверять и в одном и в другом случае.
После этого забил на оптимизацию
Как сейчас дела - не в курсе. Может всё и наладилось. Но 70% или зелёная плашка вполне устраивает. Дальше смысла нет улучшать. Разве что ради спортивного интереса.
здесь Гугл лукавит. Он проверяет исключительно поведенческие пользователей (накопленные). Если юзерам нравится сидеть на сайте с мобилок - он говорит что все хорошо. Проверил на своих популярных и на своем d-it.ru - последний дал печальку. Хотя сделан более просто и качественно (за счет простоты).
У меня гугл говорит, что все ок
Количество проблемных страниц я тоже вижу. И в разделе Удобство просмотра на мобильных устройствах в таблице есть колонка "Время последнего обнаружения". Самые свежие даты там недельной давности. А неделю назад указанные страницы точно были оптимизированы (и в гугловской сохраненке лежат правильные копии). Так что пока у них не все отлажено.
Ничего на стал предпринимать, просто подождал пару недель. Прошла очередная проверка, после которой изменилась строка "Статус на 02.05.15". Причем по отдельным страницам даты проверки самые разные. Т.е. имеет значение только сам факт общей переоценки сайта, а не дата последней проверки страниц.
На текущий момент страниц с ошибками показывает 4. Эти страницы не были переиндексированы на момент общей переоценки сайта (2 мая) и имеют очень старую дату индексации.
В общем, все, как писал Юрий. Просто 2 -3 недели подождать нужно и все появится.
P.S. На позиции пока не повлияло))
Я для тестов оставил один проект не проходящий по тестам (он не адаптивный и Гугл на него жалуется в вебмастере).
Проект индексируется стабильно раз в три дня, достаточно посещаемый. И пока тоже не повлияло на уменьшение доли трафика, на выходных трафик даже подрос, но это специфика тематики.
Посмотрим, что будет дальше, провалится сменю шаблон, все подготовлено ждет
Мне в этом всем не нравится одно - Гугл смотрит просто на ПФ, а преподносит все под маркой "мы крутые ребята, видим как у вас все плохо". Тьфу, дешевка какая-то. Не ожидал от них.
Выпаду с топа гугла - буду плакать и переделывать
С sp-fan.ru конечно, умора. Я думаю, там фишка в том, что все файлы стилей заблокированы в роботсе (Disallow: /bitrix/) и гуглобот всерьез считает, что сайт отображается вот так
А вот на d-it.ru вьюпорта нет и робот определяет ширину как получится. Например, видит широкую картику в тексте и думает, что тут не меньше 780 пикселей в ширину. Ну и видит, что пальцем в такую ссылку не попадешь
PS. Чтобы робот все видел корректно, смотрим, как сделан роботс у битрикса
Allow: /bitrix/cache/
Allow: /bitrix/js/
Allow: /bitrix/templates/
Allow: /bitrix/panel/
Allow: /bitrix/cache/
Allow: /bitrix/js/
Allow: /bitrix/templates/
Allow: /bitrix/panel/
надо будет заняться.
Необходимо сделать всего две вещи:
1. Добавить в код мета-тег viewport.
В этом случае вам решать, кто для вас авторитетней.
Понятно, что гугл не настолько глуп, но всё равно на первое время возможно реально поможет обмануть гуглоробот. А вот дальше уже пойдут в ход поведенческие факторы. Вдруг у меня сайт специально без css и js. Главное, что всё пользовательское работает и пользователям удобно. По сути гугл ещё не умеет смотреть на сайты с эстетической точки зрения, и это было бы не правильно. А тут как раз всё нормально - адаптивность, вес страницы, js внизу (точнее отсутствует). "У меня сайт такой белый и на стандартных стилях! Что ты ко мне привязался, Гугл!!". Кроме как от пользователей и асессоров пока никак не узнать, хороший сайт или нет в плане дизайна.
Но недельки через 2 гугл пойдёт по просторам выискивать такие сайты, если уже не пошёл
Allow: /bitrix/cache/
Allow: /bitrix/js/
Allow: /bitrix/templates/
Allow: /bitrix/panel/
Наше адаптивное решение в маркетплейс полностью соответствует требованиям
а до добавления этих правил google писал что не соответствует требованиям