Веб-сайт

В этой статье не будет подробного разбора всех аспектов SEO-friendly сайта. Я собрал здесь лишь тот объем информации, с которым мне необходимо было познакомиться для решения SEO-задач в компании.

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

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

Вы познакомитесь с несколькими важными областями валидной SEO-верстки и найдете примеры работы с validators.w3.org. Дополнительные материалы, указанные ниже, будут весьма полезны в повседневной работе верстальщика.

Семантические теги

Семантическая верстка - это html элементы со смыслом понятные разработчику, браузеру и поисковым роботам. К таким относят: header, footer, main, article, section, nav, aside и тд. Использование перечисленных тегов описывается по спецификациям W3C или WHATWG. Короткую вводную можно получить в цикле видео\статей HTML шорты от Вадима Макеева. Приведу описание к нескольким тегам.

Section - определяет раздел в документе. В соответствии со спецификацией W3C по HTML5: "Раздел это тематически сгруппированный контент, как правило с заголовком."
Article - определяет независимый, самодостаточный контент. Контент, помещенный в этот элемент, должен иметь смысл сам по себе, т. е. он должен быть понятен в отрыве от остальных частей веб-сайта.
Подробнее о article, а так же section написано здесь.
Header - предназначен для определения заголовочного блока или "шапки" документа или раздела. Подробнее здесь.
Footer - предназначен для определения "подвала" документа или раздела.
Nav - Предназначен только для основного блока навигационных ссылок.
Aside - определяет некий контент, находящийся в стороне от контента, внутри которого он расположен (как боковой блок страницы, "сайдбар").

В целом, тема доступности сайтов довольно обширна. Со всеми нюансами предлагаю ознакомиться в этой статье и еще советую пройтись по всей серии HTML шорты. Еще могу посоветовать ресурс Веб стандарты, некоторые статьи писали авторы спецификации HTML5 (переводы на русский). И для понимания, можно ознакомиться с контентной моделью HTML.

Микроразметка Schema.org

Чаще всего инструкции по включению микроразметки в HTML-код вы будете получать от SEO-специалистов. Но для понимания немного осветим эту тему.

Schema.org - стандарт семантической разметки данных, который помогает поисковикам лучше понимать данные, представленные на сайте. Например, с помощью разметки можно явно указать поисковым роботам, что на странице site.ru/product_page1 находится товар, и передать основные параметры: название, цену, артикул, производителя и т.д. На основе этих данных поисковики формируют расширенные сниппеты в поисковой выдаче.

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

Подробно о микроразметке написано в вики Яндекса. Документация Schema.org. Так же стоит обратить внимание и на гайд от Google.

Как проверить свой HTML

Так как один из критериев к SEO - это валидная верстка, необходимо прогонять написанный код через ранее упомянутый валидатор. К слову, помимо него есть валидатор от Google - в нем необходимо следить за выбранным роботом (Компьютер/Смартфон) и инструмент от Яндекса. Эти инструменты помогут Вам в задачах связанных с микроразметкой. Следует сравнивать новый и старый код, удостовериться, что ошибок нет и все существующие ранее сущности правильно считываются.

В целом, работа с ними сводится к тому, чтобы скопировать HTML код из браузера и вставить его в соответствующее текстовое поле валидатора. Можно копировать куски кода сразу из вашего IDE, но это должен быть чистый HTML с готовыми данными. После прохождения проверки вы будете получать уведомления о различных ошибках в коде. Warning можно опустить. Но от всех Error необходимо избавиться, чтобы верстка удовлетворяла принципам валидной HTML-страницы. В процессе работы могут возникнуть нерешаемые проблемы. Такое стоит гуглить и принимать во внимание, что валидаторы могут не поспевать за всеми нововведениями.

Перейдем к нескольким конкретным примерам (не)валидной верстки и их проверке с validator.w3.org.

Списки

К спискам относятся теги ul и ol (маркированные и нумерованные соответственно).
Выглядит это так:

<ul><li>item 1</li></ul><!-- или --><ol><li>item 1</li></ol>

Внутри открывающего и закрывающего тегов ul могут стоять только элементы li, а уже внутри самих этих элементов (пунктов) можно вставлять любой контент (текст, картинки, заголовки, абзацы, ссылки и даже другие списки). То есть, <ul><div></div></ul> является не валидной версией, и https://validator.w3.org/nu/ явно об этом напишет в выводе ошибок (Рис 1).

Ссылки

В использовании тега <a> тоже есть нюанс, в href недопустимы пробелы. То есть, <a href="tel:+7 (967) 321-22-33">phone</a> не является валидным вариантом (Рис. 2), однако <a href="tel:+7(967)321-22-33">phone</a> соответствует всем критериям.

Атрибуты

У каждого html тега есть свой набор валидных атрибутов. Часть из них можно увидеть здесь, остальное можно найти тут.
При использовании атрибутов необходимо помнить, что существуют устаревшие.

Таблицы

Часто приходится немного корректировать базовые стили таблицы. Раньше такое реализовывалось через соответствующие атрибуты.

<table border="1" cellpadding="0" cellspacing="0" width="400"></table>

На данный код мы получим сразу 4 ошибки об устаревших атрибутах (Рис. 3).

Это можно спокойно переписать с использованием стилей и классов.

• border - http://htmlbook.ru/html/table/border

• cellpadding - http://htmlbook.ru/html/table/cellpadding

• cellspacing - http://htmlbook.ru/html/table/cellspacing

• width - http://htmlbook.ru/html/table/width

Резюмируя вышеописанное получим примерно такой код:

<style>.table {  border-collapse: collapse;    width: 400px;    border-spacing: 0;   }.column {    padding: 0;    border: 1px solid #333;  }</style><table class=table>  <tr>  <td class=column></td>  </tr></table>

Подобное решение относится ко всем атрибутам, влияющим на стили элементов. Но есть такие, которые относятся к логике DOM-элементов. Чаще их реализация полностью падает на браузеры. Остальное можно реализовать с помощью JavaScript.

Атрибут id

Этот атрибут является неотъемлемой частью HTML. На нем часто завязаны стили и клиентский JavaScript. Данный подход уже давно не используется ввиду усложнения поддержки написанного кода. Используя id в браузере, часто можно наткнуться на проблему отсутствия уникальности значений этого свойства. Поэтому чаще всего чистый id заменяют на data-id или более специфичные названия. У нас часто используются data-атрибуты data-behavior и data-selector. Первый подходит для взаимодействия с пользователем, второй чаще используется для манипуляций с DOM. Однако, насколько я знаю, это необязательное правило. Помимо этого, в css можно писать код с обращением в любые из свойств элементов, будь то data-* или любой другой атрибут.

Пример микроразметки

Помимо примеров валидной верстки хотелось бы привести небольшой кейс использования микроразметки Schema.org. Используя микроразметку, желательно размечать верстку, которая видна на странице и никоем образом не скрывается от пользователя при помощи opacity, visibility, display или top/left/right/bottom: -100500px. Поисковики не жалуют скрытый контент. Иногда бывают исключения, но их стоит уточнять у SEO специалистов.

Перед тем, как мы продолжим хотелось бы описать значение используемых атрибутов:

Itemscope - задает область действия словаря в структуре данных. Как правило, работает совместно с атрибутом itemtype и задаёт пределы, где itemtype будет активен. У этого атрибута нет значений.

Itemtype - указывает адрес словаря, который будет применяться для определения свойств элемента в структуре данных. Яндекс и Google поддерживают стандарт разметки Schema.org. Соответственно, в качестве значения itemtype указывается адрес словаря на этом сайте. К примеру, для разметки организаций используется значение https://schema.org/Organization.

Itemprop - используется для добавления свойств словаря микроданных к элементу. Имя свойства определяется значением itemprop, а значение свойства определяется содержимым HTML-элемента, к примеру, текстом который располагается внутри элемента.
Приведем пример микроразметки Article.

<div itemscope="" itemtype="http://personeltest.ru/aways/schema.org/Article"><...>         <div class="article-meta">     <div       itemprop="author"       itemscope=""       itemtype="http://personeltest.ru/aways/schema.org/Person"     >       <span         itemprop="name"         class="meta-item"       >         ВсеИнструменты.ру       </span>     </div>     <time       itemprop="datePublished"       class="datetime meta-item"       datetime="{{ article.getUpdatedTimeObj().format('Y-m-d') }}"     >       {{ article.getUpdatedTimeObj().format('d.m.Y') }}     </time>   </div>   <meta      itemprop="description"      content="{{ article.getShemaOrgDescription() }}"   />   <div     itemscope     itemprop="image"     itemtype="http://personeltest.ru/away/schema.org/ImageObject"   >     <img       itemprop="url"       src="{{ article.getShemaOrgImageUrl() }}"       alt=""       class="d-none"     >   </div>   <...></div> 

В данном примере представлена микроразметка статьи. Действие микроразметки ограничено дивом с атрибутами itemscope, itemtype = Article. Внутри включает микроразметку автора статьи и дату публикации. Включает в себя также краткое описание статьи и изображение. В данном кейсе при помощи бэкенда на этапе публикации парсится весь список изображений и выдается фронтенду при помощи метода getShemaOrgImageUrl().

Я не хотел бы сильно погружаться в детальные гайды по микроразметке, поэтому просто укажу несколько полезных статей на эту тему.
1. Микроразметка для сайта интернет-магазина: как настроить разметку Schema.org для товаров и категорий
2. Микроразметка товаров

Итог

Хотелось бы, чтобы этот материал был вам полезен. Я старался предоставить информацию для работы с SEO-версткой максимально сжато. Надеюсь, я смог достичь этой цели. Данной информации не хватит для формирования по-настоящему SEO-friendly сайта, поэтому я рекомендую использовать дополнительные материалы при разработке своих страниц. Эта тема сложна и обширна. Для плодотворного продвижения и удержания позиций сайта в поисковой выдаче необходимо работать в паре с SEO-специалистом и постоянно вести работы над улучшениями своих продуктов. Спасибо за уделенное время!

Apache Wicket - это фреймворк для веб-разработки на Java. Я чувствую, что ему не уделяют столько внимания, сколько он того заслуживает. Я профессионально использую Wicket для реальных проектов последние 6 лет и мне это нравится! В этом посте давайте рассмотрим пять причин, по которым вам стоит подумать об его использовании.

1. Простое управление состоянием

Опыт разработки приложений Wicket очень похож на разработку для настольных компьютеров. Иногда вы можете почти забыть о том, чтоб вы работаете с HTTP, т.к. нет необходимости сохранять состояния. Это связано с тем, что в Wicket веб-страница и все ее компоненты (кнопки, текстовые поля и т. д.) Являются объектами Java, которые поддерживают свое собственное состояние. Состояние компонентов сериализуется в сеансе пользователя и десериализуется в нужное время.

Проще говоря, предположим, что у вас есть форма с полями, которые пользователь заполняет и отправляет. В приложении Wicket эта форма, ее поля и кнопка отправки являются компонентами (объектами Java), которые создаются и добавляются на веб-страницу. При нажатии кнопки отправки:

1.У нас автоматически есть доступ к вводу пользователя, обычно в виде полей POJO.

2.Нам не нужно связывать запрос HTTP POST с запросом GET.

Нам также не нужно думать о заполнении полей формы отправленными значениями. Это делается с помощью моделей, которые являются основной концепцией Wicket.

2. Стандартная интеграция HTML

HTML в Wicket не требует каких-либо специальных тегов, в отличие от некоторых других фреймворков. Фактически, вы можете взять любой существующий HTML и интегрировать его с вашим приложением Wicket практически без изменений. Для подключения HTML-тегов к компонентам Wicket необходим только один атрибут: wicket: id Рассмотрим пример:

<div wicket:id="userName">Roman</div>add(new Label("userName", getUsername()));

wicket:id "userName" используется для подключения HTML элемента с компонентом Wicket. Компонент Wicket Label получит имя пользователя и отобразит div тег . Ничего страшного, если сейчас это не совсем понятно. Это становится привычным и интуитивно понятным, когда вы начинаете экспериментировать с ним. Компоненты Wicket являются объектами первого класса и могут инкапсулировать собственную разметку HTML / CSS / JS, как в некоторых популярных фреймворках, таких как React. Это позволяет нам создавать код, который можно многократно использовать.

3. Не требуется Javascript (по большей части)

В какой-то момент вы закончите писать код JS. Поддержка AJAX, предоставляемая Wicket, означает, что вам не нужно писать собственный JS-код для наиболее распространенных задач. За кулисами Wicket использует JQuery и автоматически генерирует JS-код на веб-странице. Давайте рассмотрим для примера страницу с раскрывающимся списком и различными другими компонентами, которые зависят от выбора этого раскрывающегося списка. Когда выбор изменяется, нам нужно обновить эти различные другие компоненты на странице. На самом деле для этого не требуется код Javascript . Это делает Wicket идеальным решением для создания сложных интерфейсов со сложной бизнес-логикой.

4. Система событий / сообщений

События Wicket - это способ взаимодействия компонентов и страниц между собой. Используя эту функцию, мы можем создавать очень сложные, но не связанные друг с другом структуры компонентов. Компонент может транслировать сообщение, не зная, кто его получит. Когда компонент заинтересован в конкретном типе сообщения, он может просто подписаться, чтобы получать уведомление, когда это сообщение будет транслироваться. Компонент может транслировать событие критического обновления с полезной нагрузкой всем другим компонентам на странице следующим образом:

send(getPage(), Broadcast.BREADTH, new CriticalUpdate(target, payload));

И если какой-то компонент заинтересован в получении CriticalUpdate , он будет регистрироваться следующим образом:

public void onEvent(IEvent event) {    if (event.getPayload() instanceof CriticalUpdate) {       String msg = ((CriticalUpdate)event.getPayload());       //do something with the msg      } }

5. Модульное тестирование

Компонентный / сохраняющий состояние характер Wicket означает, что мы можем писать модульные тесты для внешнего интерфейса так же, как мы пишем их для уровня сервиса или нашего уровня доступа к данным. Wicket предоставляет полезные утилиты, упрощающие написание модульных тестов. Давайте рассмотрим пример простого сценария, который может оказаться не таким простым для тестирования в других средах. У нас есть веб-страница с интерфейсом CRUD: таблица с именами и кнопками удаления. Форма с текстовым полем и кнопкой для добавления новых строк в таблицу. Мы можем написать тест, который отобразит страницу, имитирует заполнение и отправку формы пользователем, обеспечит правильное обновление таблицы, имитирует нажатие кнопки удаления пользователем и так далее. Все это может быть выполнено с использованием чистого кода Java и JUnit, не прибегая к Selenium, Puppeteer или аналогичным библиотекам.

Заключение

Надеюсь, вы услышали достаточно, чтобы попробовать Wicket. Если вам интересно узнать больше:

1. Перейдите на официальный сайт, где есть отличная документация.

2. Взгляните на примеры кода часто встречающихся практик в веб-разработке.

Понадобилось мне тут недавно фрилансера найти, чтобы вебсайт сделать. Казалось бы, и что тут такого? Уж кого-кого, а веб-девелоперов в стране хватает! За пару недель найду, - думал я, максимум за месяц. Как вы уже догадались, не нашел.

Этот лонгрид - о фрилансерах в частности, и немного о веб-разработке в целом, от лица заказчика. Я прекрасно понимаю, что большинство завсегдатаев Хабра - исполнители, а заказчикам тут периодически прилетает. И все же рискну высказаться. Надеюсь, будет весело.

Тут надо сделать небольшое лирическое отступление, чтобы вы смогли погрузиться в контекст. Итак, у нас с коллегами есть небольшой pet-проект в области образования. Если точнее - в области постановки произношения. Внутри этого pet-проекта есть еще один вложенный класс pet-проект, - YouTube канал, на котором мы тестируем разные идеи, собираем отзывы, и немного анализируем рынок.

Постепенно у нас накопилось приличное количество текстового материала - статьи, аналитика, разные тестовые задачки, и тому подобное. Параллельно YouTube канал набрал несколько сотен тысяч подписчиков. А еще мы стали замечать, что доля поискового и внешнего трафика на канале приближается к 50% (это много). Причем поисковые фразы хорошо коррелируют с "нужными" высокочастотными запросами.

В общем, мы дозрели до своего сайта.

Пишем техзадание

Адекватного заказчика отличает хорошее понимание того, что он хочет. Проблема в том, что нам-то был нужен самый что ни на есть обычный контентный сайт. Мы даже ненадолго впали в ступор, как это красиво расписать. По большому счету, техзадание могло быть примерно таким:

Сделать совершенно типичный сайт для публикации статей. Функциональные требования не выделяются чем-то уникальным. Дизайн - примитивный. Нагрузка - средняя. Pagespeed insights >= 90%.

Этот вариант имел право на жизнь, но выглядел несколько эксцентрично. Поэтому мы просто сели и записали в ТЗ все, что входит в обычный блог. Нарисовали основные мокапы. Перечислили референсы. Ну и, конечно, добавили несколько специфических требований:

Полнотекстовый [морфологический] поиск а-ля ElasticSearch или Sphinx.
Фильтрация списков статей по множеству тегов.
Сортировка списков статей по времени и/или категориям.
Кастомное меню с навигацией по ключевым статьям на главной странице.
И еще одна секретная фича на фронтенде.

Я еще расскажу об этих "специальных" требованиях ниже. Впрочем, даже с ними функциональная часть нашего ТЗ не выглядела как Rocket Surgery.

Осталось разобраться с нефункциональными требованиями.

Гугл не скрывает, что использует скорость загрузки страниц в качестве одного из критериев своих алгоритмов ранжирования. Поэтому мы включили в ТЗ оптимизацию сайта до зеленой зоны PageSpeed Insights. Кроме вполне очевидной пользы, это требование позволяло нам отсечь неопытных исполнителей (спойлер: это сработало, но не совсем так, как мы предполагали).

За отправную точку оценки нагрузки взяли наш YouTube трафик. В хороший день это 7-8 тысяч уникальных посетителей со средним количеством просмотренных видео 2,4. Берем полуторакратный запас и получаем порядка 30 тысяч хитов. Это примерно 12 тысяч посетителей в день.

В общем, у нас получилось вполне приличное техзадание на 15 страниц.

Публикуем заказ.

Рассуждая в том ключе, что "хорошие" исполнители ТЗ читают, а "плохие" нам не нужны, мы добавили в техзадание "капчу": просьбу начинать отклик со слов "Hello there!".

Сам текст публикации был максимально коротким. Примерно таким:

Cделать контентный сайт на базе вашей любимой CMS/фреймворка согласно ТЗ

Внимательно прочитать требования к проекту (!).
Выбрать оптимальную CMS/фреймворк, удовлетворяющие требованиям.
Оценить общую трудоемкость и стоимость проекта.
Согласовать приблизительный поэтапный план разработки.
Собственно, сделать сайт согласно плану.

Заказ опубликовали на пяти площадках, с разницей по времени от нескольких дней до недели. Там, где было возможно, мы старались "выделить" объявление:

На все про все было потрачено примерно 3500 рублей. Бюджетненько!

Разбираем отклики

Всего на заказ отозвались ровно 100 исполнителей:

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

Чтобы себя успокоить, мы сделали трекер исполнителей с классификатором их видов:

Вид первый, "автобот":

Здравствуйте, это как раз мой профиль, готов помочь!
Портфолио > https://***.**/portfolio/
Телефон/Viber/WhatsApp: ***

(здесь и далее приведены совершенно реальные отклики, орфография и пунктуация авторов сохранены)

Характерные признаки "автобота": присылает отклик практически сразу после публикации заказа. Где-то в интервале от минуты до пары часов. Как правило, в портфолио бота половина ссылок не работает. Причем это лучшая половина. Чаще всего боты водятся на freelancehunt.com и freelance.ru. Что бы вы ни делали, вступать с вами в переписку бот не будет.

Вид второй, "разработчик продающих сайтов":

--не бот--

***, добрый день! Меня зовут ***, я веб-разработчик с опытом более 10 лет. Самое главное - это продающая структура, а уж потом дизайн и верстка, я делаю именно "продающие" сайты, которые реально работают.

CMS на которых делаю сайты: 1. 1С Битрикс 2. Тильда 3. Wordpress

Характерные признаки: старательно дистанцируется от ботов. Вне зависимости от задачи, использует такие словосочетания как "повышение продаж", "продающая структура", "конверсия", "SEO", и другие. Средний опыт работы - более 10 лет. В списке регалий имеет Битрикс и Тильду.

Наконец, вид третий. Самый забавный. "эффективный project manager":

Добрый день, ***!

Бюджет вашего проекта 10 000$. Если вас устраивает такая стоимость, то давайте назначим звонок на конкретное время. Длительность звонка: 1 час. Наш CTO к тому времени ознакомится с вашим документом и подготовит ответы на ваши вопросы.

Характерные признаки: управляет вселенной, не привлекая внимания санитаров технических специалистов. Может за пару минут оценить любой проект, не открывая ТЗ. Всячески демонстрирует свою занятость, но при этом подчеркнуто избегает какой-либо конкретики. Очень любит круглые суммы.

В итоге, лучше всего себя показал freelance.habr.com (ура!), хуже всего - freelancehunt.com и freelance.ru. Как еще существует weblancer.net - непонятно.

Далее, из сотни откликнувшихся лишь 14 человек полностью прочитали наше задание. Еще шестеро капчу не прошли, но попали в short-list, потому что написали развернутый отклик.
Итого - 20.

Слава роботам!

Пытаемся планировать

Life is what happens to you while you're busy making other plans
John Lennon.

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

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

Почти половина отвалилась сразу, даже не попрощавшись. Причем, что интересно, отвалились как раз те, чьи отклики производили наилучшее впечатление.

Несколько человек все же планы прислали, чем нас еще немного повеселили. Ниже - наш топ-3.

"Стандартный" план:

этапы разработки у нас стандартные ))
1. Разработка прототипа проекта (UX проектирование)
2. Разработка дизайна
3. Верстка
4. Посадка верстка и доработки серверной части
5. Тестирование

Еще вариант, со сроками:

1. Прототипирование и создание дизайна сайта 10 дней
2. Верстка сайта 7 дней
3. Программирование структуры сайта 30 дней
4. Создание уникальных модулей 10 дней

И, наконец, мой любимый, самый короткий:

Разработка фронтенда, админ-панель, бэкенд
По срокам примерно 2-3 недели, цену предлагайте сами.

В результате, этап планирования прошли шестеро. Трое - с Wordpress, и по одному с Laravel, October CMS, и Drupal.

Впереди нас ждет еще очень много всего интересного!

Wordpress - три попытки, от $2000 до $4000

Когда-то в начале двухтысячных Wordpress задумывался как простая система для self-hosting блога: удобная админка, таксономия, теги, антиспам фильтр, неплохой по меркам тех времен редактор, и так далее. Где-то начиная с 2011, стали появляться разнообразные плагины: e-commerce, booking, формы, галереи, и так далее.

Наверное, это был правильный вектор развития с точки зрения бизнеса. В конце концов, миллионы владельцев "лэндингов" и интернет-магазинов не могут ошибаться. Вот только как система для публикации контента Wordpress так и остался где-то в 2010-м. И даже, по-моему, немного откатился назад.

Камнем преткновения для Wordpress разработчиков стали наши требования по скорости загрузки страниц. Напомню, что нам очень хотелось получить сайт в зеленой зоне PageSpeed Insights. Так вот, по оценке наших кандидатов, оптимизация Wordpress съедала 40-50%% бюджета. Буквально каждый кандидат категорически настаивал на разработке кастомизированной темы "с нуля".

Вырисовывалась примерно такая логика: вы должны использовать Wordpress, потому что это самая популярная CMS, и там много классных тем и плагинов. Только вам эти темы использовать нельзя, потому что работают они медленно. А так как ядро CMS рассчитано на вот это вот все, то надо понимать. Поэтому, если хотите сделать хорошо, то надо делать кастомную тему, то есть доплатить за "оптимизацию" Wordpress.

Мы просто подсчитали, что только оптимизация обходилась нам где-то от $800 до $2000. Но это еще не самое страшное.

Другая проблема Wordpress, как ни странно, - это очень скромные "встроенные" средства управления контентом. Приведу такой пример: на Хабре можно посмотреть список статей в хабе фриланс, либо в хабе разработка веб-сайтов, но нельзя получить список статей, относящихся к обоим хабам одновременно.

У нас, конечно, гораздо меньше контента, чем на хабре. Зато время его жизни существенно больше. Чтобы помочь пользователям ориентироваться во всех наших статьях, мы решили добавить фильтры по множеству тегов.

Если вы хотя бы чуть-чуть знакомы с основами баз данных, то набросать запросы для фильтров many-to-many сможете за полчаса А вот стандартных плагинов для Wordpress с такой функциональностью - нет. Как нет и полнотекстового поиска из коробки, не говоря уже о морфологическом.

В общем, у нас были три Wordpress-кандидата. Все трое - хорошие специалисты с неплохими портфолио и впечатляющим опытом. Кстати, говоря о бюджете, даже с учетом Wordpress-оверхеда, он был вполне приемлемым: от $2000 до $4000.

Мы всячески пытались довести хотя бы одного из кандидатов до контракта. Но не сложилось: первый сошел с дистанции в процессе согласования деталей. Второй изначально особой активности не проявлял, как бы намекая, что не сильно заинтересован. Третий немного подумал, и сам предложил отказаться от Wordpress в пользу Laravel. За +20% к цене.

А ведь все так хорошо начиналось!

Laravel - $2000

Параллельно у нас появился еще один многообещающий кандидат:

Hello there! Я не могу предложить готовую CMS, но зато могу предложить потрясающий фреймворк Laravel. На нём могу реализовать весь необходимый вам функционал.

Вечер перестает быть томным, - подумали мы.

Буквально за выходные кандидат-ларавел развёл кипучую деятельность: написал весьма подробное техническое обоснование, включая примерный расчет VPS сервера под требуемую нагрузку, список необходимых сторонних библиотек, краткий план работ, mind map, и даже прислал несколько референсных тем. Несмотря на разницу во времени, кандидат отвечал на вопросы практически мгновенно, да и в целом производил самое что ни на есть благоприятное впечатление.

Вот только был один нюанс: у парня не было портфолио. Совсем не было. Ни единого сайта. Более того, он отказывался показать хоть какие-нибудь примеры своих работ, ссылаясь на NDA.

И тем не менее, мы решили рискнуть. Во-первых, кандидат-ларавел был самым коммуникабельным из всех, с кем мы на тот момент успели пообщаться. Во-вторых, сумма ($2000 за основную функциональность) и сроки (4 недели) выглядели вполне разумно. Поэтому мы предложили вариант с поэтапной оплатой через escrow. От него требовалось только подтвердить план на первые два этапа и заключить контракт

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

А жаль, нормально же вроде общались.

Drupal - $8000

В любом pet-проекте есть несколько интересных идей "на вырост". У нас они тоже есть. Что гораздо важнее, мы знаем, чего мы делать не будем: не будем открывать интернет-магазин, запускать корпоративный портал, хостить форумы, и тому подобное.

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

Поэтому мы немного удивились, когда на наш заказ откликнулась целая web-студия с предложением сделать сайт на Drupal 9. Они оценили бюджета проекта в $8000.

Менеджер студии практически сразу переслал нам наше же техзадание, с комментариями их разработчика. Почти все было помечено как "доступно из коробки". Только в паре мест стояли пометки "нужны дополнительные настройки" или "нужна установка плагинов".

Как были обоснованы $8000? А никак! Все, что было хоть сколько-нибудь детально расписано, относилось к дополнительным опциям. Ну, вы понимаете, все эти , "структура сайта", "user story", "подготовка ТЗ" и "фиксация деталей по функциям". Где-то даже промелькнула фраза "наполнение контентом".

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

В общем, от этого предложения мы отказались сами: писать user story нам не хотелось, да и в целом выбор Drupal показался необоснованным.

А еще мы пожалели $8000.

October CMS - $2000

Нам изначально нравилась философия минимализма в October. К примеру, мы не планировали регистрацию внешних пользователей. Для простого контентного сайта в этом просто нет необходимости: контент будем добавлять только мы, а для комментариев все равно удобнее использовать что-то вроде commento.io. Зачем нам лишний код?

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

Мы хотели пообщаться с кем-нибудь с опытом в October, хотя статистически это и было маловероятно. И все же, иногда даже маловероятные события случаются.

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

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

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

В общем, мы заключили контракт и закинули деньги за первые два этапа на escrow.

Первый этап был закончен точно в срок, мы даже удивились. Не то, чтобы это был сложный этап, - изначальная установка CMS, базовых плагинов и тем. Но к этому моменту мы уже так устали от всего происходящего, что радовались как маленькие дети. У нас, наконец, что-то заработало! Мы даже можем что-то опубликовать!

Увы, наша радость была недолгой. Второй этап был отложен на неделю, потом еще на неделю. Судя по коммитам на Github, второй этап даже не был начат. А потом исполнитель просто пропал.

Запил, наверное.

Бонус - профессиональные студии, до $18 000

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

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

Если коротко, то там еще хуже.

Нам присылали "коммерческие предложения", скопированные с других проектов, не имеющих ничего общего с нашим. Нам предлагали сделать магазин, - "вам же когда-нибудь понадобится магазин?" Нам предлагали "зашифровать чувствительные данные". Нам предлагали увеличить трафик в два раза (серьезно?!?), а также "переделать сайт под SEO продвижение", и "протестить нишу". Да, еще нам предложили "написать адекватное ТЗ". Я уже рассказывал про use cases и user story?

Нам долго и обстоятельно рассказывали о преимуществах EditorJS над Tailwind, и TinyMCE над Bootstrap (и наоборот). Нам даже объяснили, почему монолитная архитектура нам подходит лучше, чем микросервисы. Ах да, ну и конечно, правильный PHP - это PHP 7, правильный Laravel - это 8, ну а правильный HTML - это 5! И никак иначе!

Зачастую все это сопровождалось огромным количеством грамматических ошибок и перемежалось фразами "я вас услышал", "наиболее оптимальный", и тому подобными. Не поймите меня неправильно, лично я спокойно отношусь к грамматическим ошибкам. Но когда в твоей команде большинство - лингвисты, им сложно объяснить, почему project-manager подрядчика пишет как третьеклассник, а разговаривает как пятиклассник.

И все это за каких нибудь $18 000 (восемнадцать тысяч долларов США). Ну хорошо, если мы "урежем" часть требований - $12 000. Но тогда работа аналитика оплачивается отдельно.

Вместо эпилога

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