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

Серверная часть

На серверной стороне и на бэкэнде в целом улучшается параметр Time To First Byte (TTFB). Этот параметр показывает время от начала запроса до получения первого байта данных от сервера.

На начальном этапе время тратится на:

• задержку сети;
• получение IP от DNS сервера;
• установку соединения.

TTFB складывается из времени на:

• передачу пакета данных запроса;
• обработку запроса веб-приложением;
• генерацию ответа (добавление заголовков, сжатие).

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

Уменьшить это время можно несколькими способами:

• обеспечить высокую пропускную способность сети;
• предусмотреть балансировку нагрузки;
• использовать CDN доставки контента от ближайшего сервера или сервера с меньшим пингом;
• оптимизировать веб-сервер для обработки большого количества запросов:
  • облегчить правила фаервола;
  • уменьшить количество прокси;
  • настроить буферы;
  • настроить кеширование статики.
• настроить сжатие (оптимально brotli со степенью компрессии около 5, значение выше не даёт значительного уменьшения);
• уменьшить количество передаваемых заголовков в ответе;
• использование протокола http2 для обработки запросов в одном соединении;
• улучшить производительность самого веб-приложения.

Оптимизация веб-приложения

Веб-приложение обычно состоит из бэкэнда и фронтенда.

Бэкэнд

Оптимизация бэкэнда (так же влияет на показатель TTFB) сводится к следующему:

• стараться использовать статику где это возможно;
• настроить кеширование и буферизацию запросов к БД;
• настроить кеширование страниц;
• настроить кеширование скриптов прилжения (opcache, apc(u) cache, …);
• оптимизировать запросы к БД;
• минимизировать объём передаваемых данных от api.

Фронтенд

На фронтенде показателей больше:

• First Contentful Paint (FCP) — время до первой отрисовки;
• First Meaningful Paint (FMP) — время до отрисовки основной части контента;
• First Input Delay (FID) — время отклика на событие, генерированное пользователем;
• Total Blocking Time (TBT) — суммарное время задач длительностью более 50мс;
• Time To Interactive (TTI) — время до начала интерактивности элементов страницы.

Оптимизируется всё это на нескольких уровнях.

Разметка HTML

• уменьшение вложенности DOM дерева;
• минификация, использование табов для отступов.

Эффект оптимизации: быстрее наступают FCP, FMP.

Стили CSS

• вынесение критичных стилей в head > style;
• разделение стилей на куски и их дозагрузка после первого экрана;
• упрощение селекторов CSS (по методологии БЭМ);
• минификация.

Эффект оптимизации: быстрее наступают FCP, FMP, отрисовка происходит значительно быстрее на большом количестве узлов DOM дерева.

Скрипты JavaScript

• перенос, либо отложенная (async, defer) загрузка скриптов JavaScript;
• requestAnimationFrame для анимаций;
• requestIdleFrame для длительных задач;
• WebWorkers для сложных длительных задач;
• ServiceWorkers для обеспечения кеширования запросов;
• ленивая загрузка данных (Infinite Scrolling);
• минификация.

Эффект оптимизации: значительное улучшение всех показателей при большом объёме JavaScript кода.

Изображения

• ленивая загрузка изображений;
• правильный выбор формата изображений (jpeg — фото, png — чертежи или логотипы или постеры);
• оптимизация изображений для веб:
  • сжатие изображений по размеру в пикселях;
  • использование векторной графики или CSS3 где это возможно;
  • сжатие изображений по качеству;
  • использование современных способов сжатия (webp).

Эффект оптимизации: быстрее наступают FCP, FMP, уменьшается TTI (по наблюдениям), бонусом меньше трафика.

Шрифты

• ленивая загрузка веб-шрифтов, в идеале использование системных - Web safe шрифтов;
• уменьшение количества шрифтов;
• использование шрифтов только нужных языков;
• выбор меньшего количества начертаний (font-weight).

Эффект оптимизации: быстрее наступают FCP, FMP.

Список оптимизируемого будет пополняться, пока это всё, что вспомнил. =)

Оптимизируя приложения следите за своим временем. ;) Правило 20%/80% работает и здесь: за 20% времени можно улучшить производительность приложения на 80%, остальное время чаще всего тратится на долгое ковыряние за десятки милли- и даже микросекунд.

Может кому-то показаться странным, зачем переходить с полноценной IDE с кучей возможностей на редактор, из которого даже выйти сложно. А в PHPStorm или IDEA одной мышью программировать можно. В моём случае переход был инициирован двумя вещами: желание использовать инструмент матёрых программистов и желание хоть как-то продолжать работать =D

Преимущества VIM перед IDEA

• быстрое начало работы с проектом: 200 мс против 2..3 минут на моём железе
• быстрая работа с текстом: обрамление строк списком HTML за 2,5 с vap<C-y>,ul>li*
• низкое потребление ресурсов: RAM 500-700 МБ при работающем NodeJS сервере LSP против 4+ ГБ с IDEA
• конфигурируемость: сами решаете как и что будет работать, используя VIMScript, плагины
• при отсутствии большого количества ресурсов работай удалённо по SSH, а с tmux вообще сказка
• работать можно с намного большим количеством проектов одновременно

Начало освоения VIM

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

Сначала не понимал, зачем нужны эти режимы, если можно находясь только в одном режиме работать с текстом как в обычном редакторе. Пиши и пиши, даже мышь вроде работала для перемещения курсора =)

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

Вынужденный переход на VIM с IDEA

IDE Intellij IDEA очень хороша по своему функционалу. Из используемого мной это:

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

Однако однажды перейдя на удалённую работу, работая с ноутбука и имея 4 гигабайта оперативки понял, что работа встаёт колом. Оперативка съедалась вся при запущенном браузере (45%) и загруженной IDEA. При этом по окончании рабочего дня своп использовался на 25%, это при условии, что был включён zRam. Так продолжать работать было невозможно. И тут я решил провести эксперимент и перейти на VIM полностью.

До очередной попытки чаще всего использовал VIM для правок конфигов на серверах.

Начал всё с чистого листа: создал новый vimrc файл и помаленьку стал добавлять в него нужное для работы.

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

if empty(glob('~/.vim/autoload/plug.vim'))
  silent !curl -fLo ~/.vim/autoload/plug.vim --create-dirs
        \ https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim
  autocmd VimEnter * PlugInstall | source $MYVIMRC
endif

Если менеджер плагинов не установлен при запуске редактора, он скачивается и запускается установка плагинов, указанных в директивах:

call plug#begin('~/.vim/plugged')

" здесь плагины

call plug#end()

Далее пошёл по просторам интернетов искать плагины, которые были нужны при работе в IDE IDEA (ну или PHPStorm).

Подсветка синтаксиса есть отдельно для каждого языка, но есть один мультиязыковый плагин — sheerun/vim-polyglot, объединяющий разные языки.

Для автодополнения решил использовать neoclide/coc.nvim, т.к. он позволяет получить результат как в VSCode.

Для вставки сниппетов пользуюсь тем же coc (ссылка на конфиг будет в конце поста), плюс honza/vim-snippets — набор готовых сниппетов, можно создавать и свои.

Чтобы быстро переходить по файлам с помощью fuzzy (нечёткого) поиска воспользовался:

Plug 'junegunn/fzf', { 'do': { -> fzf#install() } }
Plug 'junegunn/fzf.vim'

оба плагина нужны.

Для навигации по файлам использую preservim/nerdtree, как самый популярный. Конфигурируется отображение иконок типов файлов, добавляются плагином ryanoasis/vim-devicons, так что красоту навести можно.

Т.к. работаю с html разметкой, удобно написать emmet строку ul>li*5 и получить список. Это делает mattn/emmet-vim.

Для работы с базами данных есть классный плагин от tpope: tpope/vim-dadbod. Указываете в переменной g:db строку соединения с базой и спокойно отправляете запросы на исполнение командой DB. По умолчанию отправляется весь буфер.

Для рефакторинга можно использовать разные техники, но для PHP решением стал adoy/vim-php-refactoring-toolbox. Умеет создавать методы из кусков кода, переименовывать методы, переменные и многое другое.

Итоги перехода с IDEA на VIM

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

Кому интересно облегчение VIM, сделал статусную строку без плагинов в 5 строк.

Теперь как говорится, работать могу даже с хлебушка/холодильника/калькулятора. =)

На данный момент неудобно только редактировать множество строк в БД. Для этого пользуюсь mysql-workbench.

Как и обещал, конфиг vimrc на момент написания поста.

Желаю удачи в переходе на редактор VIM!

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

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

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

const doc = window.document;
const links = doc.querySelectorAll("a"); // любой нужный селектор
const linksCount = links.length;
const currentURL = doc.URL;

for (let i = 0; i < linksCount; i++) {
  let linkURL = links[i].href;

  // linkURL == currentURL, если не надо светить уровни выше
  if (currentURL.startsWith(linkURL)) {
    links[i].classList.add("active");
  }
}

Современное краткое решение:

(function() {
  [...this.querySelectorAll("a")]
    .filter(a => this.URL.startsWith(a.href))
    .forEach(a => a.classList.add("active"));
}.bind(window.document)());

Останется только назначить стили активным ссылкам с классом active.

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

Задача

Задача проста — воспользоваться шаблонами строк для отображения данных из массива. Сделать это можно несколькими способами:

• сгенерировать текста в самом PHP
• воспользоваться готовыми шаблонизаторами например Twig, Blade, Smarty, …
• написать небольшую функцию для преобразования определённой подстроки в текст по данным из ассоциативного массива

Решение

Я предпочёл последний вариант, несмотря на подключенный Twig в проекте.

Первый вариант решения задачи выглядит следующим образом:

<?php

/**
 * PHP function to render string path template using nested array.
 * Renders template string like "Nested array item value: {data.some.nested.item.value}"
 * @param string $template
 * @param array $data
 * @return string
 */
public static function renderDataTemplate(string $template, array $data): string
{
  return preg_replace_callback('/{([^{}]+?)}/', static function ($v) use ($data) {
    $temp = &$data;
    foreach (explode('.', $v[1]) as $key) {
      $temp = &$temp[$key] ?? null;
      if ($temp === null) {
        return null;
      }
    }
    return $temp;
  }, $template);
}

Данная версия позволяет выполнять множественную замену вложенных шаблонов, применяя функцию несколько раз для шаблона вида:

{variables.{data.item.type}.{id}.name}

так как разворачивает только ближайшие фигурные скобки.

Актуальная версия функции PHP для рендера шаблона по данным из ассоциативного массива: PHP function to render string path template using nested array.

Использовать normalize.css практично и менее затратно. Сейчас расскажу почему и что меня подвело к использованию normalize.css вместо reset.css.

Всё-таки normalize.css это не reset.css

Как бы это не было очевидно, разница большая между сбросом и нормализацией. Задача reset.css — сбросить все возможные стили для переопределения потом в коде. Почему таки задумался о разнице между двумя способами привести стили к одному виду?

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

А normalize.css решает в том числе и эту проблему. В итоге сделал выбор в сторону normalize.css против reset.css. Вместе с системными шрифтами это решение позволяет меньшими затратами достичь нужного результата и быстрее предоставить пользователю контент.

Где скачать normalize.css

Известный источник с самым большим комьюнити — normalize.css от Nicolas Gallagher. Официальный сайт проекта necolas.github.io/normalize.css.

Так же существует более лёгкая версия normalize.css для топовых браузеров: sindresorhus/modern-normalize.

В 2015 году писал CSS стиль для stylish, для подсчёта изображений без атрибута alt, чтобы видеть где и сколько забыл проставить.

Да, считать средствами css уже давно можно

Посмотрев в доки на mozilla.org, увидим что в спецификации CSS 2.1, а это аж в середине 2011 года, появилась возможность использовать счётчики для их инкрементирования через свойства CSS. Кто не знает, как и что — привожу краткий пример для нумерации заголовков.

article {
  counter-reset: h;
}
article h2 {
  counter-increment: h;
}
article h2:before {
  content: counter(h) '. ';
}

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

Что я сделал

Реализация старая, оставлю как есть.

body {
	counter-reset: noalt extLinks;
}

img:not([alt]) {
  counter-increment: noalt;
}

a[href ^= 'http'] {
	counter-increment: extLinks;
}

body:after {
  content: 'noalt: ' counter(noalt) ', external links: ' counter(extLinks);
  position: fixed;
  bottom: 0;
  right: 0;
  z-index: 1000000;
  padding: 2px 16px;
  background: rgba(0,0,0,0.75);
  color: #0f0;
  font-size: 11px;
  line-height: normal;
}

В коде выше помимо подсчёта изображений без атрибута alt ещё считал количество внешних ссылок. Критерием было наличие http в начале ссылки, что недостоверно, т.к. отслеживает только абсолютные ссылки. Доработайте сами. Тут показал только пример.

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

Системные шрифты — что это такое

Системные шрифты — это шрифты, предустановленные в операционной системе по умолчанию. Для каждой версии операционной системы свой список системных шрифтов по умолчанию, вот краткий список:

Windows

Источник

Mac OS

Источник

Linux

…

iOS

Источник

Android

Источник

Зачем использовать вместо веб-шрифтов

Да, используя веб-шрифты, например Google Fonts, получится очень красивая типографика. Здесь есть большой простор для фантазии, многообразие шрифтов и их бесплатность порадует каждого. Но не всегда пользователя.

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

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

Что такое эти системные семейства шрифтов

Ещё такие шрифты называют веб-безопасными. Список системных шрифтов на W3C Schools. Так же смотрите запись в блоге Scott Granneman.

Если интересуют надёжные источники — в блоге Scott Granneman перечислены ссылки.

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

В посте это опущу, оставлю пару ссылок:

Using UI System Fonts In Web Design: A Quick Practical Guide System Fonts in CSS

Мой вариант

Полазив по GitHub, Medium и некоторым другим ресурсам, пришёл к такому виду стека системных шрифтов 2019 года:

:root {
  --font-family-sans-serif: -apple-system, BlinkMacSystemFont, "Segoe UI", "Roboto", "Helvetica Neue", Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
  --font-family-sans-serif-condensed: "DINNextW01-CondensedMed", "AvenirNextCondensed-Bold", "Futura-CondensedExtraBold", HelveticaNeue-CondensedBold, "Ubuntu Condensed", "Liberation Sans Narrow", "Franklin Gothic Demi Cond", "Arial Narrow", "Roboto Condensed", sans-serif-condensed, Arial, "Trebuchet MS", "Lucida Grande", Tahoma, sans-serif;
  --font-family-serif: Georgia, Times, Times New Roman, serif;
  --font-family-mono: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace;
}
.condensed {
  font-family: var(--font-family-sans-serif-condensed);
  font-stretch: condensed;
}

GitHub Gist

Ещё советую проверить, какие символы видны при использовании стандартных шрифтов на этом сайте.

Захотел попробовать сделать для своего блога на Jekyll календарь с использованием Liquid template engine. Не хотелось использовать JS библиотеки, решил написать календарик на чистом Liquid.

Предыстория

Делал календарик для отображения даты публикации постов. Решил не заморачиваться с написанием или поиском плагинов, взялся делать самостоятельно. К тому же, изучая CSS grid system понял, что делая минимум телодвижений можно заставить отображаться сквозной “список” дней с разбивкой на недели.

Jekyll календарь на чистом Liquid

Первым делом думал о получении даты начала месяца. Сделать это просто:

{{ 'now' | date: '%Y-%m-01' }}

Следующее что стоило сделать — каким-то образом перебрать все дни. Сделать это можно легко. Благо в сутках 24 часа =)

{% raw %}{% for i in (0..30) %}
{% assign day = 86400 | times: i | plus: month_starts_ts %}
{% endfor %}{% endraw %}

Оставалась ещё проблемка: выводить нужно дни до первого числа месяца, чтобы правильно отобразить календарь средствами CSS grid. Пришлось оглядываться назад на недельку и вставлять заглушки для дней с прошлого месяца. Можно конечно и отображать, но делать цвет шрифта приглушённым.

{% raw %}
{% for i in (-7..30) %}

{% assign day = 86400 | times: i | plus: month_starts_ts %}
{% assign dow = day | date: '%u' %}
{% assign m = day | date: '%m' %}

{% unless fd %}
{% if dow == '7' %}{% assign fd = true %}{% endif %}
{% continue %}
{% endunless %}

{% if month == m %}

{% case dow %}
{% when '6' %}<span class="calendar__we {{ has_posts }} ">
  {% when '7' %}<span class="calendar__we {{ has_posts }}">
  {% else %}<span class="{{ has_posts }}">
{% endcase %}{{ day | date: '%e' }}</span>

{% else %}<span></span>{% endif %}

{% endfor %}
{% endraw %}

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

Осталось отобразить наличие опубликованных постов в определённый день. С наскоку заюзать фильтр по дате не удалось, сделал через обычное условие.

Итоговый вид скрипта:

{% raw %}
{% assign month_starts = 'now' | date: '%Y-%m-01' %}
{% assign month_starts_ts = month_starts | date: "%s" %}
{% assign month = 'now' | date: "%m" %}
{% assign fd = false %}
<div class="calendar">
<b>Пн</b><b>Вт</b><b>Ср</b><b>Чт</b><b>Пт</b>
<b class="calendar__we">Сб</b>
<b class="calendar__we">Вс</b>
{%- for i in (-7..30) %}
{%- assign day = 86400 | times: i | plus: month_starts_ts %}
{%- assign dow = day | date: '%u' %}
{%- assign m = day | date: '%m' %}
{%- assign dayf = day | date: "%Y-%m-%d" %}
{%- unless fd %}
{%- if dow == '7' %}{% assign fd = true %}{% endif %}
{%- continue %}
{%- endunless %}

{%- if month == m %}
{%- assign has_posts = '' %}
{%- for post in site.posts %}
    {%- assign d = post.date | date: "%Y-%m-%d" %}
    {%- if d == dayf %}{% assign has_posts = 'calendar__ext' %}{% break %}{% endif %}
{%- endfor %}
{%- case dow %}
{%- when '6' %}<span class="calendar__we {{ has_posts }} ">
  {%- when '7' %}<span class="calendar__we {{ has_posts }}">
  {%- else %}<span class="{{ has_posts }}">
{%- endcase %}{{ day | date: '%e' }}</span>
{%- else %}<span></span>{% endif %}
{%- endfor %}
</div>
{% endraw %}

Вёрстка календаря средствами CSS grid

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

.calendar {
  display: grid;
  grid-template-columns: repeat(7, 2rem);
  line-height: 2rem;
  text-align: center;
}
.calendar__we {
  color: #e22;
}
.calendar__ext {
  font-style: normal;
  position: relative;
  &:after{
    content: '•';
    position: absolute;
    top: -.45em;
    right: .125em;
  }
}

Заключение

Такой календарь удобно использовать скорее для бо́льших промежутков времени, т.к. всей картины периодичности постинга не видно. Однако, это мой первый опыт доскональной работы с Jekyll Liquid template engine и реализации календаря с использованием модного и удобного CSS grid.

В детстве очень любил простую игру, где нужно уничтожать блоки одного цвета, чтобы очистить экран. Как начал заниматься изучением HTML5 canvas, решил реализовать её.

Поиграть можно тут: демка.

Суть игры

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

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

Начало реализации игры, знакомство с html5 canvas

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

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

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

Оптимизация отрисовки html5 canvas

Ладно, блоки уничтожаются. Процесс обхода оптимизирован. Но всё же игра на html5 canvas тормозила при уничтожении большого количества блоков. Причина была в том, что на перерисовку html5 canvas нужно время. Если блоков достаточно много (ведь играть на поле маленького размера не интересно), перерисовка занимала порой более 1 секунды.

Нужно было срочно с этим разбираться. Стал искать решения в интернетах.

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

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

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

Код первоначальной версии игры можно посмотреть на github: block-destruction-game.

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

Тернистый путь

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

До того, как я обнаружил для себя reset.css, приходилось каждый раз указывать своё значение margin, padding и box-sizing, сбрасывать значение list-style для немаркированных списков, потому как при первоначальной вёрстке они чаще всего используются для построения многоуровневых меню, иногда и сами списки перестилизуются.

Чтобы всего этого избежать, можно воспользоваться минимальным файлом сброса стилей.

Легковесное решение

Можно пойти по пути минимализма и сбросить только основные свойства, которые чаще всего требуют сброса. Раньше делал так:

* {
  margin: 0;
  padding: 0;
  box-sizing: border-box;
}

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

Позже нашёл простое современное решение — минимальный и в то же время более полноценный вариант сброса стилей minireset.css

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

С приходом HTML5 я стал задаваться вопросом: как правильно использовать семантическую вёрстку используя новые теги? В посте поделюсь опытом вёрстки этого блога с применением семантических тегов.

С чего всё началось

Верстая разные проекты, в голову приходили мысли: зачем нужны все эти <main>, <nav>, <section>? Ведь можно и дальше спокойно верстать дивами.

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

Первое знакомство с семантическими тегами

Первый раз я с ними встретился, когда пошли слухи об HTML5. Шаблон типовой страницы был прост в отличие от XHTML.

Например:

<!DOCTYPE html>

вместо

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

выглядит намного лучше. Да ещё и экономия. К тому же, стало возможным опускать тег <html> в корне документа.

Раньше не обращал внимания на семантические теги, но хотелось везде их использовать. Модно же.

Доступность контента

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

Тогда я познакомился с элементом <nav>, который служит для определения блока навигации. Позже узнал¹, что использовать связку nav > ul совсем не обязательно и даже вредно, т.к. читалки натыкаются на список и не могут перечислить все названия ссылок за один проход.

SEO

Немного позже, столкнувшись со статейным контентом стало интересно, что существуют такие теги, как <header>, <article> и <footer>. Тег <article> позволяет определить зону с материалом. Это помогает не только семантически правильно разметить контент сайта, но и помочь сайту лучше выглядеть в поисковой выдаче.

Каркас сайта

Чуть более детально разбираясь в структуре сайта и выделяя семантические блоки, обнаружил, что есть полезный тег <main>. Он определяет основную часть сайта с контентом. При этом использоваться этот тег может только один раз, что позволяет при написании стилей писать селектор main и не использовать классы. Это ещё один шаг к написанию css фреймворков с низким порогом вхождения и лаконичностью.

Собственно, блог

Перейдём к практике.

Этот блог я стараюсь верстать, используя минимум телодвижений, без единого фреймворка css/js. Использую максимум семантики, пытаясь обеспечить лучшую доступность и адаптивность для лучшего пользовательского опыта.

Итак, у нас есть основной каркас сайта, который чаще всего приводится к виду:

<!DOCTYPE html>
<html lang="ru">
  <head></head>
  <body>
    <header></header>
    <main></main>
    <footer></footer>
  </body>
</html>

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

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

<nav>
  <a href="">Link 1</a>
  <a href="">Link 2</a>
  <a href="">Link 3</a>
</nav>

Дальше у нас следует основной контент страницы. В нём могут присутствовать сайдбары с навигацией или чем-то другим, а так же набор материалов, либо один материал. Например:

<main>
  <aside></aside>
  <article></article>
</main>

Статья обычно состоит так же, как и страница из заголовка (шапки), footnotes (подвала) и контента. В общем случае, структура такова:

<article>
  <header>
    <h1>Article title</h1>
    <p>Author, <time>2019-07-03</time>
  </header>
  <div>Article content</div>
  <footer>
    <small>viewed 15 times</small>
  </footer>
</article>

На этом о моей практике вёрстки семантическими тегами всё.

Что дальше?

Позже планируется раскрыть темы:

• разметка страниц при помощи микроформата
• использование h1 в качестве заголовка статьи и наличие h1 в теле статьи
• мой способ адаптивной вёрстки сайтов
• рассуждения на тему SEO

Полезные материалы

Эта статья помогла определиться с вариантом реализацией навигации

1. Пост на тему списков в навигации с большим количеством комментариев

Часто при работе с изображениями встаёт задача оптимизировать изображения для показа в Веб. Инструментов достаточно много, в том числе и онлайн, однако больше контроля над процессом и более эффективный результат можно получить используя утилиту convert из библиотеки ImageMagick.

Часто нужно сделать так, чтобы изображения подгружались в полном размере, чтобы не плыла вёрстка или не было пустого пространства до полной загрузки изображения. Да и к тому же будет достигнут эффект размытия при загрузке изображения.

Реализовать это очень просто:

convert -strip -interlace Plane -quality 85 input-file.jpg output-file.jpg 

Подробнее про опции:

-strip убирает лишнюю метаинформацию
-quality устанаввливает качество результата в процентах; рекомендуется в диапазоне 75..90
-interlace Plane определяет режим подгрузки изображения, в данном случае всё изображение при загрузке в браузере будет отображаться постепенно из размытого состояния к более чёткому.

При работе с PNG изображениями можно достичь меньшего размера, если урезать палитру до минимально необходимого набора цветов:

convert -colors 8 input-file.jpg output-file.jpg 

Где:

-colors 8 указывает на количество цветов в выходном файле.

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

#!/usr/bin/env bash

find . -name '*.jpg' -exec mogrify \
    -filter Triangle \
    -define filter:support=2 \
    -unsharp 0.25x0.25+8+0.065 \
    -dither None \
    -posterize 136 \
    -quality 82 \
    -define jpeg:fancy-upsampling=off \
    -define png:compression-filter=5 \
    -define png:compression-level=9 \
    -define png:compression-strategy=1 \
    -define png:exclude-chunk=all \
    -interlace Plane -colorspace sRGB \
    -strip $1 {} + 

Для быстрого создания изображений в формате WebP из JPEG можно воспользоваться этим:

for i in *.jpg; do cwebp -q 80 $i -o $i.webp;done

На выходе получим файлы с расширением .jpg.webp.

Способ с обработкой поддиректорий с изображениями и параллельным выполнением:

find . -name "*.jpg" | parallel -eta cwebp {} -o {.}.webp

На выходе получим рядом лежащие файлы с расширением .webp.

Бонус для пишущих на PHP — определение поддержки WebP на стороне сервера:

$has_webp = strpos($_SERVER['HTTP_ACCEPT'], 'image/webp') !== false || strpos($_SERVER['HTTP_USER_AGENT'], ' Chrome/') !== false;