Об омолаживании вебсайта — критерии принятия решения

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

Но, как любая современная технология, технология производства вебсайтов быстро развивается. Ваши клиенты больше не сидят за компьютерами, они стали путешествовать с планшетами и смотреть сайты на экранах смартфонов. Чтобы приспособиться к новым привычкам ваших клиентов, старый сайт нужно омолодить. А может и не надо?

Кто спорит, есть консервативные бизнесы, для которых омолаживание не требуется. Например, сайт самой богатой частной компании в мире Berkshire Hathaway, так и застыл в 1996м, потому что отлично справляется с основной задачей — предоставлением годового отчета инвесторам, а больше от сайта ничего не требуется.

Но, если ваша компания не принадлежит пока Уоррену Баффету, вам нужно как-то справляться. А как узнать, что уже пора вести ваш сайт к косметологу, тьфу… к вебмастеру?

1) Повышение количества «отскоков»


High bounce rate, почему-то в русскоязычной литературе именуемый «показатель отказов» означает низкий уровень вовлеченности посетителей сайта. Если аудитория сайта сильно не менялась качественно за прошлые годы, а это можно посмотреть в разделе характеристик аудитории, например в Google Analytics, повышение уровня отказов от просмотра это звоночек! В Google Analytics смотрим Aquisition > Overview и оцениваем характер вовлеченности по каналам траффика.

Рис 1. Благостная картина. Ни трафика, ни отказов.
ни трафика ни отказов

Рис 2. А вот тут летом что-то пошло не так!
тут что-то не так с Bounce Rate

2) Увеличение количества технических ошибок


Посматривайте в Google Search Console, в раздел Crawl Errors, если наблюдается склонность сайта к накапливанию ошибок сервера, 404 и результатов неверных редиректов, надо что-то делать. Например, нанять админа все это чинить. И не так что «отметим ошибки как пофиксеные» в той же Search Console, а по-настоящему. С техническим аудитом сайта и разбором проблем по каждому разделу.

Рис.3 Тут у нас были проблемы, но мы все починили. Почти, но не совсем.
Ошибки в консоли - пора над ними работать снова

3) Низкая относительная скорость загрузки страниц


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

Но настроение Google не так страшно, как ваш удар по терпению ваших пользователей. Если ваш сайт по подбору фильтров для пылесосов грузится медленнее чем 4 секунды (а надо 2), клиент уйдет на более быстрый сайт с высокой долей вероятности.

Вы можете проверить здоровье сайта в этом смысле с помощью инструмента Chrome PageSpeed Insights Tool, а для целей внутреннего документирования можно сгенерировать отчет на GTMetrix.

4) Дружественность к пользователям смартфонов


Да, парадигма mobile-first увы — торжествует. Более 60% поисков в Интернет сегодня выполняются со смартфонов. А ваш сайт готов к изменившейся ситуации? Узнать это поможет отличный инструмент Google по оценке «мобилизации» вашего сайта — testmysite.withgoogle.com.

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

Рис.4 6 секунд это долго для 3G, этот сайт должен грузиться за 3с.
Сайт должен грузиться менее чем за 3с

5) Устаревший дизайн — диагноз необходимости омолаживания сайта


Не вдаваясь в подробности, дизайн зависит от бизнес-функции сайта, как марка вашего автомобиля зависит от того зачем он вам нужен в принципе. Если сайт мультимиллирдного фонда Berkshire Hathaway может себе позволить стиль мятой бумажки формата А4, это не значит, что именно ваши пользователи обрадуются такому подходу.

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

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

6) Отвечает ли старый сайт вашим нынешним бизнес-процессам?


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

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

*FOUC — Flash of Unstyled Content — баг UI/UX, когда пользователю показывается неоформленный контент, поскольку управляющие выводом стили и скрипты грузятся дольше положенного по регламенту.

