В сети всё ещё очень много сайтов, которые когда-то делались без учёта адаптивности. Они разрабатывались под отображение на стационарных мониторах, под какую-то распространённую на момент разработки ширину экранов — 1024 или 1280 пкс. И при открытии таких сайтов с мобильных устройств сайты отображаются плохо — страницы не влезают и их приходится прокручивать или вообще части дизайна накладываются друг на друга. Если владелец сайта хочет его осовременить, но полноценный редизайн и разработка новой версии сайта не укладываются в бюджет, то можно попробовать сделать старый сайт адаптивным.
Я могу рассмотреть несколько вариантов решения этой задачи:
- Сделать адаптивным HTML сайта
- Сделать отдельную мобильную версию для сайта
- Обновить не только дизайн, но и сам сайт используя готовое решение
Рассмотрю все эти варианты, не углубляясь в конкретные приёмы HTML-вёрстки или другие технологические решения.
Вариант первый. Оставляем старый сайт, но меняем его вёрстку и корректируем дизайн для того чтобы сайт стал адаптивным.
Трудозатраты на то чтобы сделать сайт адаптивным будет сильно разниться в зависимости от многих нюансов.
Для начала нужно определиться с целью создания адаптивных версий страниц. Если речь идёт о прохождении тестов Google (и плюсах в плане продвижения в поисковиках), то нужно понять на сколько надо приблизиться к идеалу. Есть мнение, что для гугла не имеет значения сколько на сайте ошибок — 1000 или 100, если сайт не в «зелёной» зоне, то остальные оптимизации не имеют значения для гугла и он не даёт сайту каких-то бонусов в результате поиска. Это определит степень проработки. Например, в простом варианте мы можем оперировать целыми блоками, но не их содержимым. А гугл будет проверять и содержимое — видеть близко расположенные ссылки, мелкие шрифты, устаревшие плагины и т.д. И нам потребуется менять и всё это. Т.е. просто проводить тест, вычленять задачу, решать её, исправлять все связанные с ней возникшие проблемы. А это многократно увеличивает сложность работы. Вплоть до того, что может быть аналогично по затратам проектированию и отрисовке нового дизайна, его вёрстке и наложению новой верстки на программные компоненты системы управления сайтом (близко к тому что сделать новый сайт). Особенно это критично если текущий дизайн воспринимается как устаревший и его планируется менять в обозримом будущем — в таком случае просто не выгодно тратить ресурсы и лучше сразу делать новый сайт.
Если оптимизация запланирована больше для удобства людей, чем для поисковиков, то нужно посмотреть статистику и попробовать понять на сколько это вообще критично и востребовано. Многие смартфоны корректно показывают сайт, а людей не раздражает необходимость увеличивать масштаб. Вполне возможно, что адаптивить текущую версию сайта и не нужно будет. Или же можно ограничиться тестированием и ситуационным исправлением багов — например, у вас кнопочки изменения числа товаров в корзине или другие элементы интерфейса на смартфонах не работают.
Если после все этого решение оптимизировать сайт под мобильные устройства будет всё ещё в силе, то нужно будет определиться с разрешениями, под которые мы будем тестировать отображение сайта помимо текущего основного десктопного, под которое заточена текущая старая версия сайта. Например, это могут быть: 480*800, 640*960 и 768*1280. Решение лучше принимать исходя из текущей статистики заходов (отчёт «Разрешение дисплея» в Яндекс.Метрике или «Аудитория -> Мобильные устройства -> Устройства -> Разрешения» в Google Analyticts). По разрешениям вопрос важен тем, что с ростом их числа обычно пропорционально увеличиваются и трудозатраты. Поэтому имеет смысл взвесить какие именно нужны. Особенно интересует минимальное разрешение, которое нужно учитывать. Как правило, это ширина 320 пкс.
После определения целей и задач мы можем действовать примерно по такому плану:
- Согласовываем вариант поведения всех блоков на страницах при адаптивности. Это могут быть варианты разной сложности.
- Делаем макеты адаптивных вариантов страниц разной степени проработки для того чтобы наглядно представить результат. Это могут быть прототипы, могут быть макеты. Просто чтобы можно было визуализировать как-то изменения.
- Создаём временную копию сайта для выполнения на ней изменений.
- Корректируем вёрстку на временной площадке и итеративно согласовываем и правим до получения приемлемого результата.
- Переносим обратно на боевой сайт.
Как правило, предварительная оценка всех трудозатрат по таким работам затруднительна. По своему опыту — для обычного сайта с 10 шаблонами уникальных страниц это от 50 часов трудозатрат для клиента. Верхнюю границу сказать трудно — зависит от дизайна и текущей верстки сайта, для которого мы делаем адаптивный HTML.
Вариант второй. Делаем отдельную версию сайта под мобильные устройства.
При этом подходе старый сайт остаётся без изменений, а просто делается отдельная версия специально под мобильные устройства. Это может быть та же база сайта, но с отдельной «витриной» публичной части. Т.е. делается определение мобильного устройства и если на сайт пытается зайти посетитель с такого устройства, то посетителя перекидывает на отдельный сайт. Как правило, мобильный сайт выносят на отдельный домен вида m.site.ru. Нужно понимать, что даже если используется одна база, одна административная часть, то всё равно возникают существенные трудозатраты на новый внешний вид. Т.е. фактически нужно спроектировать, нарисовать, и сверстать новые страницы, уместив в мобильное разрешение 360 px весь функционал страниц сайта.
В частном случае этого варианта делают ограниченную мобильную версию — иногда даже одностраничную или оставляют каталог без возможности заказа. Но, конечно, это всё может привести к снижению конверсии посетителей в клиентов.
Вариант третий. Обновляем сразу весь сайт.
В некоторых случаях бывает проще и дешевле обновить сразу весь сайт. Например, есть отличные готовые решения с современным дизайном и хорошей адаптивной вёрсткой на «1С-Битрикс». Я работаю с этой системой управления, поэтому говорю про неё, но подход применим и к другим платным и бесплатным CMS. Этот подход позволяет не только сделать свой сайт адаптивным, но и получить хорошую современную систему управления для него, какую-то новую функциональность сайта.
Тут можно выделить два направления в зависимости от исходного статуса.
Если старый сайт не на «1С-Битрикс». Нужно спланировать перенос накопленной на старом сайте информации (база пользователей, подписчиков, истории заказов и т.п.) и наполнения сайта. Возможно, что-то стоит автоматизировано переносить, а что-то — вручную.
Если старый сайт тоже на «1С-Битрикс», то перенос сайта на современное готовое решение может быть осуществлён двумя путями:
Путь 1. Ставим готовое решение вторым сайтом на «боевой» сервер к старому сайту (лицензия 1С-Битрикс позволяет работать двум сайтам на одной панели управления).
Настраиваем готовое решение на вывод тех же инфоблоков и свойств, что созданы для старого сайта без изменения самих форматов свойств.
В итоге получаем контент старого сайта, но в шаблоне готового решения с адаптивным дизайном. Скорее всего, в некоторых местах что-то будет выглядеть криво, что-то будет работать не так из-за разной архитектуры инфоблоков, разных настроек свойств заказов и т.д.
Поэтому далее выявляем моменты, которые необходимы для модификации данных под отображение на новом готовом решении. Это могут быть доработки дизайна/вёрстки (заменить логотип, например). Но могут быть и более серьёзные контентные вещи — допустим, на старом сайте свойство «бренд» для товаров — список, а в готовом решении должно быть привязкой к элементам инфоблока. После выявления, эти моменты исправляем.
Этот метод позволяет не решать в дальнейшем проблему синхронизации контента, который за период разработки станет отличаться между версиями сайтов. И в целом нами более рекомендуем.
Путь 2. Делаем отдельную копию сайта (отдельная админка, отдельная база), ставим на неё готовое решение и далее выполняем все действия на ней.
Этот метод хорош если есть опасения во время разработки как-то повлиять на рабочий сайт. Т.к. система отдельная, то метод более безопасен. Однако, возникнет проблема синхронизации. Пока мы делаем сайт на отдельной версии, на старой регистрируются новые пользователи, формируются новые заказы, копится статистика, обновляется контент. Поэтому синхронизация тут будет выполнена простым, но трудозатратным способом — все изменения документируются, а потом воспроизводятся повторно на «боевом» сайте.
Если рассматривать первый вариант решения задачи переноса сайта на готовое решение «1С-Битрикс», то примерные трудозатраты и план действий выглядит так:
- Выполнить резервное копирование сайта, создать сайт и поддомен на хостинге. Установить готовое решение вторым сайтом, закрыть его от индексации поисковиками. Это примерно 2-5 часов. Разброс, т.к. при установке решения могут возникнуть какие-то проблемы — с хостингом, с самим решением или чем-то другим.
- Перенастроить компоненты готового решения для вывода данных не из созданных им демо-инфоблоков, а из реальных инфоблоков старого сайта, настройка меню. Примерно 2-6 часов. На этом этапе у нас получится базис для дальнейших работ (то самое «кривое» готовое решение с контентом старого сайта), которые уже сложно оценить предварительно.
- Просматриваете сайт и составляете список замечаний для исправления (заменить логотип, настроить фильтры, вывести такое-то свойство, изменить вывод того-то, в оформлении заказа изменить поля такие-то и т.д.).
- С разработчиками изучаете ваши пожелания. Тут важно помнить, что помимо очевидных правок публичной части, которые на предыдущем пункте и обозначаются, надо будет проверять, оговаривать и планировать изменение разных скрытых моментов — как, например, свойства заказов (профили покупателей). В итоге получаем список задач — мини-техническое задание.
- Реализация итогового списка пожеланий.
- Запуск новой версии сайта в эксплуатацию. Зависит от числа необходимых действий согласно технического задания (например, может потребоваться автоматическое преобразование некоторых свойств на этапе запуска). В целом это: закрыть сайты от посетителей, выполнить резервное копирование, переключить показ по основному домену новой версии сайта (доработанного готового решения), проверить работоспособность основных сценариев (авторизация/регистрация, добавление товаров в корзину, оформление заказа).
Посмотреть примеры готовых решений сайтов на «1С-Битрикс» можно посмотреть на сайте моего работодателя: 8800.pro.
С каким-нибудь WordPress-ом, повторюсь, ситуация примерно такая же.
Я выделили 3 больших варианта. Естественно, все они могут изменяться в зависимости от ситуации, от особенностей старого сайта, требований по взаимодействию владельца сайта и исполнителей (а если Вы владелец и сами же исполнитель, то Вы и сами понимаете, как нужно действовать).
На дворе 2018 год — делайте свои сайты адаптивными!