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

Первым делом уменьшайте размер в пикселях, а не качество: фотография 6000×4000 в карточке шириной 1200 пикселей это чистые потери. Один этот шаг убрал 77% веса тестового снимка.

Формат выбирается под тип картинки: фотографиям WebP или AVIF, скриншотам и интерфейсам сжатие без потерь, логотипам SVG, анимациям анимированный WebP вместо GIF.

AVIF при равном качестве весит вдвое меньше JPEG, но кодируется примерно в пятнадцать раз дольше, поэтому генерировать его нужно на этапе сборки.

Метаданные съёмки занимают от 10 до 30 КБ на файл и в вебе не нужны ни для чего.

Сжатие с потерями на тексте и резких границах даёт видимые артефакты: скриншоты и логотипы жмутся только без потерь, зато на 20–60%.

Шаг, который экономит больше всех остальных

Прежде чем подбирать кодек и качество, посмотрите на фактические размеры. Фотография 6000×4000 в карточке шириной 1200 CSS-пикселей отдаёт браузеру в двадцать пять раз больше пикселей, чем нужно обычному экрану, и вшестеро больше, чем нужно экрану с двойной плотностью.

В замерах автора чеклиста одно только уменьшение до реально отображаемого размера ужало тестовое изображение с 4,7 МБ до 1,1 МБ. Это минус 77% при нулевой потере качества: пиксели, которых не видно, просто перестали передаваться.

Как определить нужный размер:
Отправная точка это ширина контейнера в CSS-пикселях. На обычном экране она же и есть нужная ширина в физических пикселях, на плотных экранах нужно кратно больше: у части ноутбуков это двойка, у большинства современных смартфонов тройка. Поэтому правильный инструмент здесь не фиксированный множитель, а атрибут srcset с несколькими вариантами файла: браузер сам возьмёт тот, что соответствует плотности экрана посетителя.

Формат под тип изображения, а не один на всё

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

• Фотографии — WebP (на 30–50% меньше JPEG) или AVIF (ещё примерно на 30% меньше WebP).
• Скриншоты и элементы интерфейса — PNG или WebP без потерь.
• Логотипы и иконки — SVG: вектор весит копейки и масштабируется без предела.
• Анимации — анимированный WebP вместо GIF, это экономит 60–80% веса.

Отдельно про текст. Сжатие с потерями на буквах и резких границах создаёт заметные ореолы вокруг символов, поэтому скриншоты и логотипы обрабатываются только алгоритмами без потерь. Инструменты вроде oxipng ужимают такие файлы на 20–60%, не меняя при этом ни одного пикселя.

Конвертация и сжатие — это два разных действия

Перевод PNG в JPEG экономит место. Сжатие получившегося JPEG экономит ещё столько же, и про этот второй проход регулярно забывают. Для фотографий рабочий диапазон качества это 75–82%: от стопроцентного такая картинка визуально неотличима, а весит заметно меньше.

Метаданные, которые вы отдаёте бесплатно

В файле с камеры или из редактора лежат EXIF, координаты GPS, модель камеры и метки программы обработки. Для показа в браузере это бесполезный груз весом от 10 до 30 КБ на файл, за одним исключением: тег ориентации. Часть снимков с телефона хранит пиксели неповёрнутыми и полагается на него, поэтому поворот нужно применить к самим пикселям до того, как метаданные срежутся, иначе фотографии лягут набок. На каталоге из тысячи товарных снимков набегает до 30 МБ трафика ни за что, а координаты съёмки вдобавок могут оказаться данными, которые вы не собирались публиковать.

AVIF: что это и почему его нельзя кодировать на лету

AVIF (AV1 Image File Format) выпущен Alliance for Open Media в 2019 году и построен на внутрикадровом кодировании видеокодека AV1. По сути это инструменты сжатия одного кадра AV1, упакованные в самостоятельный контейнер для картинок.

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

Сколько это в килобайтах

В сравнительном тесте брали пейзажный кадр 1920×1080 с градиентами неба, текстурой листвы и границами зданий, исходник в BMP весил 5,93 МБ. Целевое качество задавали по метрике структурного сходства: она сравнивает сжатую картинку с исходной, где единица означает полное совпадение, а 0,92 примерно соответствует порогу, за которым разницу перестают замечать глазом. Результаты:

На листве и градиентах неба разница видна и глазом: JPEG на низком битрейте показывает цветовые блоки, у AVIF артефактов практически нет. Отвечают за это многоуровневые фильтры внутри цикла кодирования, которые заглаживают границы блоков и восстанавливают детали текстур.

Плата за это — время. Кодирование AVIF примерно в пятнадцать раз дольше JPEG и вчетверо дольше WebP, потому что выбор разбиения и типа преобразования требует перебора с оптимизацией. Зато декодирование медленнее JPEG всего вдвое, и на просмотр это почти не влияет. Практический вывод прямой: генерируйте AVIF заранее, на этапе сборки. Сервисы доставки изображений кодируют его и по запросу, но только с кешированием результата, чтобы платить за кодирование один раз на вариант, а не на каждого посетителя. Чего делать нельзя, так это кодировать заново при каждом обращении.

Как отдавать современный формат и не потерять старые браузеры

Поддержка AVIF в браузерах составляет примерно 96%, но подстраховка всё равно нужна. Делается она тегом <picture>: браузер берёт первый формат, который понимает, и до остальных не доходит.

