Идеальный алгоритм вёрстки сайта?

Составил для себя такой список. Есть ли что-нибудь что я упустил и можно сделать лучше?

0. Если есть, изучить метрики текущего сайта: какие разрешения ходовые, какие браузеры, есть ли значимый % посещений особенных браузеров типа IE и т. д.

1. Осмотр макетов на дизайн-завершённость: смотрю чтобы были все состояния всех элементов, 404 страницы, необходимые модальные окна, алерты, валидация всего того где нужно, фавиконка, второстепенные макеты страницы типа политики конфы и т. д. Спрашиваю за файлы шрифтов, за оригиналы картинок (вдруг в макете демонстрационная графика), за видео, за текста если есть.

2. Осмотр макетов на интерактивность: уточняю, есть ли на страницах кроме очевидных интерактивных штук неочевидные: прилипающие блоки при прокрутке, анимации, какие-то эффекты которые "как нам том сайте", формы, калькуляторы, референсы и так далее.

3. Повторный осмотр макетов, выделение повторяющихся блоков, элементов, шрифтов и т.д.

4. Выкачиваю и сортирую всю графику по папкам: фоны, контентные изображения, svg. Сразу отмечаю для себя, что я могу сделать на чистом CSS. Учитываю ретина дисплеи, форматы webp — сервисом squoosh.app (там же проверяю, не слишком ли размыленно вышло, подкручиваю). Свг оптимизирую также через веб-сервис. Проверяю, можно ли оптимизировать шрифт: например, в макете может быть использовано только 10 символов шрифта в 1 месте, беру и отсекаю все остальные символы.

5. Начало вёрстки: делаю семантичную разметку страницы. При этом: в кодовом редакторе sublime стоят плагины которые помогают быстрее верстать — эметы, автопрефиксеры и т. д. Нейминг по БЭМ. Стараюсь использовать лучшие практики. Если в макете встречается блок, который я уже верстал — копирую разметку из прошлого проекта.

6. Делаю CSS: для начала дроблю весь макет на прямоугольники в голове, прикидываю переполнение контента и сетку. Определяю из пункта 3 что пойдет в CSS переменные. Стараюсь не писать CSS в разнобой, есть порядок описания свойств.

Тут следует упомянуть, что это этап проверки своих закладок-сервисов. Т.е я открываю папку с закладками и смотрю/вспоминаю что я могу использовать, чтобы не писать руками: например всякие градиенты, формы CSS, генераторы таблиц, закладки codepen и так далее (список на подобные сервисы у уважаемых читателей — всегда приветствуются))

Стараюсь уходить от px в сторону относительных единиц измерения, в сторону отзывчивых макетов без скачков, с минимумом медиа-запросов (если дизайн не совсем дебильный)

7. Сделав 1 страницу, доделываю все остальные, копируя разметку и классы.

8. Проверяю в браузерах: кручу, верчу, зумлю, тыкаю чтобы всё работало. Для этого всё закидываю на гитхаб-пейдж, чтобы по ссылке я мог открыть с телефона или попросить знакомого проверить на другой ОС c телефона. На десктопе проверяю в 5 браузерах как себя ведут страницы. Использую валидаторы разметки, чтобы устранить какие-то моменты где могут возникать ошибки или предупреждения которые можно и нужно исправить.

9. Когда готовы все шаблоны и весь базовый CSS приступаю к интерактивности: где-то js написать, где-то css анимацию прикрутить для элементов. Опять-таки, стараюсь не придумывать великов и искать готовые решения всяких интересных штук взятых из блогов зарубежных разрабов/закладок/ютуба. Стараюсь не обвешивать проект библиотеками, если есть вариант сделать на чистом CSS JS. Снова проверяю всё, устраняю найденные баги и ошибки.

10. Всё готово, сжимаю CSS, JS. через веб-сервисы. Точечно исправляю разметку где нужно (например у iOS на мобиле цифры в тексте могут отображаться как ссылка-номер, исправляется метатегом и т. д). Проверяю нет ли ошибок в консоли гугла. Всё разбито по папкам, ужато, проверено. Отправляю клиенту.

11. После запуска сайта с установленными метриками, через яндекс веб-визор выборочно проверяю как видят сайт пользователи определенных браузеров и OS, нет ли косяков. Если есть — гуглю, исправляю.

Что правильно/неправильно в моем процессе? Чего я не учёл? Где облажался? О чём я не знал? Как лучше? Какие тонкости?

P.S
У меня есть ещё несколько мыслей и хотелось бы услышать мнение специалистов и критики или наоброт.

А) Я всячески отговариваю клиентов от любых CMS для лендингов и небольших сайтов например до 15 страниц. Я считаю что это лишний интерфейс +замедление скорости, ведь для тех задач что нужно клиенту в 99% хватает самого хостинга с его редактором. Ну реально бесит какой-нибудь тормозящий на смартфоне сайтик из 5 блоков с текстом на Вордпресс.

