Google Page Speed и вёрстка

Недавно немного подискутировал в facebook с человеком на тему вёрстки, а, конкретно, Google Page Speed (PSI) и о важности высоких показателей на этапе вёрстки.

В целом, мой пост получился неудачным, поскольку хоть и выражал моё мнение относительно требований к вёрстке, но отдавал лишней эмоциональностью и не преследовал донесение мысли о том, почему же 100% в PSI это не достижение, а строгое (по крайней мере, лично для меня) требование к вёрстке.

Тезисно всё можно изложить так:

  1. НИКОГДА не забивайте на вёрстку
  2. Верстальщику тоже нужны инструменты и подходы
  3. Тест среда должна быть хреновой

Далее я попытаюсь расписать почему всегда необходимо изначально уделять вёрстке много внимания и как достигать высоких показателей без головной боли.

Вёрстка – один из важнейших шагов

Для меня, разработка конечного продукта всегда делится на определённые стадии, если мы упростим схему, отбросим все шаги с теорией и оставим только «мясо», то получим примерно такую картину:

  1. Создается прототип. Это грубо говоря простой wireframe, на котором схематично отражены все идеи проекта.
  2. Разрабатывается дизайн. Это, пожалуй, один из самых творческих и, в то же время, сложных этапов.
  3. Разрабатываются HTML макеты всех страниц.
  4. Вёрстка натягивается на программный каркас
  5. Всё это льётся в прод
  6. PROFIT (казалось бы)

И вот, в один ненастный момент, клиент узнаёт о PSI и присылает скрин:

oops…

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

В чём же дело? На каком этапе косяк?

Многие не задумываясь обвинят разработчиков, заявив, что они недостаточно хорошо поработали, и, действительно, во многих случаях можно выправить производительность, видимую PSI, без изменений самой вёрстки – оптимизировать изображения, подключить http2, минимизировать css/html/javascript, переехать на более производительный сервер наконец.

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

Но это не решает проблему на фундаментальном уровне.

Как вы, вероятно, знаете − PSI это инструмент, в основном, пригодный только для оценки фронтенда (скажем прямо – для оценки производительности сайта в целом — это довольно хреновый вариант).

И совершенно очевидно, что проблемы с PSI, произрождаются именно из проблем с вашей вёрсткой.

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

Окей, а что надо делать, чтобы не тратить время впустую и верстать сразу «хорошо»?

Тебе нужны инструменты и подход

Давно прошли времена, когда верстальщику было достаточно знать HTML/CSS для получения хороших результатов. Сегодня это скорее удел новичков, ретроградов, застрявших на одном и том же уровне, либо проектов настолько элементарных, что разворачивание dev среды для них избыточна (такие проекты мы здесь не рассматриваем).

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

Сам подход к организации вёрстки тоже крайне важен. Почему-то многие обходят этот вопрос стороной, и у них реально нет какого бы то ни было подхода, кроме «пойдет, как пойдет, главное чтоб как на макете».

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

Тебе нужны build и source версии

Использование инструментов сборки, позволяет верстальщику автоматизированно вести работу как минимум на двух фронтах:

  1. DEV — режим для разработчиков, это по сути на выходе просто собранные HTML/CSS/JS файлы
  2. PROD — применяются всевозможные автоматические оптимизации, например, оптимизация изображений, выведение Critical CSS, минификация кода и прочее.

Зачем нужно две сборки?

Лично я вижу в этом такой смысл: DEV идеально подходит самим верстальщикам для быстрой сборки и тестирования вёрстки, PROD нужен для передачи разработчикам, чтобы они сразу видели и понимали, как бэкенд должен преобразовать исходник вёрстки и отдать результат в браузер.

При таком подходе точка возникновения проблем смещается в сторону разработчиков и системных администраторов, что гораздо выгоднее, чем нерешённые проблемы на уровне вёрстки.

«Зелёный» PSI — это не только про build

Чуть выше я намеренно не стал писать сколько очков должен получать проект в какой либо версии сборки.

В идеале, вёрстка должна входить в зелёную зону в обоих версиях.

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

Всегда тестируй в худших условиях

Принцип тестирования в наиболее худших условиях у меня на вооружении давно.

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

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

Конечный продукт может размещаться на каком нибудь хостинге с доисторическим железом и хреново настроенным apache, при этом вёрстка в большинстве случаев будет сначала генерироваться, на ней может быть навешено over9000 аналитических скриптов и соответственно общий latency будет гораздо выше ожидаемого.

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

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

comments powered by Disqus