Атрибуты width и height здесь не декоративные: без них браузер не знает пропорций до загрузки файла и подвёрстывает страницу заново, когда картинка приходит. Это тот самый прыжок содержимого, который портит метрику визуальной стабильности. Атрибут loading=lazy убирает изображения за пределами первого экрана из очереди, конкурирующей за отрисовку главного элемента.

Именно за пределами: на картинку первого экрана его ставить нельзя. Отложенная загрузка задержит ровно тот элемент, скорость появления которого и меряет метрика отрисовки основного содержимого. Там уместен противоположный по смыслу fetchpriority=high.

Сжатие в браузере: почему это вообще возможно

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

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

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

Вся тяжёлая работа уходит из главного потока

Перекодирование снимка 4000×4000 нагружает процессор настолько, что в главном потоке интерфейс замирает, а браузер показывает предупреждение о зависшей странице. Поэтому весь конвейер живёт в Web Worker: главный поток отвечает за выбор файлов, превью и состояние, а рабочий поток декодирует через createImageBitmap, применяет преобразования и кодирует через OffscreenCanvas. Именно через него, а не через canvas.toBlob: последний это метод DOM-элемента, а DOM в рабочем потоке отсутствует, и нужный метод там называется convertToBlob.

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

Три ошибки, которые ищутся дольше всего

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

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

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

Заголовки безопасности ломают рабочие потоки молча:
Блокирует загрузку скрипта заголовок Cross-Origin-Embedder-Policy: он требует, чтобы каждый сторонний ресурс отдавал разрешающий заголовок, иначе браузер молча его отбрасывает. Cross-Origin-Opener-Policy на это не влияет, но включают их обычно парой, поэтому и ломается всё в одном релизе. Любое изменение заголовков безопасности проверяйте на настоящем развёрнутом стенде, а не только на машине разработчика.

Что это даёт в цифрах

Скриншот 1920×1080 проходит такой путь: исходный PNG весит 2,1 МБ, после уменьшения и перевода в WebP с качеством 75% — 186 КБ, то есть минус 91%. Тот же кадр в AVIF занимает 102 КБ, минус 95% от исходного.

Именно эти проценты и отделяют страницу, которая грузится четыре секунды, от страницы, которая укладывается в одну.

Что забрать с собой

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

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

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

Одним из поводов для разочарования в области аппаратных форматов изображений всегда было медленное развитие. Разработчики обычно не решались поставлять текстуры в новом формате, пока он не становился повсеместно доступным — поддерживался большинством целевого железа и всеми вендорами без исключения. Сегодня три вендора предлагают собственные форматы аппаратного сжатия текстур на лету: ARM AFRC, ImgTec PVRIC4 и Apple Metal Lossy. Игнасио Кастаньо исследовал все три и сравнил их с программным сжатием реального времени Spark от NVIDIA.

— ARM AFRC (Pixel 8, Mali-G715) — явный победитель: по метрике RMSE значительно обходит Spark и других конкурентов во всех форматах.

— Apple Metal Lossy (A15/M2+) — коэффициент сжатия 1:2, API минималистичен: один флаг в дескрипторе текстуры.

— ImgTec PVRIC4 (Pixel 10) разочаровал: драйвер игнорирует запрошенный bitrate, качество хуже Spark для R и RG форматов.

— Vulkan-расширение VK_EXT_image_compression_control унифицирует доступ к аппаратному сжатию через параметр BPC (bits per component).

— Аппаратное сжатие — перспективная альтернатива программному, но пока ограничено современными топовыми устройствами.

Контекст: почему это важно

Разработчики обычно не решались поставлять текстуры в новом формате, пока он не становился широко доступным — то есть поддерживался большинством целевого железа и всеми вендорами. Например, хотя ATI представила форматы 3Dc в 2004 году вместе с Radeon X800 (R420) и открыла их через расширения D3D9, их использование не стало распространённым, когда Direct3D 10 стандартизировал их как BC4 и BC5 в 2007 году. Массовое применение началось лишь тогда, когда Direct3D 10 стал минимальным требованием к железу.

Crysis стала первой крупной игрой, поставляемой с BC5-текстурами, но большинство игр ещё долгие годы не решались устанавливать такое жёсткое требование к железу. Чтобы избежать задержек с принятием, форматы BC6 и BC7 разрабатывались совместно ATI и NVIDIA для Direct3D 11.

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

Apple Metal: Lossy-сжатие

Apple представила сжатие текстур с потерями в чипах A15 и M2 (оба используют одно поколение GPU). Оно обеспечивает коэффициент сжатия 1:2. Включить его на удивление просто — API минималистичен. Свойство compressionType дескриптора MTLTextureDescriptor принимает значение из перечисления MTLTextureCompressionType, и установка MTLTextureCompressionTypeLossy зачастую является единственным необходимым изменением:

Согласно таблицам возможностей Metal Feature Set Tables, все обычные пиксельные форматы поддерживают сжатие с потерями — включая 10-битные и форматы с плавающей точкой. Тестирование это подтвердило, однако основное внимание сосредоточено на форматах R8, RG8 и RGBA8.

Внутренний алгоритм Apple не задокументирован. По результатам реверс-инжиниринга lossy-форматов используется размер блока 8×4 пикселя — и они напоминают некоторые особенности форматов ETC и EAC. Несмотря на заявленное сжатие 1:2, на практике для каждого блока выделяется один байт метаданных, так что реальное потребление памяти чуть выше заявленного.

Качество на M4 Pro

