@Kadzi
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 секунд минифицирую всё сам через веб-сервис. Префиксы? В кодовом редакторе они и так есть. Оптимизация изображений? В небольших проектах нет сотен и тысяч изображений, а вручную я могу проконтролировать качество для оптимального сжатия через сервис.
Г) Что ещё существует на сегодняшний день для ускорения и оптимизации вёрстки?
Решения вопроса 0
Ответы на вопрос 2
@delphinpro
Я обычно придерживаюсь принципа верстки независимыми блоками.
Поэтому после анализа макетов, я делаю одну-две-три (смотря по объему макетов) вспомогательных страниц, на которых верстаю:
1. Базовые элементы. Общая типографика, кнопки, ссылки и т.п.
2. Общие блоки. То что повторяется на нескольких страницах и/или может быть переиспользовано, какие-то виджеты, менюшки, и т.п.
Все это занимает основную часть времени работы. И к окончанию этих этапов я имею своего рода набор, или конструктор, из готовых блоков. Остается только написать лейауты для разных страниц и раскидать по ним имеющиеся блоки.
Для этого всё закидываю на гитхаб-пейдж, чтобы по ссылке я мог открыть с телефона или попросить знакомого проверить на другой ОС c телефона
Это лишняя трата времени. Пусть небольшая, но все же. Плюс, отслеживать качество верстки все-таки удобнее в процессе, а не по окончании подкручивать.
Поэтому используем browser-sync. Поднимается сайт, доступный по IP в домашней локалке с любого устройства. Совет: использовать всегда один порт в browser-sync, а на устройствах сделать закладки на этот адрес. Любой сайт, который в данное время разрабатывается, открывается одним тапом по закладке.
Кроме того BS дает бонус в виде синхронизации действий сразу на всех устройствах: клики, прокрутка, ввод. Это мега-удобно — кликаешь на компе, краем глаза смотришь в планшет и телефоны, сразу видишь там все изменения и поведение.
Всё готово, сжимаю CSS, JS. через веб-сервисы.
Опять тратите время. Настроенный Gulp в одну команду проделает все оптимизации (на больших проектах даже кофе можно успеть сделать, пока собирается билд=).
Еще обратите внимание на инструмент lighthouse в инструментах разработчика.
Не нужно никуда сайт заливать, чтобы проверить на доступность, производительность и т.п.
Про CMS ничего не скажу. Клиенту удобнее кнопочки тыкать в условном вордпрессе.
Я не упомянул SASS-фигас и т. д, так как не увидел практической пользы для проектов на 1-15 страниц.
Возможно вы плохо знакомы с возможностями препроцессоров, или вам никогда не требовались они, кроме переменных.
Но даже в этом случае, препроцессор помогает упорядочить и структурировать код, а не писать одну простыню на 10 тыс строк в одном файле.
Ну вот зачем PUG? Как конкретно он помогает на небольших проектах 1-15 шаблонов страниц.
Помогает. Нет, конкретно Pug я очень не люблю. Но другой, более «хэтээмэльный» шаблонизатор бывает полезен. Я уже упомянул выше о верстке независимыми блоками. Шаблонизатор позволит не копипастить эти блоки, а использовать их как компоненты.
Префиксы? В кодовом редакторе они и так есть.
Я считаю, что исходный код должен быть чистым, без префиксов. Это лишний визуальный мусор. Пусть лучше автопрефиксер этим занимается. К тому же этот плагин использует актуальную базу caniuse на основе вашего .browserlist. Пусть профит и не большой, но все же поменьше на выходе неактуальных свойств.
@iiiBird
если ты все это мастерски отточил и щелкаешь как семечки — мое уважение.
но если это уменьшает скорость верстки (а при реальных условиях это очень сильно может уменьшить скорость верстки) — то тут уже лучше подумать и не быть таким дотошным. потому что такой «идеал» не нужен никому кроме тебя самого.
т.е. если брать твои 15 страниц, о которых ты ведешь речь и верстаешь их неделю — это уже можно считать, что долго. и за эту неделю ты бы мог сверстать в 2 раза больше страниц и получить также в 2 раза больше денег.
про SASS, PUG, GULP и пр. спорить не буду. если нужно будет — сам дойдешь до этого со временем.