Один из сотрудников Google в свободное время разработал новый алгоритм сжатия Zopfli, который на 3,7-8,3% эффективнее, чем стандартная библиотека zlib на максимальном уровне сжатия. Изначально алгоритм создавался для формата сжатия без потерь WebP, но его можно применять и для другого контента.

Новый алгоритм является реализацией стандартных алгоритмов Deflate, поэтому он совместим с zlib и gzip, а разархивирование данных уже поддерживается всеми браузерами. Достаточно подключить Zopfli на сервере. Например, его можно использовать с веб-сервером Nginx без изменений в модуле gzip, просто указав новый «прекомпрессор».

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

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

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

tl;dr: меньше кода = меньше парсинг/компиляция + меньше передача + меньше распаковка

Сеть

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



Это может стать проблемой даже в странах первого мира, поскольку эффективный тип сетевого соединения у пользователя необязательно 3G, 4G или WiFi. Вы можете сидеть в кафе с WiFi, но быть подключённым к хотспоту через сотовую связь со скоростью 2G.

Ускорить доставку элементов фронтенда на устройство пользователя можно несколькими способами. Разработчик Артём Белов из самарского офиса норвежской компании Cxense попробовал самые многообещающие: HTTP/2, Server Push, Service Worker, а также оптимизацию в процессе сборки и на стороне клиента. Итак, что же нужно сделать, чтобы сократить время отклика приложения до минимума?

Выясняется, что алгоритмы сжатия существуют уже давно. Это произошло где-то в июне — видимо, где-то над Самарой пролетал метеорит и идея проверить новые алгоритмы сжатия, Zopfli и Brotli, пришла мне и парню из соседней компании. Больше чем уверен, вы читали его статью, это Александр Субботин. Статья разошлась на Medium, и он известен, а я нет.

Одна из тестовых фотографий, сжатие без потерь на 41%

Для сжатия изображений без потерь принято использовать PNG. Его обычно применяют для логотипов, скриншотов, диаграмм, где есть сплошные области с одинаковым цветом. Такие области сжимаются лучше всего: все lossless-кодеки используют классический RLE, то есть кодирование повторов. В некоторых случаях это обеспечивает даже лучший коэффициент сжатия, чем JPEG. И никаких искажений.

Но PNG не используют для фотографий — файлы слишком большие. Однако сейчас, с появлением кодеков нового поколения, ситуация должна измениться. Фотографии будут кодировать без потерь в файлы меньшего размера, а PNG наконец-то уйдёт на покой (см. результаты тестирования в конце статьи).