Для форматов R и RG Metal Lossy показывает результаты лучше кодеков Spark EAC, но хуже BC4 и BC5. Результаты RMSE (Root Mean Square Error — среднеквадратичная ошибка; меньше = лучше):

Формат R:

Формат RG:

Прямое сравнение lossy RGBA8 с форматами Spark некорректно из-за разных коэффициентов сжатия: Metal Lossy поддерживает только 1:2, тогда как форматы Spark RGB(A) — 1:4. Тем не менее, для полноты картины:

Формат RGBA:

Производительность на M4 Pro

С точки зрения производительности lossy-форматы показывают себя отлично и при достаточно большом размере текстуры упираются в пропускную способность памяти. Результаты на M4 Pro (16 ядер GPU) в МПикс/сек:

Обратите внимание, что пропускная способность стандартных блитов остаётся достаточно стабильной вне зависимости от размера текстуры. Кодеки Spark, напротив, имеют фиксированные накладные расходы, которые становятся заметнее при уменьшении размеров текстур. Интересен скачок скорости блитов при 512×512 — у него пока нет объяснения. Также стоит учесть, что кодеки Spark требуют дополнительного копирования из буфера вывода кодека в финальную сжатую текстуру — это дополнительные накладные расходы, которых можно было бы избежать, если бы Metal поддерживал запись в блочно-сжатые текстуры, как это делает Vulkan.

Vulkan: расширение VK_EXT_image_compression_control

В Vulkan расширение VK_EXT_image_compression_control даёт приложениям возможность запрашивать сжатие изображений с фиксированной скоростью. Расширение уже доступно на флагманских устройствах от ARM и Imagination. Включение потерявого сжатия в Vulkan несколько многословнее, чем в Metal, но на практике ненамного сложнее: нужно лишь расширить структуру VkImageCreateInfo, добавив в цепочку VkImageCompressionControlEXT.

Можно использовать флаг VK_IMAGE_COMPRESSION_FIXED_RATE_DEFAULT_EXT, чтобы позволить реализации самой выбрать параметры сжатия:

Альтернативно можно явно указать флаги фиксированной скорости для управления допустимыми коэффициентами сжатия:

BPC (bits per component — бит на компонент) — несколько нестандартная единица, но она позволяет задавать коэффициент сжатия единообразно вне зависимости от количества каналов. Для справки, BPC существующих форматов блочного сжатия GPU:

Расширение VK_EXT_image_compression_control также присутствует в некоторых драйверах AMD и Qualcomm, однако, насколько известно, ни один из этих вендоров не поддерживает аппаратное сжатие изображений с фиксированной скоростью. В случае AMD расширение присутствует в драйвере RADV, чтобы Proton мог отключать потерявое сжатие фреймбуфера в некоторых играх, где оно вызывало проблемы с корректностью — через флаг VK_IMAGE_COMPRESSION_DISABLED_EXT.

ARM AFRC: лучший результат среди всех

ARM Fixed Rate Compression (AFRC) было анонсировано в 2021 году и впервые появилось в Mali-G510 в 2022-м, однако широкого распространения этот дизайн не получил. По-настоящему массовым AFRC стало с выпуском Mali-G715 и Mali-G615 в том же году. Тестирование проводилось на Pixel 8 с GPU Mali-G715.

Устройство сообщило поддержку следующих форматов сжатия с фиксированной скоростью (возможности значительно шире Metal Lossy):

В отличие от Metal Lossy, AFRC не использует дополнительных байт метаданных — все управляющие биты находятся внутри самого блока. Изображение делится на блоки 8×8 пикселей, в ряде случаев разбиваемые на подблоки меньшего размера. Размер каждого блока 8×8 в байтах:

По результатам реверс-инжиниринга удалось установить: AFRC представляет цвета с использованием преобразования YCoCg, а представление пикселей напоминает вейвлет Хаара. Для каждого подблока 4×4 используется 16 коэффициентов, квантование которых зависит от режима. Форматы RGB и RGBA принципиально одинаковы — флаг в заголовке просто указывает, присутствует ли альфа-канал или блок полностью непрозрачен.

Качество AFRC

Качество AFRC впечатляет. В отличие от Metal, здесь можно сделать прямое сравнение с ASTC в реальном времени, поскольку Mali поддерживает сжатие 1:4:

Формат R:

Формат RG:

Формат RGBA:

Во всех случаях RMSE значительно ниже, то есть AFRC превосходит Spark ASTC при нацеливании на ASTC с кодировщиком реального времени. Тем не менее есть несколько случаев, когда Spark даёт более высокое качество: на очень гладких изображениях сжатие AFRC приводит к заметным паттернам дизеринга, раскрывающим границы блоков. Это особенно заметно при использовании AFRC в качестве текстуры с увеличением, тогда как для сжатия фреймбуфера — основного сценария применения — такие паттерны практически незаметны.

Производительность AFRC (Pixel 8)

Включение AFRC не вызывает значительных накладных расходов по сравнению с несжатыми загрузками текстур, за исключением некоторых размеров. Результаты на Pixel 8 в МПикс/сек:

Пропускная способность здесь масштабируется с размером текстуры, а не остаётся стабильной. Накладные расходы одинаково влияют на блиты и compute-шейдеры Spark. В отличие от секции Metal, где lossy-блиты явно доминировали над Spark на малых размерах, здесь картина смешанная: Spark вплотную приближается к AFRC или превосходит его. Это показывает, что кодирование текстур в реальном времени вполне конкурентоспособно с аппаратным сжатием. Абсолютные числа здесь значительно ниже, чем на M4 Pro, — это принципиально разные классы устройств.

ImgTec PVRIC4: разочарование от Pixel 10

ImgTec впервые анонсировала поддержку PVRIC4 ещё в 2018 году для GPU серии Series 6, однако протестировать её удалось только с выходом Pixel 10 на чипе Series D. Первоначальное объявление намекало на то, что, как и Metal Lossy, PVRIC4 поддерживает только 50%-е сжатие, но расширение декларирует более широкий спектр опций:

К большому удивлению, качество вывода оказалось одинаковым вне зависимости от BPC. Дальнейшее расследование показало: драйвер игнорирует запрошенный BPC и всегда использует 4 bpc (сжатие 1:2). Формат блоков PVRIC4 — наиболее сложный из всех трёх вендоров: размер блоков составляет 16×16 пикселей, и, как в Metal Lossy, присутствует один байт метаданных на блок. Сделать реверс-инжиниринг практически не удалось.

Качество PVRIC4

Качество оказалось разочаровывающим. Для форматов R и RG Spark фактически превосходит PVRIC4 при нацеливании на стандартные форматы блочного сжатия, поддерживаемые этим железом:

Формат R:

Формат RG:

Для RGBA прямое сравнение невозможно из-за разных коэффициентов сжатия, но качество также значительно хуже других вендоров:

Формат RGBA:

Производительность PVRIC4 (Pixel 10)

Кривая пропускной способности на этом устройстве существенно отличается от Pixel 8: пик приходится на размеры 1024–2048, а не монотонно возрастает с размером. На больших размерах пропускная способность Spark фактически выше, чем у несжатых загрузок текстур. Это характерно для устройств, ограниченных пропускной способностью памяти: обычный блит должен прочитать всё входное изображение и записать обратно тот же объём данных, тогда как Spark записывает лишь 1/4 входных данных. Экономия на записи зачастую перекрывает вычислительные затраты кодирования.

Комментарий PowerVR Dev (ImgTec)
PVRIC4 поддерживает только сжатие 1:2. TFBC (доступен исключительно в чипах Rogue XE) поддерживал соотношения 1:2, 1:4 и 1:3. Дизайн расширения был спорным — многим не нравилась многословность выбора BPC, поэтому было решено экспонировать все BPC в рамках поддерживаемых соотношений и повышать их до поддерживаемого ratio. Это считалось допустимым, поскольку качество не деградирует относительно запроса приложения, а приложение всё равно обязано запрашивать реальный размер изображения, который не гарантирует уменьшения.

Spark: программная точка отсчёта

Spark — библиотека NVIDIA для программного сжатия текстур в реальном времени. Работает на GPU как compute shader, поддерживает форматы BC1–BC7 и ASTC. В тесте выступает базовой точкой сравнения как лучшее доступное программное сжатие без специализированного железа.

Spark показывает стабильные результаты по форматам, но требует явного вызова compute-прохода — это дополнительный этап в пайплайне. Аппаратное сжатие, напротив, встроено в рендеринг и не требует дополнительного кода. Отдельный плюс Spark — предсказуемое и согласованное поведение на всех устройствах, что важно, если унифицированный вывод критичен для вашего сценария. Ни один из форматов аппаратного сжатия пока не доступен через WebGPU — если это изменится, расширить spark.js для их поддержки будет несложно.

Итоги: кто победил

ARM AFRC — явный победитель. Это не только превосходит программные реализации вроде Spark, но и обходит все остальные форматы по всем метрикам. Итоговая таблица RMSE по всем протестированным форматам:

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

Аппаратное сжатие — убедительная альтернатива программному. Главная оговорка — оно сейчас ограничено современными топовыми устройствами, которые как раз и располагают наибольшим объёмом памяти и пропускной способностью.

Даже когда нативное аппаратное сжатие доступно, есть веские причины продолжать использовать Spark. Вывод аппаратного сжатия различается у разных вендоров, и в некоторых случаях — как мы видели с PVRIC4 — качество уступает кодировщику реального времени. Если для вашего сценария критичен единообразный и предсказуемый вывод на всех вендорах, Spark остаётся правильным выбором.

Алгоритмы поиска

Бинарный поиск: быстрое нахождение элемента в отсортированном массиве

Бинарный поиск — один из самых быстрых способов файндинга элемента массива в backend разработке. Если в линейном поиске все проверяется поэтапно, то в бинарном количество проверок уменьшается за счёт «располовинивания» массива на каждом этапе поиска.

Как работает бинарный поиск:

1. Устанавливаются индексы начала и конца массива;
2. Находится индекс среднего элемента;
3. Если средний элемент равен значению, поиск завершается;
4. Если элемент меньше среднего, поиск продолжается в левой половине массива, а если больше — в правой;
5. И так до тех пор, пока не будет найден элемент.

Бинарный поиск имеет сложность O(log n). Это означает, что сложность растёт логарифмически.

Поиск подстроки: алгоритмы KMP и Rabin-Karp

Поиск текста внутри текста нужен, например, в обработке данных логов.

Алгоритм Кнута-Морриса-Пратта (KMP) был создан для поиска подстрок с предварительной обработкой шаблона.

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

Алгоритм KMP имеет сложность O(n + m), где n — длина текста, m — длина шаблона. А значит, сложность растёт линейно, в зависимости от длины текста и длины шаблона.

Алгоритм Рабина-Карпа создан для поиска подстроки через хеширование.