Б) Я не упомянул SASS-фигас и т. д, так как не увидел практической пользы для проектов на 1-15 страниц. Вот что такого можно в SASS чего нельзя сделать в css-переменных? Ну да, css переменные нужно указывать аккуратно, окей, укажу.

В) Ну вот зачем PUG? Как конкретно он помогает на небольших проектах 1-15 шаблонов страниц. Зачем GULP? Я стараюсь писать осмысленно понимая что произойдет с блоком, мне не нужно по 10 раз перезагружать страницу. Минификация? Ничего страшного, за 10 секунд минифицирую всё сам через веб-сервис. Префиксы? В кодовом редакторе они и так есть. Оптимизация изображений? В небольших проектах нет сотен и тысяч изображений, а вручную я могу проконтролировать качество для оптимального сжатия через сервис.

Г) Что ещё существует на сегодняшний день для ускорения и оптимизации вёрстки?
  • Вопрос задан
  • 4348 просмотров
Решения вопроса 2
delphinpro
@delphinpro
frontend developer
В целом согласен. До пункта №7.

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

1. Базовые элементы. Общая типографика, кнопки, ссылки и т.п.
2. Общие блоки. То что повторяется на нескольких страницах и/или может быть переиспользовано, какие-то виджеты, менюшки, и т.п.

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

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


Это лишняя трата времени. Пусть небольшая, но все же. Плюс, отслеживать качество верстки все-таки удобнее в процессе, а не по окончании подкручивать.
Поэтому используем browser-sync. Поднимается сайт, доступный по IP в домашней локалке с любого устройства. Совет: использовать всегда один порт в browser-sync, а на устройствах сделать закладки на этот адрес. Любой сайт, который в данное время разрабатывается, открывается одним тапом по закладке.
Кроме того BS дает бонус в виде синхронизации действий сразу на всех устройствах: клики, прокрутка, ввод. Это мега-удобно — кликаешь на компе, краем глаза смотришь в планшет и телефоны, сразу видишь там все изменения и поведение.

Всё готово, сжимаю CSS, JS. через веб-сервисы.


Опять тратите время. Настроенный Gulp в одну команду проделает все оптимизации (на больших проектах даже кофе можно успеть сделать, пока собирается билд=).

Еще обратите внимание на инструмент lighthouse в инструментах разработчика.

скриншот
608fcaa260f31153020142.png


Не нужно никуда сайт заливать, чтобы проверить на доступность, производительность и т.п.

Про CMS ничего не скажу. Клиенту удобнее кнопочки тыкать в условном вордпрессе.

Я не упомянул SASS-фигас и т. д, так как не увидел практической пользы для проектов на 1-15 страниц.


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

Ну вот зачем PUG? Как конкретно он помогает на небольших проектах 1-15 шаблонов страниц.


Помогает. Нет, конкретно Pug я очень не люблю. Но другой, более "хэтээмэльный" шаблонизатор бывает полезен. Я уже упомянул выше о верстке независимыми блоками. Шаблонизатор позволит не копипастить эти блоки, а использовать их как компоненты.

Префиксы? В кодовом редакторе они и так есть.


Я считаю, что исходный код должен быть чистым, без префиксов. Это лишний визуальный мусор. Пусть лучше автопрефиксер этим занимается. К тому же этот плагин использует актуальную базу caniuse на основе вашего .browserlist. Пусть профит и не большой, но все же поменьше на выходе неактуальных свойств.
Ответ написан
iiiBird
@iiiBird Куратор тега Вёрстка
Пока ты спишь - твой конкурент совершенствуется
если именно брать как "идеал" и частично этого придерживаться, то нормальный алгоритм. но в реальных условиях слишком дотошный алгоритм.
если ты все это мастерски отточил и щелкаешь как семечки - мое уважение.
но если это уменьшает скорость верстки (а при реальных условиях это очень сильно может уменьшить скорость верстки) - то тут уже лучше подумать и не быть таким дотошным. потому что такой "идеал" не нужен никому кроме тебя самого.
т.е. если брать твои 15 страниц, о которых ты ведешь речь и верстаешь их неделю - это уже можно считать, что долго. и за эту неделю ты бы мог сверстать в 2 раза больше страниц и получить также в 2 раза больше денег.

про SASS, PUG, GULP и пр. спорить не буду. если нужно будет - сам дойдешь до этого со временем.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
bubn0ff
@bubn0ff
Специалист по технической поддержке
А. Согласен - CMS для мелких проектов не нужна.
Б. Удобство SCSS, прежде всего, для разработчика. Вложенности, миксины, импорты - как основное. Сам раньше не использовал CSS-препроцессоры, пока не понял их удобство и полезность.
В. Согласен - тоже не понимаю необходимости в HTML-препроцессоре PUG. Для меня он крайне неудобен.

В целом Ваш алгоритм схож с моим. :-) Хотя, думаю, можно и лучше.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы