Сертификат по Google AdWords

Сертификат по Google Analytics

Итак, три шага по оптимизации сайта для просмотра на мобильных.

1. Настраиваем область просмотра meta viewport

Самый первый и самый простой шаг — настроить область просмотра. Для этого в шаблон сайта надо добавить мета-тег meta viewport. Без дальнейших шагов, такое добавление мало чем поможет: в Google Webmaster Tools вместо одних ошибок начнут появляться другие, а при просмотре на мобильных сайт будет показываться с горизонтальным скроллингом.

2. Исправляем ширину контента под область просмотра

Простыми словами это означает сделать сайт резиновым, сайт должен «сжиматься» и нормально отображаться при ширине экрана в 320 пикселей. Самая сложная работа, потому что надо брать верстку шаблона, стили и менять пиксели на проценты и относительные единицы. Чем больше на сайте колонок и блоков, чем больше уровень вложенности каких-то div’ов, тем больше будет работы у вас или вашего верстальщика. Может оказаться, что проще поменять тему для вашей CMS на адаптированную для мобильных, а не переверстывать текущую тему.

Кстати, настоящая адаптивность с перестановкой и сворачиванием блоков не так важна, как «сворачиваемость» до 320 пикселей по ширине. Мне удалось существенно снизить ошибки для сайта с табличной версткой, я просто применил тот же метод — сделал таблицы сжимаемыми.

3. Размер шрифтов и активных элементов

Продолжение предыдущего пункта. Шрифты делаем относительными, используем em вместо px, если оставляем пиксели, ставим размер шрифта не менее 14 пикселей.

Что касается активных элементов, то есть кнопок, ссылок и полей форм, то Google рекомендует делать их размером не менее 48 пикселей и с расстоянием между ними не менее 32 пикселей. Инструкция от Google здесь. Мне не пришлось ничего специально делать по активным элементам, достаточно было относительных размеров блоков и шрифтов.

Итоги и замечания

В результате проведенных изменений я избавился от ошибок оптимизации блога для мобильных, тем самым обезопасив сайт от снижения позиций в результатах мобильного поиска. Итоговое время, затраченное на работу в случае с темой WordPress и статическими HTML-файлами — 3 часа. Правда темы именно WordPress легко делать резиновыми — две колонки, небольшой уровень вложенности, несложная структура блоков и CSS.

Да, повторюсь насчет инструментов: тестируйте изменения с помощью PageSpeed Insights, а не специальным инструментом Google, последний может показать «Ok», а в Google Webmaster Tools ошибки останутся.

Следующим шагом буду делать адаптивную тему, пока думаю как: с помощью библиотек или руками. Подписывайтесь, будет интересно!

Резиновый дизайн вместо фиксированного

Для исправления неправильной ширины контента надо из сайта с фиксированной шириной сделать сайт с резиновой шириной, то есть сделать сайта «сжимаемым». Сжиматься он должен вплоть до 300-320 пикселей по ширине.

Как это сделать? В теории достаточно просто, необходимо везде пиксели заменить на проценты для блоков и элементов, а для шрифтов пиксели заменить на относительные пункты (em вместо px). На практике это преобразование может быть катастрофически сложным и дл кого-то проще будет заменить тему на адаптивную, если речь идет о распространенных CMS вроде Joomla и WordPress.

Резиновый дизайн не обязательно должен заполнять все пространство на десктопах и ноутбуках, для этого в стилях есть параметр max-width, где пиксели будут уместны. Например, для этого блога внешний контейнер имел ширину 1000px и его стиль определялся так:

#page{
	width:1000px;
	margin:0px auto;
}

Переписываем этот стиль так:

#page{
	max-width:1000px;
	width:100%;
	margin:0px auto;
}

На больших экранах ничего не поменялось, а на маленьких блог должен сжиматься в 100% экрана, какой-бы она не была. Должен, но не будет, потому что внутренние блоки имеют фиксированные размеры и горизонтальный скроллинг на узких экранах никуда не денется. Ширину внутренних блоков необходимо также переводить в проценты, при этом помнить, что проценты надо считать относительно родительского блока. Например, ширина блога была 1000px, ширина основной колонки — 725px, ширина правой колонки (сайдбара) — 275px. Размер в процентах вычисляется по формуле:

Размер элемента в пикселях / Размер родительского элемента в пикселях * 100

В нашем случае размер основной колонки будет равен: 725/1000*100=72,5%
Размер правой колонки будет: 275/1000*100=27,5%
Если же в правой колонке у нас есть виджет размером 225 пикселей, то его размер необходимо уже считать относительно ширины правой колонки: 225/275*100=81,818182%

Аналогично рассчитываются размеры для margin и padding, их желательно тоже переводить в проценты. Но без фанатизма. Где-то можно оставлять отступы в 1-3 пикселя в пикселях.

Для того, чтобы картинки при сжатии экрана также масштабировались, надо добавить в стили для сайта следующий код:

img {
max-width:100%;
height:auto;
}

Относительный размер шрифтов

Размер шрифта переводится в пункты точно таким же образом. Базовый размер шрифта — 16 пикселей, т.е. один пункт по умолчанию равен 16 пикселям (1em=16px). Если нужен другой размер шрифта в пунктах, то он рассчитывается по формуле:
Размер шрифта / Размер шрифта родительского элемента (базового)
Для примера, размер шрифта 12 пикселей в пунктах будет:
12px / 16px = 0.75em

Кстати

Кстати, в случае Google инструмент инструменту рознь. Если проанонсированный мной ранее специальный инструмент для проверки «мобильности» говорит, что все нормально и горит зеленым, то Google Page Insights выдает ошибки. А Google Webmaster Tools ориентируется на Page Insights, судя по моим сайтам. В нем и надо проверять.

Сделать резиновый дизайн из фиксированного можно не только с версткой div’ами, но и при верстке таблицами, принцип тот же самый — переводим размеры из пикселей в проценты. Проверил — работает.

Я уже модифицировал несколько сайтов, жду переиндексации и результатов в Google Webmaster Tools, после этого опубликую примеры.

Осталось еще разобраться с расположением кнопок, ссылок в меню и некоторых других блоках, чтобы исправить ошибку «Интерактивные элементы расположены слишком близко». Об этом в следующий раз.

Подписывайтесь, лайки и шары приветствуются!

Пара ремарок

Во-первых. Ошибки по мобильной версии в Google Webmaster Tools после их исправления на сайте меняются по мере переиндексации страниц сайта, поэтому для работы и тестирования лучше использовать специальный инструмент Google, ошибки там соответствуют ошибкам в Google Webmaster Tools.

Во-вторых. Я выяснил, что Google не требует именно адаптивной версии, когда при уменьшении экрана блоки на сайте перестраиваются для более удобного просмотра. Достаточно реализации «резинового» дизайна и использования относительных шрифтов. Этими изменениями можно «закрыть» ошибки Google, чтобы сайта считался оптимизированным для мобильных.

Ошибки оптимизации для мобильных

Ошибки, которые указывает Google при оптимизации для мобильных:

1. Область просмотра не настроена
2. Область просмотра фиксированной ширины
3. Ширина контента не соответствует области просмотра
4. Маленький размер шрифта
5. Интерактивные компоненты расположены слишком близко
6. Использование Flash

Про последнюю ошибку ничего не буду говорить или делать по этому поводу. В моем случае Flash используется на паре страниц и скорее всего это вставки какой-нибудь презентации из SlideShare. Ошибки с размерами шрифтов и интерактивных элементов я разберу в следующем посте. Первые три ошибки касаются настроек области просмотра и с ней разберемся подробней.

Настройка области просмотра

Область просмотра настраивается с помощью специального тега meta viewport. Этот тег говорит мобильному браузеру, в каком разрешении пытаться показать сайт.

Если тега viewport на странице сайта нет, то браузер пытается показать сайт шириной 920 или 960 пикселей, то есть при физическом разрешении экрана 320 точек не способствует удобному просмотру. А Google выдает ошибку «Область просмотра не настроена».

Можно в теге прописать реальную ширину сайта, например так:

1

<meta name="viewport" content="width=980">

В этом случае браузер будет масштабировать сайт таким образом, чтобы отобразить его полностью по ширине. Это лучше, чем ничего, но оптимизацией для мобильных это назвать сложно и ошибка меняется на «Область просмотра фиксированной ширины». Данный блог в мобильном браузере будет выглядеть так:

Правильная запись этого тега в случае с Google такая:

1

<meta name="viewport" content="width=device-width, initial-scale=1.0">

Запись говорит мобильному браузеру, что необходимо отображать сайт с масштабированием 1:1 ориентируясь на реальное количество точек экрана. Данный блог в этом случае будет выглядеть так:

Поскольку дизайн сайта не резиновый, Google продолжает считать это ошибкой, но уже другого типа: «Ширина контента не соответствует области просмотра».

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

Сообщения все идентичные и выглядят так:

Если перейти в соответствующий раздел Google Webmater Tools (Поисковый трафик — удобство просмотра на мобильных устройствах), то можно будет увидеть всю глубину падения с десятками и сотнями ­«пострадавших» страниц сайта, на каждой странице как правило по несколько ошибок. Ужас!

На самом деле все не так страшно, как кажется на первый взгляд и поводов для паники никаких нет.

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

Во-вторых, оптимизация сайта для просмотра на мобильных еще не означает редизайн сайта, внедрение адаптивной верстки и прочих чудес. Хотя если есть желание, время и необходимые ресурсы, то можно и сделать такой редизайн.

В моем случае необходимость оптимизации сайтов для мобильных коснется как сверстанных «вручную» сайтов без CMS, так и сайтов на распространенных CMS вроде WordPress и Joomla, поэтому я начал вносить изменения в верстку и стили, о результатах этих работ и как они будут отражаться в Google Webmaster Tools и в поиске буду информировать.

Предыстория

Некий сайт лежал на сервере и работал. Сайт — информационный каталог, в Гугле на сегодня больше 2000 страниц. Реализован на Joomla с несколькими «тяжелыми» компонентами. В меру оптимизирован, но без фанатизма. Сервер был выделенным, но медленным. Серверная часть была оптимизирована, без фанатизма. «Узким горлышком» сервера был процессор, поэтому статика выдавалась достаточно быстро, а вот скрипты работали долго, что усугублялось тяжелыми компонентами Джумлы и большим количеством SQL-запросов, характерными для этой CMS.

Среднее время отклика страниц было больше 1 секунды, а по правде говоря приближалось к 2 секундам.

Смена хостинга

В октябре сайт перенесли на другой хостинг. Самый обычный виртуальный хостинг. Время отклика страниц сайта сократилось  в 2,5-3 раза, до вполне приемлемых 500-700 миллисекунд, что видно на картинке выше (время отклика сервера для главной страницы).

Кроме непосредственно переезда с сайтом в это время ничего не делали.

Индексация и SEO

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

Скрин из Google Webmaster Tools количества индексируемых страниц, индексируемого объема и времени отклика:

Как видно из графика Google, количество запросов к страницам сайта выросло в те же 3-4 раза, то еcть сайт стал быстрее и лучше индексироваться и переиндексироваться.

Позиции сайта в результатах поиска и CTR:

Хорошо видно, что позиции сайта в результатах поиска после переезда на более быстрый хостинг начали расти, как и CTR. Практически по всему списку запросов.

Трафик на сайте:

Тут и комментировать особо нечего, потому что трафик на сайте вырос где-то в два раза. Сезонности нет, с сайтом в это время ничего не делали, работал в штатном режиме.

Выводы

Данный кейс подтверждает явную зависимость индексации сайта и позиций в результатах поиска от скорости работы сайта. Чем быстрее работает сайт, тем лучше он индексируется и лучше у него позиции в поиске. Приемлемое время отклика для страницы должно быть меньше секунды, лучше ориентироваться на 0,5 секунды.

Быстрых вам сайтов и хороших позиций в поиске!

Лайки и шары приветствуются.

На конференции в Нью-Йорке представитель Google из команды Google Webmaster Central рассказал о двух сигналах, останавливающих робота:

1. увеличивающееся время отклика страниц сайта
2. появление 5xx ошибок

Если время отклика сайта все время увеличивается, страницы отдаются все медленнее, то сервер может быть перегружен и имеет смысл приостановить или совсем прекратить запрашивать URLы с сайта. Аналогично и с ошибками из категории 5xx — различные внутренние ошибки сервера, также возникающие иногда из-за высокой нагрузки на сервере или неправильной его конфигурации. Через некоторое время робот повторно запросит какие-то страницы и если ошибки исчезли, а время отклика приемлемые, то индексация сайта возобновится.

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

 Google Tag Manager

• Счетчики Google Analytics
• Коды ремаркетинга
• Коды AdSense
• События Аналитикса
• A/B тестирование

Чтобы не беспокоить вебмастера и программиста для установки всех этих кодов достаточно поставить один раз код Диспетчера тегов и затем делать все необходимые изменения через веб-интерфейс.

Здорово? Конечно! Но тут заканчивается лирика и начинается реальность:

• сначала нужно разобраться в самом Диспетчере тегов, который сделан отнюдь не для гумманитариев
• позже оказывается, что не все можно делать через веб-интерфейс, а кое-что все равно кодить и менять на сайте

Я прошел этап изучения и сейчас разбираюсь с нестандартными случаями, а пока несколько ссылок для изучения возможностей инструмента

1. Веб-аналитика с помощью Google Tag Manager — читаем в первую очередь, материал из серии «все в одном»
2. Как отслеживать уточненный показатель отказов с помощью диспетчера тегов Google — если мало стандартного показателя отказов, то можно отслеживать нестандартный
3. Отслеживание глубины прокрутки с использованием Google Tag Manager — это тоже из разряда «не для гумманитариев»
4. Как установить на сайт Google Tag Manager — инструкция как установить и запустить
5. Настройка отслеживания событий в Диспетчере Тегов — полезный материал об отслеживании кликов на страницах за счет преобразования их в события GA