• Сначала определяются хеш-коды для шаблона и для каждой подстроки текста той же длины;
• Далее хеши сравниваются. При их совпадении проводится дополнительное сравнение символов;
• В конечном итоге хеш-код обновляется при переходе к следующей позиции текста.

Рабин-Карп нужен, если у вас есть много шаблонов для поиска одновременно — здесь работает параллельное вычисление.

Алгоритмы сортировки

Алгоритмы сортировки помогают в оптимизации данных в backendе. Они снижают время обработки массивов данных. А это особенно важно при высоких нагрузках и больших объёмах информации.

Quicksort и Merge Sort: эффективная сортировка больших массивов

Quicksort разделяет массив на подмассивы с помощью опорного элемента.

Алгоритм имеет среднюю сложность O(n log n). Время выполнения алгоритма растёт быстрее, чем линейно, но медленнее, чем квадратично:

1. Сначала выбирается элемент массива: средний, случайный, первый или последний;
2. Все элементы меньше опорного перемещаются влево от него, а больше — вправо;
3. И всё то же самое повторяется с подмассивами.

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

Медиана — значение, которое будет совпадать с серединой данных, а если нужно определить ее из чётных чисел, то считается среднее из двух.

Merge Sort имеет среднюю сложность O(n log n) во всех случаях.

Он объединяет отсортированные подмассивы в один полностью отсортированный массив:

1. Массив делится пополам каждый раз, пока не останутся отдельные элементы;
2. И в конце концов подмассивы «собираются» снова, но уже в отсортированном виде.

Merge Sort весит больше, чем Quicksort. Зато он более стабилен и подойдёт для обработки больших файлов или для поток данных.

Heap Sort: сортировка для работы с приоритетами

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

Хорош этот алгоритм тем, что подойдёт для сортировки данных по приоритету для создания частичных выборок:

1. Сначала массив преобразуется в двоичную кучу;
2. Затем для max-heap выделяется максимальный элемент и заменяется следующим, более «низким»;
3. Далее создаётся правильный порядок с помощью функции maxHeapify() или heapify();
4. Процесс повторяется до тех пор, пока не будет сформирован правильный порядок для всех элементов.

Heap Sort имеет сложность O(n log n) — она растёт быстрее, чем линейно, но медленнее, чем квадратично. Для метода не нужна дополнительная память для хранения промежуточных результатов.

Работа с графами

Мы когда-то упоминали в этой статье, графы используются для аналитики данных в backend-разработке. С помощью них определяется связь элементов друг с другом. Графы состоят из вершин, рёбер и весов, связей между рёбрами и вершинами.

Алгоритм Дейкстры: нахождение кратчайшего пути

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

1. Сначала определяется главная вершина. Расстояние до неё, при этом, равно нулю, а до всех остальных вершин задаётся вручную (ну или определяется автоматически).
2. И далее алгоритм идёт от соседней (относительно начальной) вершины до следующей. И так, пока цель не будет достигнута.

Алгоритм Дейкстры имеет сложность O(V²), то есть, растёт квадратично. Сложность может уменьшиться до O(E log V) при работе с очередями приоритетности.

Алгоритм Флойда-Уоршелла: нахождение всех кратчайших путей

Если смысл Дейкстры в том, чтобы искать наиболее короткий путь от начальной вершины к остальным, то смысл алгоритма Флойда-Уоршелла в том, чтобы находить самый короткий путь между всеми вершинами.

1. Сначала создаётся матрица расстояний, где каждая ячейка [i][j] содержит вес ребра (i,j) или бесконечность, если ребра нет;
2. Для каждого узла проверяется возможности оптимизации пути между двумя другими узлами;
3. Далее матрица расстояний обновляется и ранжируется по самым коротким путям.

Алгоритм Флойда-Уоршелла имеет сложность O(V³), то есть, растёт кубически, и подходит для анализа связей между вершинами.

Алгоритмы хеширования

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

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

MD5 (алгоритм дайджеста сообщений 5) — самая популярная хеш-функция. Она используется для проверки целостности данных.

Раньше считалось, что два разных фрагмента не могут дать один и тот же MD5 хеш. Но система была взломана: в 2005 году китайские криптологи опубликовали статью с описанием алгоритма, который помогает найти 2 разные последовательности, но с одним MD5 хешем.

SHA — сразу несколько версий алгоритма (SHA-1, SHA-256, SHA-512). Сейчас распространены SHA-256 и SHA-512 с выходом дайджеста сообщений в 256 и 512 бит соответственно.

SHA используется для создания цифровых подписей и сертификатов безопасности — всё благодаря устойчивости алгоритма к «коллизиям» (иными словами, взломам) и постоянным обновлениям.

CRC32 (циклический избыточный код) — ещё одна хеш-функция для проверки целостности данных. CRC нельзя использовать для защиты данных от атак, поскольку ее основная задача — быстро обнаружить изменения данных при передаче или хранении.

CRC32 подходит для работы с сетевыми протоколами и для базового обеспечения целостности данных.

Работа с деревьями

Работа с деревьями — основа backend разработки. С помощью нее можно эффективно и правильно организовывать и хранить данные.

Алгоритм обхода деревьев (DFS, BFS)

Обход деревьев, если коротко, нужен для того, чтобы обработать каждый узел в своём порядке. Есть 2 главных способа обхода: поиск в глубину (Depth-First Search, DFS) и поиск в ширину (Breadth-First Search, BFS).

Принцип поиска в глубину (DFS) — сначала анализируются все «вторичные» (ну или дочерние) узлы одного поддерева, а потом следующее поддерево. DFS полезен для того, чтобы сначала проанализировать все узлы, а потом уже искать элементы с определённым условием.

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