** Даже сайт на WordPress можно снабдить пакетом для разработки по MVC паттерну, превратив его из процедурного фреймворка в OOP фреймворк, получив бесплатно и в одном флаконе логичность Laravel, волшебство Magic и удобство ACF.
Поделиться публикацией
Похожие публикации
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 18
  • 0
    Ваша фирма десять лет назад вложила в разработку сайта существенные средства, и худо-бедно за эти годы сайт их отбил.


    Изначально неправильная постановка.

    Если сайт нужный-полезный-критичный для бизнеса-дорогой в разработке — то его нужно поддерживать и обновлять регулярно. Никак не раз в 10 лет.

    Если сайт типа сайта визитки — то что это за «Рога и копыта», если разработка, сделанная 10 лет назад, до сих пор заставляет директора фирмы с содроганием гладить кошелек.

    Никакой «худо-бедно за 10 лет» окупаемости в вебе быть не может в принципе.

    • 0
      Вы это Уоррену Баффету скажите — я его сайт Berkshire Hathaway в качестве хрестоматийного примера привожу.
      • 0
        а разве баффет делает бизнес в интернете?
        • –1
          Возможно, это покажется странным и необычным, но у каждого бизнеса свой взгляд на то, зачем ему Интернет. А некоторым бизнесам он и вовсе незачем. что же касается Баффета, то у него почти три процента в Apple и почти девять в IBM, если что. Баффет делает бизнес в голове, а Интернет использует для быстрого ознакомления инвесторов с результатами работы фонда. Другие делают как-то иначе. Но статья, конечно не об этом.
          • 0
            но баффет не торгует акциями эппл и ибм на своем сайте

            то есть ваш пример сайта баффета не подходит для случаев, когда бизнес построен именно на возможностях интернета, например тот же амазон
            • 0
              Пример не подходи, а подход к принятию решения изложенный в статье — почему нет. На редизайн амазона я не замахиваюсь, не по сеньке шапка. Мне бы сподвигнуть мысли тех, у кого старые desktop-first сайты малость проржавевшие, чтобы заглянули в аналитику и выводы сделали.
              • 0
                cподвиги не работают, работают только готовые проекты, даже если они называются proof of concept
      • 0
        Вы это Уоррену Баффету скажите — я его сайт Berkshire Hathaway в качестве хрестоматийного примера привожу.


        Разве сайт обошелся Баффету в такую сумму, что он ждал 10 лет пока он окупится?

        Здесь не упомянут один из важных аргументов:

        Увеличение вероятности взлома (а то и реальные взломы) устареших CMS
        • 0
          У него были вообще свои критерии, когда он его заводил. А статические сайты не ломаются, такие как сайт BH. Вероятность же взлома сильно преувеличена. У меня в управлении есть пара сайтов, которые по ряду причин (управленческого характера) не будут апгрейдится с WP 3.6.1 например. Думаете их хоть раз сломали за 5 лет с момента создания? Нет. Дело не в увеличенной вероятности взлома, а в том как именно выглядит risk exposure для бизнеса в случае увеличенной вероятности взлома. Если меры по защите сайта на устаревшей CMS стоят в разы дешевле переработки сайта, а сайт продолжает выполнять бизнес-функцию, то зачем его переделывать?
          • 0
            У меня есть пара сайтов с Джумлой 1.5 в управлении.
            Владельцы категорически не хотели обновляться.
            Теперь можно про эти сайты говорить в прошедшем времени — сайты были похаканы и в них засажены спам-прокси.
            При том что с Джумлой 2.5 уже таких проблем нет.
            • 0
              да, такое я тоже видел. А важен был сайт для бизнеса его владельцев?
              • 0
                Важны.
                Но ведь проблемы визуально нет.
                А спам-прокси не волновали владельцев сайтов.
                «Сайт же работает».
                Меня они волновали, потому что меня хостер долбил.
                А хостер долбил потому что ему абузы шли.

                • 0
                  Тогда вы возможно зря волновались. Как в контракте на поддержку сайта было прописано обеспечение безопасности и оплата за него?
                  • 0
                    Тогда вы возможно зря волновались. Как в контракте на поддержку сайта было прописано обеспечение безопасности и оплата за него?


                    Ну дык мне хостер сервер блокировал. Как тут не волноваться. Хостеру абузы тоже не нужны.

                    Контракт на обеспечение безопасности для бюджетного сайта на Джумле?
                    Да вы смеетесь.
                    Если бы такой контракт был бы, то денег в нем было бы заложено раза в 3 больше, чем на создание самого сайта.
                    Тогда бы я просто за свой счет перевел бы с Джумлы 1.5 на Джумлу 3 — и это все равно было бы выгодно.

                    • 0
                      То есть вы продали клиенту сайт без пункта об обеспечении его безопасности? Тогда вам не о чем беспокоиться, пусть клиент беспокоится.
    • +1
      Даже сайт на WordPress можно снабдить пакетом для разработки по MVC паттерну

      Возможно есть еще какие-то, но я использовал Corcel. Хорошая штука, когда основной сайт на Laravel, а блог сбоку на WordPress.

      • 0
        это интересно, спасибо. Я в последнее время присматриваюсь к статическим генераторам с CMS, есть например генератор для Kirby.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.