Меня интересует, что можно почитать на тему оптимизации работы верстки. Также, возможно, в сочетании с JS оптимизацией.
Как вообще можно "ускорять" работу сайта? Речь не об оптимизации первой загрузке (склейки минификации и т.д.), не о работе с сетью (интересует не скорость загрузки ресурсов, а скорость рендеринга и минимизация затрат при обновлении DOM) и не о скорости JS (оптимизация самого JS кода, избегание блокирующих оптимизатор конструкций и т.д.)
Речь именно об оптимизации верстки: как сделать "чтоб тут не лагало при скролле", а тут при наборе текста. Также интересует оптимизация (именно с точки зрения производительности) под мобильные браузеры.
Хотелось бы получить информацию в стиле: (это не реальные советы, а примеры)
- использование 3д-трансформаций поможет сделать...
- если убрать все флексбоксы и везде сделать абсолютное позиционирование - все будет работать быстрее...
- табличная верстка быстрее блочной (или наоборот)...
- чтобы снизить частоту reflow & repaint вы должны избегать...
- заменяйте SVG на PNG...
и т.д.
Буду рад ссылкам на статьи или книги, описывающие механизмы рендеринга с упором на производительность.
Меньше DOM элементов.
Меньше вложенности DOM элементов.
Меньше ивентов
Минус jQuery
Меньше скриптов и библиотек
Меньше CSS
Минус Bootstrap и прочие тяжелые либы
Меньше repaint'ов
Меньше манипуляций с DOM
Больше оптимизации картинок
Меньше кастомных шрифтов
Если шрифты кастомные - использовать ровно необходимый charset и вырезать лишнее
...
PS: SVG на PNG не меняйте. Сомнительная экономия на спичках, а качество сильно хуже, возможностей меньше. Да и вообще "фу, прошлый век"
Ту же сеть не сбрасывайте со счетов - тот же HTTP/2 с его потоком (прощай, конкатенация) одновременно доставит в браузер все нужное, что ускорит прорисовку. А с новым server push все самое нужное вообще прилетает вместе с html. В общем, тут все связано.
sim3x: Да я в курсе. Там, в принципе, в 105 кажется слайде - единственная точная информация из этого спича. Все остальное - синтетические тесты и подгонка под свой маркетинг. Многое не учтено, много сказано с точки зрения CDN а не реальных приложений, и по packet loss там вопросов к их тестам много... В общем, нюансов вагон и тележка. Фастли еще те жуки. В целом, конечно H2 не является волшебной палочкой, да. Но все же, in real world он прекрасно работает и таки действительно заметно и ощутимо ускоряет. А также снимает часть работы с команды, а экономия ресурса - это профит. Особенно в long term.
sim3x: конкатенация и спрайты. Генерация этого добра хоть и автоматизирована, но тоже время на поддержку этого всего. В моем случае с WP иногда бывает неудобно, особенности платформы. То же касается загрузки скриптов и стилей только там где надо вместо одного бандла. Картинки тоже, вместо одного большого спрайта - ровно то, что нужно на этой странице. И всем этим добром, предоставленным со стороны фронтенда в разобранном виде, а не одной большой соплей, мне на бекенде управлять гораздо комфортнее и быстрее. Фронтендеру проще - он забилдил автоматом сборку и в ус не дует. А мне потом это надо оптимизировать под максимальную производительность. По мелочи, но в сумме какая-то копеечка на каждом проекте. Меньше обезьяньей работы.
sim3x: не люблю его и не использую, у меня все fine-tuned. Да и не в этом дело. Зачем мне грузить слайдер, лайтбокс, скроллимейт и еще десяток скриптов + парочку их css на каждой странице, если нужны они только, допустим, на главной? Или валидация форм нужна только на странице контактов. Примеров масса. То же с большими спрайтами. Во-первых, мы сильно увеличивает общий весь страницы и самый первый приход пользователя - отдаем ему тупо все, а там видно будет - пригодится или нет. И если мы грузим это все на каждой странице - получаем как раз замедление рендера - браузер то на каждой странице будет парсить все скрипты и стили, даже этот десяток не используется. В общем, с точки зрения оптимизации это все надо разделять. И вот тут HTTP/2 в помощь. Это один из примеров. Можно углубляться, но смысла нет. Ответ очень прост - если это корпоративный сайтик небольшой или портфолио - все это не важно. Если это high-load и крупный проект - тогда это мегаважно. Собственно из опыта хайлоада все это и выросло у меня в кастомные решения.
Таймеры и слушатели (подписка на события) - основные лангольеры.
Для анимации - используем CSS
Обработчики событий (стараемся использовать реже) - JS
Для сложных/периодических вычислений: Asm.js
Ответ на "чтобы не лагало при...": используем ИЕРАРХИЧЕСКИЙ контроль слушателей событий и включаем/отключаем изоляцию целых "ветвей дерева" событий в различных ситуациях: ввод в поле, нахождение во вьюпорте и т.д.
Я бы хотел увидеть какое-либо подтверждение о тяжести обработчиков. https://jsfiddle.net/sjLp1u9g 1000 обработчиков, количество сильно превышающее адекватное значение практически на любом сайте, съедают всего 3мс.
Простой