Балансировка деревьев (AVL, красно-чёрное дерево)

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

AVL-деревья — двоичное дерево поиска с быстрым доступом к данным. При каждом добавлении или удалении элемента дерево автоматически балансируется. А это означает, что сложность операций всегда будет равна O(log n).

Красно-чёрные деревья менее сбалансированы по сравнению с AVL, зато операции вставки и удаления проводятся быстрее (за счёт меньшего количества вращений дерева).

Глобально: разница между двумя этими подходами в том, что: путь от корня (основания) дерева AVL — не более ~1,44 lg(n+2), а путь от корная красно-чёрного дерева — не более ~2 lg(n+1). AVL-деревья быстрее ищут данные, но требуют больше времени на вставку и удаление. А красно-чёрные деревья более простые и стабильные в реализации из-за меньших требований к балансировке.

Алгоритмы сжатия данных

Алгоритмы сжатия данных нужны для обработки и передачи больших объёмов информации в backend разработке. А потому и нужна оптимизация.

Huffman Coding: оптимизация хранения и передачи данных

Алгоритм Хаффмана (Huffman Coding) — один из видов алгоритмов префиксного кодирования. С помощью него можно уменьшить размер данных, при этом, «выигрывая» как в скорости, так и в объёме.

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

Код Хаффмана — основа форматов сжатия по типу JPEG и MP3.

LZ77/LZ78: алгоритмы для компрессии больших объёмов данных

Алгоритмы семейства Lempel-Ziv — база современных методов сжатия без потерь качества и производительности. С помощью них большие по объёму данные сжимаются за счёт поиска повторяющихся последовательностей внутри массива.

Принцип работы LZ77 — второе и последующее совпадение данных ссылается на самое первое совпадение.

Принцип работы LZ78 — создание динамического словаря «фраз» по мере обработки данных. В процессе добавляются новые комбинации символов («фразы») по мере их обнаружения.

На этих алгоритмах строится форматы архивирования файлов по типу ZIP и GZIP.

Жадные алгоритмы

Жадные алгоритмы — класс алгоритмов, внутри которых данные принимаются локально. «Жадными» они названы потому, что требуется найти самый оптимальный способ решения с минимальными затратами в backend-разработке.

Алгоритмы «наиболее подходящего выбора»: оптимизация решений

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

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

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

Алгоритм Дейкстры мы уже разбирали выше. Если коротко: он используется для поиска кратчайшего пути от одной вершины графа до всех остальных. Основывается на выборе наименьшей стоимости пути из всех доступных на каждом шаге.

Динамическое программирование

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

Алгоритм поиска подстроки (Longest Common Subsequence): анализ строк

Грубо говоря, этот алгоритм помогает найти определённый повторяющийся сценарий в тексте. Если строка содержит этот паттерн, то вы получаете ответ «да» или прямую ссылку, где этот паттерн впервые был представлен. Это в целом основной принцип криптографии, архивирования и компиляции.

Алгоритм имеет сложность O(n*m), где n и m — длины сравниваемых между собой строк. При этом, таблица с выводами заполняется последовательно, по мере нахождения паттернов.

Алгоритмы для работы с потоками данных

Для обработки данных в backend в режиме реального времени используются специальные алгоритмы: Sliding Window и Bloom Filter — с максимальной итоговой производительностью.

Sliding Window: обработка данных в реальном времени

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

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

Bloom Filter: проверка существования элемента в наборе

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

Фильтр Блума занимает гораздо меньше места в сравнении с обычными структурами данных. С помощью него можно быстро проверить существование элемента через использование нескольких хеш-функций. По такому же принципу работает спам-фильтр в почтовом клиенте.

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

Наверняка вы сталкивались с zip–архивами, сохраняли фото в jpeg или смотрели видео в 144p — всё это примеры сжатых данных. Когда мы говорим о сжатии (компрессии), то имеем в виду уменьшение исходного размера без потери содержимого. Так можно хранить больше информации, быстрее её передавать и считывать.

Методы сжатия данных принято делить на 2 категории: с потерей и без потери. Рассмотрим их подробнее.

Сжатие с потерями (lossy)

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

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

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

Оригинал — первое изображение в формате png. Второе — сжатый вариант в формате jpeg.

Казалось бы, вариант 2 должен был потерять качество, и это произошло. При компрессии были удалены некоторые похожие оттенки цветов и лишние детали, а размер файла уменьшился с 2.38МБ до 145 КБ. При этом визуально он все еще выглядит неплохо.

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

Сжатие данных без потерь (lossless)

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

Допустим, нам нужно составить список покупок. Мы можем записать его так:

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

Популярные алгоритмы сжатия данных без потерь

Давайте рассмотрим три наиболее распространенных метода сжатия без потерь.

Huffman coding

Метод Хаффмана позволяет нам компактно закодировать данные при помощи манипуляций с частотой объектов и выстраивания дерева. А еще его включают в себя многие другие алгоритмы и форматы сжатия.

Рассмотрим пошагово кодирование Хаффмана на примере сжатия слова: «compression».

Шаг 1 — строим таблицу частотности

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

Шаг 2 — строим дерево

Записываем символы как листья дерева. Их частотность будет весом.

Находим два крайних правых листа и строим над ними новый. Записываем в него символы и сумму их частот.

Мы создали лист «in» с весом 2. Формируем листы дальше.

Теперь мы построили лист «ein» с весом 3 из «in» и «e». Продолжаем до тех пор, пока не создадим последний лист.

Шаг 3 — кодируем текст

Мы закончили строить дерево. Теперь можно приступить к кодированию знаков.

Вершина «oscmprein» является корнем нашего дерева, так как обладает наибольшим весом — 11.

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

Например, между «o» и корнем «oscmprein» есть только одно ребро, которое равно нулю. Следовательно, «o» это 0. От корня до «s» ведут две линии: один и ноль. Значит, код будет 10. И так до узла «n», код которого 11111111.

В итоге получим следующую кодировку символов:

В изначальном варианте «compression» весит 88 бит, но благодаря методу Хаффмана мы сжали его до 48 бит.

Lempel-Ziv-Welch (LZW)

Метод Лемпеля создает словарь, где кодирует символы, слова и сочетания слов. Давайте рассмотрим принцип работы данного алгоритма на примере текста: «The big big big cat sat on the mat mat mat. The big big cat ate the fat fat rat. The cat cat cat sat sat sat.»

Шаг 1 — создаем словарь

Начнем с создания словаря, содержащего все возможные одиночные символы и их коды. В нашем случае мы будем использовать ASCII-коды для простоты:

Шаг 2 — сжимаем текст и расширяем словарь

Теперь будем читать каждый символ из фразы. Если он уже есть в словаре, то считаем комбинацию символов:

• Читаем «T». Проверяем его в словаре. Записываем код (84).
• Проверяем его сочетание со следующим символом. «Th» нет в словаре.
• Присваиваем для «Th» код 256.
• Читаем «h». Есть в словаре, пишем код (104).
• Проверяем «he». Этого сочетания нет в словаре.
• Присваиваем код 257.

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

Например, слово «big» повторяется пять раз. Первое повторение мы закодируем по коду символов «b», «i», «g»: 98 105 103.

Так как в словаре нет сочетаний «bi» и «ig», присвоим им новые коды и добавим в словарь:

При следующем повторении мы закодируем «big» как 260 261, а не 98 105 103.

В итоге получим вот такой код:

Исходная фраза весила 73 байта, но мы сжали её до 53 байт.

Deflate

На самом деле с этим алгоритмом мы уже сталкивались. Ну, почти. Он основан на двух методах сжатия без потерь: LZ77 и коде Хаффмана. LZ77 — более старая версия LZW. Они отличаются только тем, что LZ77 не создает словарь с кодами — вместо этого он использует ссылки. Для примера возьмем текст: «The big big big cat sat on the mat mat mat».

Шаг 1 — определяем повторяющиеся подстроки

Это будут:

• big;
• cat;
• mat.

Шаг 2 — создаем ссылки

Ссылки записываем в следующем формате:

Например, буква «b» в слове «big» является пятым по порядку символом, если смотреть относительно всего текста. При счете с нуля её индекс — 4. Слово состоит из трех букв. Поэтому наша ссылка выглядит так:

Аналогично с cat (16,3) и mat (31,3).

Шаг 3 — сжимаем текст

Последовательно записываем наш текст, заменяя повторения ссылками:

Шаг 4 — применяем метод Хаффмана

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

Алгоритмы сжатия с потерями

JPEG (для изображений)

Сжатие данных исходного изображения в jpeg происходит в четыре этапа.

Этап 1 — переводим в цветовое пространство YCbCr

YCbCr — цветовой профиль, который условно можно представить как три маски.

Y — чёрно-белая картинка, которая демонстрирует уровень яркости.

Cb — синий канал.

Cr — красный канал.

Так мы сможем отделить цвета от яркости.

Если что, отсутствие синих и красных оттенков нормально, потому что каналы Cb и Cr не представляют напрямую синий и красный цвета. Они показывают отклонения от нейтрального серого в сторону сине-желтого (Cb) и красно-зеленого (Cr) спектров.

Этап 2 — Дискретное косинусное преобразование (DCT)

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

Комбинируя их, можно повторить любое изображение 8x8 пикселей.

У каждого паттерна есть свой вес, который можно менять — его называют коэффициентом. DCT определяет, на какие паттерны с какими коэффициентами можно разложить блок.

Этап 3 — Квантование

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

Этап 4 — сжатие Хаффмана

Да-да. Здесь опять вступает в игру метод сжатия Хаффмана, который сжимает нашу последовательность еще сильнее.

MP3 и ACC (для аудио)

MP3 и ACC — это два формата компрессии аудио с потерями. Сжатие в них работает аналогично сжатию в jpeg.

Этап 1 — раскладываем звук на волны

Мы раскладываем звук на несколько кусочков — фреймов. Эти фреймы разделяем на волны.

Этап 2 — находим у волн лишние частоты

У каждой волны есть своя частота. Некоторые частоты человек не воспринимает, поэтому MP3 использует психоакустическую модель. Она удаляет такие частоты, а еще заменяет похожие волны одной.

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

Этап 3 — округляем коэффициенты частот

Далее начинается квантование. Мы округляем коэффициенты частот. Те, что слышим хуже, получают меньше битов, и наоборот.

Если последовательность частот равна нулю, то удаляем нули и заменяем их записью по типу:

(0, количество повторений). Точно как с jpeg.

Этап 4 — пропускаем через алгоритм Хаффмана

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

H.264 и HEVC (для видео)

H.264 и HEVC — это стандарты видео сжатия. Еще их называют кодеки. Вот основные этапы сжатия видео:

Этап 1 — разбиение на кадры и блоки

Разбиваем видео на кадры. Каждый кадр раскладываем на блоки:

• 16x16 пикселей в H264.
• 64x64 в HEVC (H.265).

Благодаря этим небольшим блокам мы можем отслеживать изменения в кадрах.

Этап 2 — формируем I,P,B-кадры

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

Этим методом формируем три категории кадров:

1. I-кадры (intra-coded frames) — это опорные кадры, которые кодируются без учета других кадров. Они содержат полную информацию о текущем изображении и служат отправной точкой для декодирования других кадров. Такие кадры наиболее «тяжелые» по объему, но необходимы для восстановления видео.
2. P-кадры (predictive frames) основываются на предыдущих I- или P-кадрах. В них кодируется только информация о различиях между текущим кадром и предыдущим, что значительно сокращает объем данных.
   
3. B-кадры (bi-predictive frames) используют как предыдущие, так и последующие кадры для предсказания текущего кадра. Это делает их наиболее эффективно сжимаемыми, поскольку они могут использовать информацию из двух направлений — как вперед, так и назад. Однако их обработка требует больше вычислительных ресурсов.
   

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

Представим последовательность кадров:

В I-кадре статичная картинка. В первом P-кадре мы повторяем предыдущий I-кадр и благодаря информации о смещении дорисовываем его часть. То же самое проделываем со вторым P-кадром относительно первого P-кадра.

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

Этап 3 — выводим коэффициенты

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

Этап 4 — округляем, убираем излишки и кодируем по Хаффману

Округляем их при помощи квантования, сокращаем коэффициенты близкие или равные нулю и используем метод сжатия Хаффмана.

Инструменты для сжатия данных

ZIP и GZIP

ZIP и GZIP — это утилиты для архивирования файлов. Они уменьшают размер данных без потери информации.

• ZIP использует алгоритмы из метода Deflate, который мы рассматривали выше. Преимущества ZIP в том, что он поддерживается практически на всех операционных системах и способен сжимать несколько файлов.
• GZIP используется на серверах для уменьшения объёма данных, передаваемых по сети. GZIP также основан на алгоритме Deflate, но в нем нет реализации методов сжатия многокомпонентных архивов. Это значит, что он не умеет сжимать несколько файлов.

FFmpeg

FFmpeg — фреймворк, который применяется для сжатия, конвертации и обработки медиафайлов.

FFmpeg поддерживает широкий набор кодеков и форматов, включая H.264, H.265 для видео и AAC, MP3 для аудио.

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

7-Zip

7-Zip — бесплатная утилита для сжатия данных, которая поддерживает формат 7z, а еще там есть ZIP, RAR, и TAR.

Основное преимущество 7-Zip в его высоком уровне сжатия. Здесь применяется метод сжатия LZMA. Это модифицированная версия LZ77.

LZMA, так же как и LZ77, ищет повторяющиеся последовательности и заменяет их ссылками. Но еще он использует метод Маркова для предсказания вероятности появления символов.

7-Zip также поддерживает создание защищённых паролем архивов с шифрованием и работает на большинстве платформ, включая Windows и Linux.

Преимущества и недостатки различных методов сжатия

Баланс между эффективностью сжатия, скоростью и качеством данных

Сжатие без потерь

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

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

Сжатие с потерями

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

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

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

Как выбрать метод сжатия данных

Выбор способа сжатия данных зависит от задачи.

Для хранения архивов

Zip, 7-zip или RAR-архивы станут отличными инструментами, если нам нужно просто сохранить набор файлов на компьютере.

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

Для сжатия веб-сайтов

Для оптимизации сайта подойдет формат gzip. Он умеет сжимать html и css без потерь, благодаря чему веб-страницы быстрее прогружаются.

Для изображений

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

Но если мы увлекаемся профессиональной фотографией, то стоит выбрать RAW формат — он содержит максимум данных, которые нужны для обработки.

Для видео

Для любительской съемки и просмотра видео подойдет Кодек H264. Но если мы занимаемся видеопроизводством профессионально, то для редактирования нам подойдут форматы вроде ProRes. А финальную версию можно сохранить в H.265 (HEVC).

Для аудио

Чтобы послушать музыку на смартфоне или в машине, нам хватит MP3 или ACC формата. Но для аудиофилов и тех, кто занимается музыкой профессионально, подойдет формат без потери данных FLAC.

А с какими методами сжатия работаете вы? Расскажите в комментариях👇

• Чем WebP: на 14%
• Чем BPG: на 22%
• Чем PNG с брутфорсом через ZopfliPNG: на 33%
• Чем обычный PNG: на 43%
• Чем PNG, оптимизированный через Adam7: 46%
• Чем JPEG2000 без потерь: на 53%
• Чем JPEG XR без потерь: на 74%

Даже если из конкурентов FLIF выбирать наиболее подходящий для конкретной фотографии, он всё равно медианно эффективнее на 12 % (в среднем — на 19%, учитывая 16 битные изображения, которые не поддерживают WebP и BPG).

Преимущества FLIF

Лучшее сжатие

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

Работает с любыми типами изображений

С FLIF вам не нужно будет больше думать о том, какой формат для изображения подойдёт лучше, потому что лучше гарантированно подойдёт FLIF ?

Графики говорят сами за себя:

Но в любом из трёх типов изображений FLIF на голову опережает конкурентов.

Прогрессивная загрузка

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

FLIF — свободный формат

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

Подробнее можете прочитать на официальном сайте FLIF.