Метод сжатия с использованием словаря

Субтитры

Всем привет. Добро пожаловать на очередной выпуск Google Developers Live, в котором здесь, в Google, у нас есть шанс поговорить с вами об удивительных вещах, происходящих в сети, технологиях и платформах и их потрясающих возможностях. Меня зовут Colt McAnlis. Я работаю специалистом по работе с разработчиками в команде, занимающейся Chrome, и чаще всего я занимаюсь вопросами производительности в сети, а также ведением интернет-игр. То, о чем я хочу поговорить сегодня, очень близко и дорого моему сердцу - и это сжатие. Сегодня мы поговорим о GZIP на веб-платформах и как вы можете его менять, исправлять и вносить изменения в файл для минимизации объема требуемой памяти вашего сайта и фактически получать более быструю загрузку данных. Теперь, пока мы не углубились в беседу, я бы хотел обратить внимание на хэштег #perfmatters. Это - фантастический хэштег, используемый повсеместно в различных социальных сетях среди людей, занимающихся веб-разработками, которые пытаются решить те же самые проблемы, к которым можно обратиться с вопросом и поговорить о работе в занимательной и познавательной манере. Поэтому используйте этот хэштег. Если что-либо во время этой беседы вас заинтересовало или воодушевило, не стесняйтесь заходить в ваши любимые социальные сети. Это замечательное средство и им нужно пользоваться. Итак, позвольте приступить. Давайте начнем с самого начала. Я не могу говорить о сжатии в интернете не поговорив о настоящем состоянии интернета. Сегодня, несмотря на обилие котиков, там есть кое-что действительно интересное, на что нам стоит посмотреть. существует отличный сайт httparchive.org, и, по сути, этот сайт пропускает огромное количество веб-сайтов через обрабатывающие фильтры в течение всего дня. И получается, что они берут 300,000, 400,000 обычные веб-сайты, пропускают их через систему обработки, и потом собирают информацию о них и размещают на своей странице. Сейчас на этом графике вы можете увидеть одно из последних исследований, которое показывает средний размер страницы в байтах по типу содержания. Таким образом, этот график показывает, что изображения среднего сайта, занимают, фактически, львиную долю контента, передаваемого пользователям. Фактически, эта доля составляет более 50%. Это достаточно крупный объем поставляемого контента, в то время как скрипты остаются на втором месте и сводятся к 260 кб или около того. И теперь, что в этом интересно, когда вы посмотрите на размер отдельных откликов, вы, конечно, заметите подобную тенденцию, Размер Flash - один из самых крупных по количеству откликов. Но, конечно, все сводится к тому факту, что обычно у вас на странице один или два flash-объекта, и они имеют тенденцию быть достаточно большими, тогда как JavaScript или PNGs или JPEG собирают множество запросов на странице. Что на деле снижает это число. Итак, мы здесь видим, что представление об интернете находится под влиянием изображений и мы находимся под влиянием данных в виде изображений. Но я не безусловно уверен, что средства, от которых мы можем отказаться, пытаясь минимизировать и уменьшить размер текстовых данных, на самом деле ведут интернет. Давайте рассмотрим эту ситуацию. Она включает крупный набор схем HTTP Archive. И по существу, то, на что вы здесь смотрите, это три графика, отражающие размер передачи данных к числу запросов. И мы видим, что со временем, число запросов остается примерно постоянным в течение нескольких прошедших лет, тогда как вы можете заметить тренд к увеличению общего размера на каждый запрос. Здесь вы видите три графика для HTML, JavaScript, и CSS. И что это означает? Что пока графические изображения составляют львиную долю интернета в данный момент, текстовая информация, основа этих трех форматов, не исчезнет в скором времени, так же как не станет ничуть меньше. Итак, многие скажут хорошо, если интернет состоит по большей части из изображений почему нас должен волновать текст? Итак, вот почему. Вы знаете, что изображения могут быть потрясающими и они могут быть доминирующей Формой контента для нас, Но очевидно и доказано, что они не так малы, как могли бы быть. Например, давайте давайте рассмотрим это потрясающее изображение, Снятое на камеру. Он содержит почти один мегапиксель данных. И если он будет в формате PNG, получается, что он весит около 2.3 мегабайт. А те, кто играют в игры дома, заметят, что архив HTTP среднего размера сайта достигает от 1.2 to 1.1 МБ данных. Так, одно только это PNG изображение, выложенное на вашем веб-сайте, уже больше, чем средний размер вебсайта в интернете. Итак, PNG файлы восхитительны. Они позволяют достичь прозрачности, и изнутри поддерживают GZIP сжатие как формат, но на самом деле только поддерживают кодирование без потерь, что означает, что вы на самом деле не избавляетесь от любых визуальных данных, которые могут быть лишними. JPEG, с другой стороны, как формат подвергается как кодированию с потерями, так и без потерь. Что позволяет кодировочной системе JPEG Фактически удалять ненужную визуальную информацию из графического изображения так, что вы даже не заметите, что она исчезла. Человеческий глаз довольно сложен, но, тем не менее, 32 бита на писксель содержат так много информации, которой мы не можем разглядеть. Поэтому если это изображение преобразовать в JPEG, вы потеряете возможность добиться прозрачности, даже если вы обрежете изображение до 297k. Итак, эти два формата являются самыми распространенными Форматами изображений, не учитывая анимированных GIF-котиков в интернете, но в начале этого года, евангелисты интернет технологий и другие энтузиасты решили, что мы, наверное, здесь еще не закончили. Может быть, система сжатия JPEG не была достаточно хорошей для всей сети, и поэтому мы должны были изобрести формат WebP. Пока формат WebP нов. Он поддерживается не всеми браузерами на данный момент. Но у него и в самом деле есть несколько удивительных качеств, которые реально заставляют людей в интернете остановиться и обратить внимание. Первое – если вы сжимаете изображение с помощью WebP, размер его сокращается примерно до 198k. разница в 100 килобайт данных для одного изображения. В дополнение, WebP фактически позволит вам добиться прозрачности и даже поддерживает некоторые форматы анимации, что значит, что один этот Формат изображения предоставляет вам размеры сжатия JPEG, прозрачность PNG, а также анимацию GIF. Это восхитительно, одно решение для множества требований вашего изображения. Теперь нужно отметить важный момент о размере этого изображения и о формате этого изображения. В большинстве мобильных телефонов сейчас 5 мегапиксельные камеры, и значит, что люди фотографируют еду или уличные знаки, или детей, загружают их в любимые социальные сети, и эти фото фактически поступают несжатыми, в размере 5 мегапикселей. Теперь взгляните на PNG и JPEG и уровни сжатия, Которому подвергаются Изображения размером один мегабайт, Вы можете заметить, что со временем, число изображений, заполняющих интернет, увеличивается и мы должны скорее заняться вопросами сжатия и размерами данных. Поэтому выделяется WebP и, по сути, решает огромную проблему, и позволяет нам решить множество задач. Теперь существуют целые серии GDL, сделанные в WebP. Я рекомендую вам посетить сайт GDL, взглянуть на то, о чем я говорю, чтобы получить больше информации как начать с этим работать. Это все, что я хотел сказать О сжатии изображений на сегодня. Но только на время, поговорим об этом в следующий раз. Как я сказал ранее, текстовые данные - CSS, HTML, JavaScript-- поддерживают выполнение задачи, и загрузка основной страницы требует больше времени, чем загрузка изображения. Для этого есть особая причина. Как вы видите на графике, мы не можем начать обрабатывать что-то на вашей странице, пока не пропарсим HTML и соответствующий JavaScript и пока не загрузим CSS для создания DOM и CSS DOM, Так мы сможем парсить схему исполнения и, собственно, начать выводить пиксели на экран. И если мы взглянем на средний поток событий из HTML в CSS, чтобы вывести пиксели сюда, Мы увидим интересный пример. Итак, у нас есть стандарт, привязанный к CSS. Этот CSS обновляет некоторую информацию на странице, текстовые данные. Также у нас есть некое изображение, находящееся по ссылке, и скрипт, лежащий в основе всего этого a script. Вы увидите, что на мобильном изображении сбоку еще ничего не появилось, хотя HTML уже пропарсили. И у нас появляется маленькое оранжевое HTML поле. Вы видите, что DOM уже почти пропарсили. Частично он оранжевый. И CSS файл -- example.css-- был открыт, но еще не загрузился. Это означает, что мы не можем отобразить текст на экране, потому что у нас нет параметров правки, выводящих этот текст на экран. И пока CSS данные загружаются, мы можем построить CSS Версию DOM и начать создавать схему выполнения. Заметьте, что DOM еще не закончил загрузку. это нормально. Если мы можем частично загрузить и частично просмотреть верхнюю часть DOM, или то, что люди обычно называют первым экраном, мы можем начать рендеринг пикселей на экран, пока нижняя часть страницы все еще загружается. Теперь, когда CSS загрузился, мы можем загрузить на экран какой-то текст. Заметьте, что разметка страницы и заливка на полпути к окончанию, потому что у них пока нет всех необходимых данных. Следующим нужно загрузить WebP, и потом, конечно, определяется last.js. Так как размеры файлов last.js меньше, чем изображений, его можно загрузить и пропарсить раньше, чем графические данные попадут на экран. Если last.js сбрасывает некоторые стилевые цепочки или любую другую информацию, которую нужно загрузить, можно вернуться и поменять параметры DOM и CSS, заставив страницу повторно загрузиться, снова сделать заливку, ну и все, что вам нужно загрузить. Но заметьте, что изображения еще не загрузились и не отобразились на экране. Пока последний заключительный бит не выйдет из провода, CSS DOM не будут закончены, Схема выполнения может быть завершена, и, наконец, мы можем увидеть изображение на экране, показывающее то, что вы пытались показать в первую очередь. Что вы должны из этого извлечь, - в то время, как графические изображения составляют основу контента сети, именно текстовая база данных управляет, как и когда пиксели появляются на вашем экране. И когда вы пытаетесь оптимизировать быстрый и критический путь, отображаемый на мобильных устройствах, вам нужны именно текстовые данные, чтобы вывести их из провода так быстро, как только возможно. Многие из вас, говорят о реально классной интернет технологии, называемой Emscripten. Это библиотека, разработанная как открытый источник, который позволяет разработчикам использовать существующие коды C и C++ и транскомпилировать их в данные JavaScript. Возможно, один из наиболее впечатляющих примеров этой технологии дебютировал чуть ранее в этом году, примерно в марте на конференции разработчиков игр, где Nvidia и Mozilla и группа сообщества открытых источников из Emscripten представила впервые движок механизма Unreal 3, флагман Emscripten. Теперь это означает, что вы получаете богатый, полный графический движок, работающий внутри браузера. Он работает внутри JavaScript, поэтому он соответствует спецификациям и всем другим забавным штукам. Я нахожусь на стороне игровой индустрии, и я работаю с Unreal 3 уже много лет. И одна причина почему Unreal никогда не был популярным - это его малый размер. Вы видите, что когда мы переносим код источника и скомпилированные данные в сеть, эта проблема не исчезает. Если вы посмотрите на время загрузки этого приложения, вы можете увидеть, что ядро файла JavaScript для этого порта Unreal, основанного на Emscripten, содержит около 50 мегабайт данных. 50 мегабайт файла JavaScript для загрузки игры. Чтобы быть честным отмечу, он подается сжатым, и это значит, что вам нужно только выкачать пять мегабайт данных из шнура, чтобы получить единственный файл JavaScript. Но все же, пять мегабайт. Это в пять раз больше, чем любой из наших , веб-сайтов. К слову, это не учитывая 18 мегабайт данных, которые также потребуется скачать. Когда вы смотрите на эти тенденции – все больше разработчиков стараются двигаться в направлении высокой производительности выполнения JavaScript, используя такие штуки как Emscripten, и asm.js—вы начинаете понимать, что это тренд. Чем больше появдяется приложений, создающих программные коды в JavaScript, на других языках, тем больше мы видим раздутые все большие и большие файлы JavaScript, которые клиентам нужно скачивать, чтобы пиксели добрались до экрана, и чтобы игра проигрывалась. Этот тренд со временем не ослабнет. Это означает, что наши текстовые данные продолжат возрастать. Например, это твоя работа, как разработчика, выяснить как минимизировать, сжать и уменьшить количество битов в шнуре. И вместе с тем, давайте взглянем на старого верного товарища под именем GZIP, софт, являющийся основой сжатия в интернете на данный момент. Теперь я хочу бегло заметить, что сжатие – это не то же самое, что минимизация или уменьшение размера изображения, в зависимости от того, насколько вы приверженцы чистоты терминов. Давайте бегло взглянем на них. Уменьшение размера изображения на веб-платформе - это искусство удаления лишней информации из текстовых данных такое, что мы все же сможем символически парсить и обрабатывать ее, когда передадим ее системам, лежащим в основании. Взгляните на этот пример, у нас есть функция, которая добавляет два числа, но выглядит будто там находится масса информации, которой вы не видите. Здесь есть возврат к строке, информация о простановке пробелов, хотя различные названия слишком длинные. Процесс минификации, по сути, уменьшает их и дает вам наименьшее количество полностью обрабатываемых и действующих байтов для работы данного файла. Опять же, мы можем обработать данные загодя и фактически передать это право основным системам для обработки и получить материалы прямо на свой экран. Итак, сжатие, с другой стороны, предлагает нечто абсолютно другое. Сжатие - акт изменение данных таким образом, чтобы их можно было восстановить прежде, чем их передадут основной обрабатывающей системе. Таким образом, снова, если мы берем минимизированную форму некой функции, сжатие превратит ее в битовый поток информации, а затем ее можно выкачать и развернуть, по сути, в оригинальную форму до того, как ее передадут основной системе. Эти две технологии работают как «двойной удар». Таким образом, Вы фактически должны применить минификацию к Вашей технологии прежде чем перейти к GZIP, чтобы получить наименьшее количество байтов на проводе. В продолжение разговора мы собираемся обратиться к некоторым проблемам и плюсам и минусам GZIP, но сначала мы сделаем так: я должен быть уверен, что мы понимаем, что происходит под капотом этого алгоритма. Вы видите, GZIP - формат сжатия, который фактически использует две взаимодействующие технологии вместе. Первая - технология, известная как LZ77. Теперь, это преобразованная форма, основанная на словаре, которая фактически берет данный поток данных и преобразует его в последовательность кортежей. Теперь, в каждом кортеже у нас есть показатель положения длины. Я знаю, что это запутывает. Давайте рассмотрим здесь небольшой пример. Итак, у нас имеется цепочка, состоящая Из различных A, B и C в случайном порядке. Что случится, если мы начнем парсить эту цепочку, посмотрим на каждый символ отдельно, и мы собираемся просканировать выше, чтобы найти когда ранее мы встречали этот символ, потому что тогда это позволяет нам фактически закодировать этот символ как единственную единицу информации, но скорее, как относительную единицу информации. Цель LZ77 здесь состоит в создании множества ненужных кортежей, которые немного позже мы можем сжать. Поэтому давайте немного пройдемся по тому, что же происходит. Вы видите, что мы начинаем с первой А 372 00:15:12,330 --> 00:15:13,830 И мы ее парсим, это и есть начало цепочки, мы не видели этого знака ранее. Таким образом, мы должны вывести положение и место 0, 0. Это означает, что мы не видим любых других знаков. Мы просто смотрим на эту А. Теперь, когда мы добираемся до второй A, мы начинаем сканирование назад и мы обнаруживаем, что первая А, с которой мы столкнулись, встречался один символ назад длиной в один символ. Это означает, что мы можем вывести кортеж 1, 1. Теперь B, до этого мы не видели В, поэтому мы должны вывести 0, 0. и C, то же самое, 0, 0. Но теперь мы достигли другой B, поэтому снова начинаем сканирование назад и обнаруживаем, что последнюю B мы встретили в потоке два символа назад. И снова, нам нужна длина в один символ. Теперь важная и, возможно, самая интересная часть этого примера - мы добираемся до конца цепочки, где мы видим A, B, C. Теперь, когда мы ищем A, B, C, мы обнаруживаем, что мы находили эти самые три символа выше в нашем потоке и точно пять знаковых позиций назад. Таким образом, мы вводим кортеж 5, 3. Мы вводим кортеж длиной более, чем три знака. И снова, назначение LZ77 – создавать и дублировать высокоизбыточный кортеж. Эти кортежи и избыточность, которую мы создали, используя их, очень важны при переходе к следующему шагу GZIP алгоритма, известного как сжатие Хаффмана (Huffman). Для тех, кто не помнит сжатие Хаффмана, или заблокировал его в памяти со времен изучения компьютерных наук в течение 101 дня в вашем университете, Хаффман работает путем присоединения различной длины кодов к символам в вашем потоке, основываясь на вероятности. Идея состоит в том, что чем вероятнее символ и чем чаще он встречается в вашем потоке, тем меньше бит вам нужно использовать, чтобы его представить. Идеальный всемирно известный пример кодирования Хаффмана – азбука Морзе. В Английском языке, буква E доминирует во всех словах. Поэтому она представляется отдельным гудком, чтобы отражать его важность. Подобно ей работает сжатие Хаффмана. Сейчас мы хотим поделиться с вами знаниями о построении дерева кодирования Хаффманга и всем остальным. Это тонны книг структурирования данных. Вместо этого мы покажем вам, что мы увидим после парсирования нашей новой размеченной цепочки кортежей, что 0, 0 – это самый распространенный набор кортежей. И, конечно, мы можем отметить, что один бит является одним нулем. Таким образом, следующий набор 1, 1. У нас здесь два символа. И, основываясь на методе, по которому построено наше дерево, Мы должны предоставить двухбитные символы. Мы продолжаем и продолжаем и успешно присваивать различные битовые коды символам, создавая сжатую версию наших данных. Теперь эти два знака или два символа, работающие то вперед, то назад друг с другом, создают своего рода балет по тому, как создается контент и как он сжимается со статистическим кодированием. Это и есть краеугольный камень всего, о чем мы собираемся говорить в продолжении нашей беседы. Сейчас стоит отметить, GZIP – это не новинка. Фактически, GZIP насчитывает около 20 лет. Если бы он был человеком, он бы уже мог выпивать водить и делать прикольные штуки в интернете. Но другие алгоритмы сжатия, которые 451 00:18:18,190 --> 00:18:20,690 могут быть немного новее и слегка отличаться, могут предоставлять вам некоторые плюсы и минусы. Здесь я представлю четыре кодировщика. Первый называется LZMA. Некоторые из вас могут знать его лучше как 7-Zip, очень популярный инструмент архивирования. Вы можете заметить, что LZMA дает меньшее сжатие, чем GZIP. По причине того, что он содержит большее число поисковых алгоритмов, встроенных в LZ77 алгоритм. Фактически, LZMA можно считать дальним кузеном 464 00:18:48,310 --> 00:18:50,950 GZIP, потому что он очень прост в методе сжатия данных. Благодаря тому, что он использует более современную эвристику, и алгоритмы, он может достичь больших результатов. После LZMA, вы видите LPAQ. Это кодировщик, основанный на смешении контекста. По существу подбора парных символов, это Нейронная сеть. Заметьте, что LPAQ фактически дает нам самый маленький размер, в сравнении с чем-то еще - 0.35 мегабайт. Через пару секунд расскажу об этом подробнее. И последний инструмент сжатия, который мы рассмотрим, это BZIP2. BZIP – это современный вариант преобразования, предназначенный также, чтобы производить трансформацию или Хаффмана, или арифметическое кодирование в итоге. Сегодня BZIP2 в корне меняет метод сжатия. Он очень отличается. Без использования LZ77. Вместо этого, он использует сортировочную трансформацию, основанную на полублоках, для увеличения избыточности или подстройку избыточности в данных. Эта избыточность позволяет сжатию становиться лучше. И снова вы можете видеть здесь GZIP, который дает нам 0.48 мегабайт, BZIP превосходит и его. Что вы видите здесь в понимании размера данных, это работа, которую я проделал с домашней страницей amazon.com. Если я беру все текстовые данные из - данных HTML, CSS, JSON, и JS -- Фактически получается 1.64 мегабайт. Вы можете увидеть, как эти инструменты сжатия соотносятся с конкретными требованиями к памяти. И когда вы сравниваете инструменты сжатия, размер данных - не единственная эвристика. У вас есть две других эвристики, которые приводятся в миксе. Первая – время кодирования и вторая - время декодирования, которое зачастую гораздо важнее. Таким образом, если мы посмотрим на колонку времени декодирования, мы увидим, что GZIP показывает, скорее всего, самое быстрое время скорости кодирования, равное 0.79 секунды. LZMA, являющийся дальним родственником поисковой эвристики, Показывает близкие результаты - 1.26. Вы можете видеть, что победители по размеру сжатия выходят из большей предварительной обработки в начале этапа кодирования. LPAQ предлагает вам потрясающее сжатие, но заметьте, что процесс сжатия данных занимает более 11 секунд. LPAQ сегодня – современное чудо. Он использует различные формы смещения комбинаций контента, в результате получается искусственный разум, алгоритм нейронной сети для поиска наилучшего инструмента сжатия и разумно, что время обработки занимает 11 секунд, так как под капотом происходит множество процессов. Тем не менее, трансформация Буровса-Вилера, на которой основан BZIP2, не сильно отстает от отметки, но кодирование занимает примерно 2.1 секунду. Существует целый набор исследований, показывающих, что кластерная трансформация влияет на память и обработку, и всякое такое. Время декодирования, вероятно, - здесь самая важная часть. Вы можете видеть, что GZIP и LZMA идентичны в практических целях. В то время, как LZMA тратит больше времени на кодирование, похоже, что он производит меньшие файлы, чем GZIP, и время декодирования выходит примерно одинаковым. LPAQ, ввиду использования нейронной сети, тратит столько же времени на декодирование, сколько и на кодирование - примерно 11 секунд, Тогда как BZIP декодирует быстрее, чем кодирует. Основная идея этого слайда - единственная вещь, которую я бы хотел взять для себя-- что GZIP реально хорош в нескольких вещах, особенно, во времени кодирования. Он выигрывает по нескольким пунктам - в размерах сжатия в процессе архивирования и координирования со временем декодирования. Это не единственный алгоритм в смысле коэффициента сжатия. Мы отметили парочку таких частных случаев. LPAQ выигрывает в размере. По времени кодирования лидером является GZIP, и по времени декодирования- конечно, LZMA. Это может привести множество людей с технических веб-платформ ко мне, которые скажут- эй, GZIP реально хорош. Эти данные показывают нам, что мы и в самом деле не нуждаемся в других алгоритмах сжатия, потому что он дает нам приличное сжатие, приличное время кодирования, и приличное время декодирования. Ну, я должен здесь сказать Вам это - хороший аргумент, но давайте копнем немного глубже - должен ли GZIP быть единственным в сети. Так прежде всего Вы должны понять, что есть действительно не существует некой серебряной пули для сжатия. В зависимости от того, какие Ваши данные, как часто они повторяются, какие отношения они имеют с локальной информацией, все это касается того, насколько хорошо она может быть сжата в конечном результате, и различные инструменты сжатия обрабатывают эти данные по-разному. Например, если Вы применяете сжатие для JPEG к текстовым данным, Вы не сможете декодировать текст правильно, 573 00:23:21,330 --> 00:23:24,380 потому что возможна потеря или удаление информации из самого потока. Поэтому давайте приведем замечательный пример, который точно показывает, как GZIP работает без любых модификаций. Так скажем, у нас есть ряд целых чисел. Теперь, эта последовательность целых чисел была фактически создана, как система, индексированная в некоторая более высокую базу данных. Таким образом, 10 пунктов вносятся в указатель, и мы перечисляем их здесь. Теперь, если мы просто пропустим их через GZIP, мы получим немного. Это так, потому что, если Вы помните, алгоритм LZ77 не собирается находить любые двойные индексы в этом множестве. Девять встречаются только однажды, и другие числа - так же. Между тем, это означает, что все статистические вероятности для этого символа примерно равны. Нет никакой разницы. Ничто не является более частым или менее частым, что означает, что алгоритм Хафмана назначает примерно равную длину бита всем символам. По этой причине мы не получаем дополнительного сжатия из алгоритма GZIP для этого потока данных. Это означает, что вам нужно взглянуть на ваши данные И понять, что GZIP с ними делает? Если мы, однако, берем немного отличное колебание в самой проблеме, мы можем фактически поспорить, что GZIP мало знаком с нашими данными. Так скажем, мы берем оригинальное множество, и вместо того, чтобы просто оставить его как есть, мы отметим качества, по которым эта информация сортируется, потому что нам не надо, чтобы она появилась в тыльном кэше. Таким образом, если мы сортируем ее, мы фактически заканчиваем приличным увеличением разбега чисел - от нуля до девяти без любых промежутков в середине. Мы можем взять эту последовательность и применить технику, известную как кодирование дельты для создания различных наборов символов. Теперь, кодирование дельты работает, выбирая символ и открывая различие в символах между предыдущим символом, и оно кодирует различие вместо фактического значения. Таким образом для нашего конкретного примера здесь, мы начинаем с числа ноль и один на один больше, таким образом, мы добавляем к нему один. два больше, чем один на одну единицу, таким образом, у нас получается один, один, один, один, один, один. И Вы видите, что в случае кодирования дельты, все, что мы должны сделать, закодировать один и затем восемь нолей, чтобы представить оригинальную последовательность, имеющуюся у нас. В версии с кодированием дельты можно заметить, что в нем имеется множество повторяющихся символов, И там есть определенный символ, который доминирует среди других символов. Теперь, как только мы закодировали наши данные в эту форму, тогда для GZIP наступает звездный час. Алгоритм LZ77 находит множество совпадений в своем окне, и арифметическое сжатие может приступать и присваивать коды меньшей длины самым частым потокам. То, что мы вам здесь показываем, это всего лишь то, что вы можете ввести произвольные данные в GZIP и ожидать получения идеального, удивительного сжатия. Вместо этого, предварительная обработка может слегка изменить метод работы сжатия, чаще всего, к лучшему. Теперь, давайте посмотрим на другой идеальный пример, где GZIP может вызвать некоторые проблемы. Таким образом, если Вы посмотрите на мой веб-сайт, я провел небольшой анализ чуть позже на различных формах технологии минимизации CSS. Имелся фантастический набор кода, сделанный кем-то, использовавшим генетические алгоритмы, для выяснения оптимального способа уменьшения CSS данных. Давайте посмотрим на эту таблицу. Если мы возьмем два файла CSS из StackOverflow и Bootstrap, и мы фактически смотрим на их уменьшенные формы- таким образом, их уже пропустили через Closure или YUI или Clean CSS, одна из этих штук, которые весят примерно 90 и 97k, соответственно. Использование версии генетического алгоритма минификатора, который сжимает На 3% оба файла, означает, что то, что мы можем использовать различные варианты минификации, чтобы добиться того, к чему мы идем. Это хорошая идея. Если мы найдем лучший алгоритм, который лучше уменьшит наши данные, мы должны использовать его. Это случай, в котором GZIP и в самом деле вызывает проблемы. когда мы пропускаем эти данные, генетически алгоритмически уменьшенные данные через инструмент сжатия GZIP, Мы увидим отрицательные результаты. это означает, что он даже увеличивает данные. Таким образом мы получили версию.GZIP. Если мы заархивируем данные, выходящие из Clean CSS или Closure, мы получим 18 и 15k. Однако, когда мы заархивируем данные, которые были сгенерированы с помощью нашего генетического алгоритма, мы увидим, что мы увеличиваем размер файла. В основном, то, что Вы видите, состоит в том, что данные настолько минимизированы после использования генетического алгоритма, что GZIP только раздувает данные. Он делает Ваш файл, больше, чем он должен быть, потому что он использует только этапы кодирования LZ77 и Хаффмана. Это должно испугать множество людей, думающих насколько часто это происходит в интернете с файлами различных размеров. Я вам могу сказать, это случается не так уж и часто, но на это стоит обратить внимание, потому что четко доказывает, что GZIP – не серебряная пуля И что он может навредить в определенных условиях. Теперь, конечно, многие люди скажут, ладно, это значит, что мы не должны использовать этот генетический алгоритм для минимизации CSS. Очевидно, это провал. И я все еще думаю это это - неверный аргумент, но давайте продолжим. Давайте немного поговорим о PNG. Итак, PNG – формат, который вы можете фактически экспортировать в сжатой форме. Теперь о PNG изнутри, алгоритм сжатия, который он использует, называется выкачивание, в значительной степени эту же основу использует GZIP. Это LZ77 в паре со сжатием Хаффмана. То, что вы видите сейчас на экране, это два изображения. Я взял изображение 90 на 90 спрайтовых пикселей, и перекрыл его вертикально, создав изображение 90 на 270. Потом я понял, что изображение маловато и добавил две колонки пикселей, получив изображение 92 на 270 вместо 90 на 270. Так мы почти подогнали размер данных. В самом низу вы можете видеть, что размеры файлов, обработанных GZIP, существенно отличаются. Размер изображения 90 на 270 равен примерно 20 кб, Тогда как 92-пиксельного изображения – 41кб. Он в два раза больше только за счет двух колонок пикселей, добавленных к изображению. И снова используемый алгоритм сжатия - GZIP. Давайте посмотрим почему так случается и что происходит. Мы можем сказать, что у нас вышла пачка пиксельных цветов. запомните, что алгоритм LZ77 не подведет и постарается найти совпадения. Итак, здесь у нас есть определенный зеленый пиксель и другой зеленый пиксель, идентичный предыдущему в нашем потоке. И как же это все работает - LZ77 не будет сканировать бесконечно в поисках совпадений. Вместо этого он работает в окне весом 32 кб данных. Это означает, что если нужно учесть символ снаружи окна, он не будет находить совпадения. Он их будет находить только внутри окна в 32 кб. Если мы взглянем на наши изображения 90 на 90, Которые мы создали для перекрытия, В интервале 90 на 90, 4 байта на пиксель И весят они примерно 32 кб. Теперь мы смотрим на интервал 32 - 1,024, В реальном разрешении - 32 кб, это На 300 байт больше, чем наши 90 на 90. Хотя, когда мы добавили те две колонки пикселей, мы изменили размер и шаг нашего изображения. 90 на 92 к 4 - это 33кб, а не 32кб. Это значит, что когда мы попытаемся найти повторяющиеся пиксели в нашем изображении, мы вряд ли найдем тот самый пиксель, который мы видели раньше. Давайте рассмотрим наглядный пример. Итак, снова, у нас есть два изображения размером 20 кб и 41кб, И мы можем сделать двухмерную цветовую карту для представления этого изображения. Эта теплокарта показывает нам темно-синие пиксели, те, которые сильно сжаты. Это те места, где найдены совпадения. Они являются очень маленькими, закодированными пикселями. Между тем, красные и желтые означают что совпадений мы не нашли, И кодировка этих символов затратила гораздо больше бит. С левой стороны вы видите, там, где 90 на 270, найдено гораздо больше совпадений. Доминирующая часть изображения темно-синяя. Вы видите, что как только мы перекрыли изображение в нижних двух областях, Мы обнаружили точное совпадение 32 кб пикселей. Однако, когда мы увеличили размер на две колонки, мы вытеснили окно пикселей, на которое смотрели. То есть, мы не находим совпадений. Фактически, нам приходится искать ближайшие совпадения, И поэтому у второго изображения очень много пропусков в кэше LZ77, в результате кодирование ухудшается. В основном это показывает нам, что при малейших изменениях наших графических изображений, алгоритм GZIP проваливается с треском. И снова повторюсь, он далек от совершенства. по правде говоря, на данный момент я вам скажу, что будет здорово, если мы сможем использовать какой-либо новый алгоритм. Но в реальности мы застряли с GZIP до неопределенного будущего. И вот почему. Если вы перейдете к исходному коду Chromium, и взглянете на систему багов, предоставленную здесь, вы увидите удивительную историю о том, что Chrome принял формат сжатия BZIP2. В сущности, Chrome добавил его поддержку, и множество серверов-- Apache и многие другие -- добавили поддержку рассылки контента BZIP2. Фактически, сервер рассылает Файл BZIP2 вместо GZIP и отсылает его на сервер. И то, что происходит на практике, нам интересно, И результаты заставили нас отменить поддержку BZIP2 в Chrome. В результате получилось множество таких папок, к которым мы даже не ожидали применения других программ кроме GZIP, у них жестко закодированные дорожки, чтобы взглянуть и сказать, если для сжатия применялся не GZIP, сожмите его в GZIP. И тогда, когда некоторые серверы получали архив BZIP2 или файл с заголовком BZIP2, они могла взглянуть на него и сказать, о, это не GZIP. Раскройте заголовок, постарайтесь использовать GZIP, и затем отсылайте информацию. Это значит, что Chrome получит данные в упаковке BZIP2, заголовок которого был раскрыт, и затем их можно вновь пропустить через GZIP. Мы не имеем понятия в каком формате данные, которые мы получаем. Это может быть двоичная информация или действительная информация. Проблема состояла в том, что это случалось систематически на практике с различными типами программно-аппаратных средств и это было слишком сложно исправить, поэтому было разумнее просто удалить его из Chrome. Поэтому, когда вы говорите о возможности добавления других алгоритмов сжатия к основному браузеру, вы столкнетесь с той же проблемой. Существует множество систем, которые не понимают или просто не обновлялись для увеличения количества техник сжатия. Это натолкнуло нас на интересную идею, так, если мы застряли на GZIP, но размер текстовых данных остается проблемой, как нам создать меньшие файлы GZIP? Вам повезло, я провел последние три или четыре месяца полностью сосредоточившись на этой проблеме, вы можете увидеть результаты в моем блоге на mainroach.blogspot.com. Но вначале давайте познакомимся с некоторыми из этих идей, и затем вы сможете перейти туда и узнать об этих классных штуках. Для начала мы сможем создавать файлы GZIP лучшего качества. Многие люди этого не понимают, но когда ваш сервер создает GZIP файл, многие приноравливаются к его сжатию в два счета. Параметры командной строки, которую вы передаете GZIP, позволяет переходить от нуля до девяти, когда во многих серверах по умолчанию – от нуля до шести. Это выглядит как интересный компромисс между скоростью сжатия и размером сжатия. Это благодаря тому, что веб-разработчики обычно загружают на сервер сырые ресурсы, не желая заморачиваться со сжатием. Фактически, сам сервер отвечает за сжатие контента и рассылке его по запросам. И что интересно, вы можете изменять файлы и применять GZIP офлайн. И вам нужно будет 849 00:35:12,570 --> 00:35:15,040 вять вашу текстовую информацию, сжать ее в наиболее удобном GZIP, чтобы создать меньший GZIP файл, и сообщить серверу, что ему нужно передать эти файлы. Существует два приложения, которые могут производить меньшие GZIP файлы такого типа. Первый -7-Zip. по сути, это отличный инструмент командной строки, который может генерировать как BZIP2 архивы, так и GZIP архивы, но он выигрывает в более современных, более мощных поисковых и словарных, алгоритмах сжатия Поэтому им и пользуются. 7-Zip может генерировать меньшие версии файлов GZIP, чем стандартная командная строка архиватора GZIP и загружает большую часть программных средств с серверов. Следующий замечательный инструмент называется Zopfli. Он был создан инженерами Google для решения той же самой проблемы. Zopfli использует гораздо больше памяти и гораздо более продвинутые алгоритмы, чем 7-Zip для лучшего поиска совпадений на меньшем пространстве, чтобы создавать меньшие файлы GZIP. Это открытый проект. Вы можете проверить. Если вы заинтересовались, очень вам его рекомендую. Самое замечательное, что мы можем использовать как 7-Zip, так и Zopfli, как часть процесса по созданию меньших текстовых Файлов, и отсылать их от имени пользователя. Они являются формой GZIP, поэтому они будут приниматься как средними полями, так и браузерами. Теперь если вам интересно как эти системы преподготовки взаимодействуют со стандартными файлами GZIP, посмотрите на график. Вы видите голубую колонку с совокупностью файлов, которые являются стандартным алгоритмом GZIP. Красный цвет означает Zopfli, и зеленый - 7-Zip. По всем 42 файлам вы видите, что в среднем большую часть времени как Zopfli, так и 7-Zip опережают GZIP примерно на 2% - 10%. И если вы увеличите параметры и позволите Zopfli и 7-Zip потратить больше времени на поиск совпадений и процесс сжатия, вы сможете получить соотношение в 15%, это фантастика. Но цена тому невероятна. Множество этих алгоритмов занимает примерно 20 минут - по сути - чтобы выиграть от 1% до 5% дополнительного сжатия. В основном, что мы имеем - то, что мы достигли локального минимума сжатия. Чем больше времени мы потратим попытку сжатия контента, Тем меньше, меньше и меньше места мы сэкономим. Вы можете потратить шесть часов на вычисления в облаке, чтобы выиграть 2% к вашему алгоритму сжатия. Таким образом на данном этапе, вы должны посмотреть и сказать, хорошо, если мы и застряли на GZIP, хотя ему нужны дополнительные часы на вычисление мелких GZIP файлов, тогда о чем мы вообще говорим? Разве мы не застряли? Не волнуйтесь, друзья. На самом деле вы не застряли, и все сводится к вашим собственным данным. Вы можете создать меньшие файлы GZIP Путем предварительной обработки файлов До передачи их GZIP. Во многом как и в примере, который я привел ранее, где мы брали набор цифр и обрабатывали его дельтой для создания чего-то часто повторяющегося и хорошо поддающегося сжатию, вы можете применять эту технологию множество раз к вашей кодовой базе. Поэтому давайте рассмотрим некоторые интересные алгоритмы, которые мы сегодня можете использовать в своих проектах. Первый оказался близок и дорог моему сердцу. Как много приложений и веб-сайтов использует JSON, как формат передачи данных между клиентом и сервером. Обычно социальные сети рассылают такую информацию. Это - очень хороший, широко принятый формат файла для рассылки информации, особенно, потому что он построен на стандарте JavaScript. Теперь, когда Вы рассылаете эти данные, большую часть времени, пользователи и разработчики не думают о том, как изменить отсылаемые данные потому что он сжимает гораздо лучше. А если пользователь посылает поисковый запрос, сервер отправляет и вычисляет информацию и затем возвращает объект JSON, оптимизируя время кругового обхода. Он пытается вернуть данные пользователю так быстро, как это возможно. Но они не понимают, что если у них задействован флажок GZIP, то GZIP остановит операцию и заархивирует контент до отсылки его клиенту. Теперь, если Вы разработчик, который имеет дело со странами третьего мира или с другими возможностями подключения, которые могут редкими или неустойчивыми, то это огромная проблема, потому что устройство вашего клиента-- обычно мобильное устройство в 1G или 2G -сетях, которые могут быть стабильными, а могут быть и нет-- отсылает запросы, и затем им вредит получение большого объема полезной информации. И сейчас мы говорим о том, как вы можете обрабатывать файлы JSON , которые возвращаются пользователям в таком виде, что далее GZIP сможет их сжать? И все это начинается со способности перемещения ваших структурных данных в ваши файлы JSON. Давайте рассмотрим этот пример. Я прошерстил множество веб-сайтов и множество ответов JSON, и я вижу, что эта схема повторяется на многих сайтах. То, на что вы смотрите, это список словарных структур в парах имя-значение. Если кто-то задает поиск определенной вещи на сайте интернет-магазина, логично, что его возвращают к разделу словаря, который содержит название товара, его цену, миниатюру изображения, и так далее, и затем все это линейно записывает внутри массива. Что он создает – это интересный вопрос, эти данные, подобранные по принципу подобия, отдалены друг от друга. Они чередуются. Таким образом, у вас есть название и цена, которые могут быть значениями с плавающей запятой, и затем описание, в виде длинного блока текста, и затем ссылка, у которой есть свои особенности. При перемещении наших данных мы предлагаем Фактически развернуть эту пару значения-имени И де-чередовать его, вместо группирования подобных значений по названиям. Примерами служат эти два словарных объекта, у которых есть имена и значения расположения, и мы можем их переместить так, что у нас получится массив ответов и массив положительных ответов. Я знаю, что в JSON это выглядит странно, поэтому давайте представим это все графически. Итак, здесь сверху у нас массив со списком объектов, и каждый из цветных блоков представляет свойства этого объекта. Так зеленый у нас обозначает имя, синий - цена, и красный - какие-либо URL. И что мы можем сделать - перенести и выстроить в ряд зеленые, синие и красные блоки, позволяя однородным данным находиться в массиве с другими однородными данными. Теперь я объясню почему улучшение происходит за секунду, но давайте посмотрим поможет ли нам этот прием сохранить какие-либо данные. Если мы возьмем совокупность JSON файлов, вернувшихся с обычных веб-сайтов, я выберу несколько ответов с Amazon and Pinterest и whatnot—вы видите, что первая колонка представляет исходный размер в байтах, вторая колонка отражает исходные данные, обычно в формате gzip. Третья – размер данных после перемещения. Вы видите, что появилась некая вариабельность чисел, потому что мы, по сути, удаляем символы из цепочки на этом этапе. А в последней колонке мы видим сжатую в GZIP версию перемещенных данных. И теперь мы оказались в интересной ситуации, в которой некоторые файлы JSON, перемещенные сжатые данные, оказываются меньше исходных сжатых данных, и это означает, что мы выигрываем, применяя этот процесс. Благодаря этому, мы попадаем в область, где CSS, уменьшенный с помощью генетического алгоритма, заставляя GZIP увеличивать размер данных. И мы этого не хотим. Операция перемещения дает нам меньшие файлы, это фантастика. Причина в том, что, работает он в окне размером 32 кб, которое LZ77 использует для поиска совпадений. Таким образом, если у нас есть значения, которые чередуются -- красный, зеленый, синий, красный, зеленый, синий, красный, зеленый, синий - снова, we и мы продолжать, чтобы найти части контента, в которых могут быть точные совпадения. Однако, когда мы перемещаем наши данные, мы устраняем чередования и группируем одинаковые типы данных. Так скажем, мы фактически пытаемся найти совпадения наших зеленых значений. В верхнем множестве Вы видите, что весь список данных, зеленый, может не подойти окну в 32 кб. Между тем, как только мы перемещаем его и группируем однородные данные, все зеленые данные подходят единственному окну. Это позволит Вам найти лучшие совпадения, которые Приведут к меньшим значениям сжатых данных. Теперь мы подошли к следующему шагу, с которым все в порядке, Если мы можем переместить наши данные, как еще мы можем изменить контент так, чтобы остаться в выигрыше? У нас есть действительно замечательный алгоритм, который я нашел в архивах IEEE, известный как увеличение сжатия. Он работает с теми же параметрами. Как мы предварительно обрабатываем Файлы для лучшего сжатия? Первый, который мы собираемся рассмотреть, называется Dense Codes. Это результат исследования неких исследователей из Аргентины и позволяет брать текстовые файлы, подвергать их предварительной обработке и передавать их GZIP. Предварительная обработка здесь является очень важной. Мы не перемещаем файлы, по сути, вместо этого мы используем модифицированную словарную схему поиска. Скажем так, мы разбираем наш текст и создаем словарный индекс. Таким образом, как только слово замечено, мы отправляем его в словарь, и затем каждая ссылка на это слово заменяется параметром индекса во множестве. У нас есть множество, "How much would could a woodchuck chuck," и до него у нас есть 400 символов. Поэтому "how" имеет расположение 400, 401 - "much," 402 - "wood," 403 - "could." Поэтому, когда мы создаем поток, мы стараемся получить значения, которые указывают на это множество. Проблема в том, что у на есть всего 256 символов, и мы можем использовать только 8 бит на указатель. Однако, если у нас больше 256, мы можем использовать 16 бит на указатель, что является проблемой, потому что если символы весят столько, что наиболее вероятные и наиболее видимые символы ближе к началу словаря, вы просто потратите массу места. У вас будет множество символов и параметров, где первые верхние 8 бит будут нулями с основной стороны. Тем самым вы раздуваете поток на данный момент, потому что используется слишком много бит. И то, как работает Dense Codes, позволяет вам изменять использование маркеров для создания возможности создания различной длины кодов в цепочке, что значит, что для первых трех чисел мы используем 16 бит, чтобы представить параметры вторых трех чисел, потому что их параметры ниже, чем 25 бит. Мы можем Использовать 8 бит вместо 16. Это создаст меньший поток для сжатия позже. На наш выигрыш интересно взглянуть, потому тут есть несколько пунктов, у меня в блоге есть 10-страничная запись об этом алгоритме и что интересно, это то, что можно переключаться между ними, там есть некоторые оговорки и вещи, которые нужно знать но все сводится к этой таблице. Что нам показывает таблица - мы пытались сжать исходные данные, и затем мы пытались пропустить наши данные через плотную кодировку-- это колонка ETDC – и затем gzipping информации. Следом я сравниваю другие инструменты сжатия, которые мы сегодня упомянули-- Zopfli, 7-Zip, и BZIP2. и что я хочу здесь увидеть - когда я провожу предварительную обработку, какой алгоритм сжатия даст нам лучшие результаты? Вы легко можете увидеть, что, GZIP не дает экономии места после предварительной обработки этим методом у большинства данных, обсуждаемых здесь--файлов JSON, CSS. И мы встречаем порядка 25,000, 30,000 файлов и вы увидите подобную схему, с которой работает GZIP, эта информация не дает нам никакой выгоды. Однако, когда вы начинаете использовать Zopfli, вы заметите некоторые преимущества. Продвинутая схема поиска соответствий и использование большего объема характеристик памяти, доступной в кодировщике, позволяет вам находить больше совпадений, и создавать меньшие файлы. Явный победитель здесь - 7-Zip. Что-то внутри подхода к использованию этого алгоритма последовательно создает сжатые файлы меньшей плотности в сравнении с исходными данными, что интересно, если у вас есть данные больше определенного размера. Скажем, вы по какой-то причине возвращаетесь к вашему скоплению данных в 20 кб. Предварительная обработка, которая руководит плотной кодировкой, и затем использует 7-Zip, как выбранный вами инструмент сжатия, который сможет последовательно создавать GZIP файлы. Но его недостатки, конечно, состоят в том, что вам придется перестраивать трансформацию плотной кодировки клиента, но это не обязательно будет большой проблемой в зависимости от того, какого компромисса нам нужно достичь. На сегодня это все схемы предварительной обработки. Существует другая форма обработки данных, которая может принести выгоду, недоступную другим. Я имею ввиду, что типы выгоды, о которых мы собираемся поговорить, Delta.js разносит эту схему предварительной обработки в пух и прах, но будьте в курсе. Здесь обитают драконы, по большей части, в форме безрассудства. Давайте углубимся в то, о чем я говорю. Так в 2012, команда Gmail сделала фантастическую презентацию W3C, и включила некоторые слайды, доступные для общественного ознакомления, предлагающие решение частых проблем. Как вы видите, пользователи Gmail уже 61 год видят меню загрузки Gmail каждый день. пользователи уже очень долго сидят в ожидании появления JavaScript. То, что они предложили, было новой формой способности - вместо передачи крупных файлов они могут начать передавать разницу между файлом, который есть у пользователя, и новым файлом, который пользователю нужен. Эта концепция не нова. Мы видели двоичные системы накладок такого типа в вычислениях с конца 1970-х, но их не получалось применять в интернете из-за применяемой архитектуры. Вот как работает алгоритм. Скажем, у нас есть файл, file.CSS версия ноль, и мы сделали для него обновление. Это слишком часто случается в крупных проектах. Теперь, когда мы делаем обновления, большинство файлов такие, какими они должны быть. Они могут быть добавленной функцией, или комментариями, или удаленными данными, но большинство файлов почти идентичны, и это значит, что мы можем представить второй файл, новый файл, как разницу между этим файлом и файлом, который мы видели ранее. Эта концепция работает по принципу, кодирования дельты. Тогда как мы закодировали данные с помощью дельты, патч—разница между ними двумя -- гораздо, гораздо меньше, с обновленной версией Файлов, и это значит, что мы можем представить, версию один как патч версии операции номер ноль. Это значит, что если у пользователя уже есть первая версия на его устройстве, все, что нам нужно сделать - выслать и ему патч, что позволяет ему перестроить и создать новую версию данных. Эта концепция очень интересна, так как это значит, что нам не нужно высылать полные версии файлов клиентам каждый раз. Вместо этого мы можем создать и выслать этим ребятам очень, очень минимизированный контент. Конечно, это немного расточительно в плане связи. Вы видите, чтобы это работало, у нас должен быть налажен процесс коммуникации между клиентом и сервером. Скажем, у нас есть мобильное устройство и пользователь собирается загрузить веб-сайт. Клиент должен уведомить сервер о том, какая версия Файла уже находится в кэше. Сервер может получить эту информацию, поискать ее в массиве данных и выяснить какой патч-файл нужно выслать клиенту, чтобы снабдить его актуальными данными. Как только сервер это выясняет, он передает данные клиенту, и затем клиент может использовать этот патч для создания новой версии Файла и загрузить его в кэш и должным образом его использовать. По сути, эта техника обменивается сетевыми запросами для получения меньших размеров файла. Отсылка запроса в пару байт для определения версии файла, имеющейся у вас, будет диаметрально противоположной тому, если бы мы каждый раз отсылали пользователям полноразмерные файлы. Если для вас это звучит как безумие, просто подождите. Вам нужно осознать, что это частая проблема для многих промышленных веб-сайтов, обслуживающих каждый день миллионы серверов. Вы видите, что работники Gmail просто оценили размер выгоды, который даст им этот алгоритм, они увидели огромный потенциал для улучшений. Когда они сравнили число проверок одного единственного файла в течение месяца с размером дельт, если они использовали эту схему, они увидели изменения ценой в целый месяц - около 9%-- меньше, чем 9%-- от размера ресурсов И это значит, что они должны послать 9% контента, в сравнении с новый полноразмерным файлом и это огромная выгода. Мы не говорим о 10% улучшении. Мы не говорим о 50% улучшении. Это 90% уменьшение размера, За счет использования алгоритма дельты. Очевидно, что это заявка на спецификацию W3C. Я разговаривал с несколькими ребятами из Gmail. Мне не кажется, что на серверах это все работает. Если ситуация изменится, я надеюсь, что я ошибаюсь, потому что это фантастическая технология, И я надеюсь, что она развернется в какую-то форму для многих распространителей в сети. Сегодня существует другая Форма такого сжатия, я которым работаю я. Оно обычно проявляется в форме горизонтального сжатия. Обычно, когда мы думаем о дельта кодировании для файлов, о которых мы думаем в контексте патчей. У меня есть версия A и версия B, и я хочу создать патч для них обеих. Так обычно работает разработка игр. Хотя, там существует некая форма, называемая горизонтальной. Как это работает - скажем, у нас есть последовательность файлов, подобная веб-сайту. Этот конкретный вею-сайт использует три CSS файла. Например, это Bootstrap или что-то подобное. Интересно то, что эти CSS файлы обычно не отличаются друг от друга. По сути, это синтакс широкого пользования для данного CSS файла, и значит, что вместо проведения дельта сжатия в версиях файла, мы должны провести сжатие в файлах, которые будут отосланы пользователю. Мы должны сделать различными файлы ноль и один, и затем файл один и файл два. Это позволяет нам сздавать патчи для каждого из них, и когда мы объединим его с исходным файлом вашего сервера, размер ресурсов, которые нужно отправить клиенту, радикально уменьшается. Вообще, мы можем послать им полноразмерное приложение и весь контент, требуемый как дельты из базы файлов. И это всего лишь экстраполяция различных форм алгоритмов дельты, которые уже использовались на практике. Как же это работает со стороны клиента - сервер, конечно, предоставит Клиенту базу файлов и набор патчей, и тогда клиент ответствен за перестройку каждого из этих файлов и затем за их локальное кэширование. Это отличная идея, если вы попытаетесь оптимизировать первоначальную загрузку для пользователей. Предложенная Gmail спецификация требует, Ччтобы пользователь скачал версию файла номер ноль, которая в некоторых случаях может содержать 300 кб CSS данных. В то же время, горизонтальное сжатие предполагает, что этого можно не делать. Можно просто переслать байты или фрагменты данных в размере 50 кб, когда вы представляете CSS как дельту. По сути, то, что вы делаете в этой горизонтальной схеме, - вы осуществляете обработку на стороне клиента для передачи меньших размеров. У клиента процесс реконструкции этих файлов занимает множество циклов CPU до того, как передать их обрабатывающей системе для создания DOM и всего остального. Поэтому существует компромисс между Delta.js или вертикальным дельта-кодированием файлов и горизонтальным дельта- кодированием файлов. Теперь мы можем видеть, что я применил эту технологию к различным сайтам в интернете, на которых мы обнаружили интересные раздутые значения. Я взял все CSS из сессии Gmail, все JavaScript из сессии Gmail, и все CSS из сессии Amazon, и пропустил их через эту технологию. Вы видите, у нас получился источник, источник GZIP и затем размер данных закодированных дельтой, и конечно, сжатие данных, закодированных дельтой, посредством GZIP, потому что мы не можем остановиться на дельта-кодировании. На примере Gmail вы видите, что мы получили потрясающую экономию - 31% и 12%, используя горизонтальное кодирование дельта-сжатия. В то же время, нечто странное происходит с данными Amazon, где у нас данные увеличились на 13%. Теперь я должен обратить внимание, что эти данные очень-очень минимизированы и высоко-избыточны. все эти файлы, которые создают множественные сетевые запросы обычно бывают самоподобными, благодаря процессу минификации, примененному к этому файлу в сети. Пример того, как важна минификация, - это горизонтальное дельта-сжатие, давайте взглянем на библиотеку игр, называемую Impact.js. Мне нравится эта библиотека. Она фантастична. Если вы разработчик игр и вы возлагаете надежды на создание HTML5 игр, тогда определенно загляните на Impact.js. Фактически, я взял исходные файлы и оставил их свободными файлами. Я не объединял их в один большой файл. По существу, я создал дельту между этими файлами и затем создал ее версию GZIP. Теперь вы видите, что размер снижается с 70k до 21k. Однако, когда я минимизировал все файлы, до того, как провел дельта-сжатие, я получил больше экономии места. Я получил около 14кб. Это потому, что технологии минимизации, которые мы сегодня используем в интернете, создают множество повторяющихся символов, которые можно использовать в различных целях. Теперь, когда вы видите оригинальные примеры, выборки и переименования некоторых параметров, и передачи их как ABC, мы стремимся увидеть схему, работающую для JavaScript, дя каждой функции, которая была определена, и это означает, что мы увидим больше совпадений. Больше совпадений приводит к большей статистической вероятности, что и приводит к меньшему размеру файлов. Поэтому минимизация наших данных до применения дельта-сжатия, мы получаем гораздо большую выгоду. То, о чем мы сегодня говорили, это место GZIP на веб-платформе. У нас множество текстовых данных, которые вскоре взорвутся. У нас есть мобильные устройства. У нас есть фрагментированные аппаратные решения. У нас есть возможность подключения по всему миру, но некоторые вещи позволяют вам воспользоваться преимуществами и справиться с проблемами, вместо ожидания увеличения сетевого времени. Например, мы выяснили, что GZIP не является серебряной пулей. Предварительная обработка данных может принести вам большую экономию места. Мы видели примеры, где GZIP с треском проваливается. Если вы провели много этапов предварительной обработки, он не сожмет ваши данные, и даже может их увеличить. Или в случае с PNG, Изменение незначительных параметров окна поиска совпадений может нарушить прикрепление GZIP к вашим данным. Также мы рассмотрели как предварительно обработать ваш контент с использованием различных форм других алгоритмов командной строки, таких как Zopfli или 7-Zip, и затем как перемещать ваши данные JSON, которые просто удивительно подходят для ваших интернет-магазинов. И когда вы объединяете их с повышением плотности кода, который находится на передовой позиции предварительной подготовки текстовых данных, у вас появляется чувство, что интернет развивается. Вы не заперты в той Форме, что у вас есть. затем вы смотрите на методы дельта-сжатия и на пути для объединения данных различных способов уменьшения дупликации и сложностей контента, которые у вас есть. И когда вы применяете это все вместе, вы приобретаете понятие об интернете, что мы можем контролировать больше данных, чтобы уменьшать размеры и избежать множества помех и проблем, которые может доставить GZIP. На этом спасибо за ваше время. Спасибо, что выслушали мою болтовню о некоторых очень сложных инструментах сжатия. Если вам интересно, я очень рекомендую посетить html4rocks.com. Недавно я разместил две статьи о сжатии текста для веб-разработчиков, а также о сжатии изображений для веб-разработчиков, и они предназначены для открытого доступа и обучения, чтобы познакомить вас с различной терминологией и алгоритмами и как их использовать. Повторюсь, обязательно загляните под хэштег #perfmatters. Там много умных людей. Присоединяйтесь к сообществу Web Performance в Google+. Снизу вы можете найти короткую ссылку as goo.gl/webperf. Это прекрасное место, чтобы поговорить о проблемах производительности и обнаружить проблемы. С меня достаточно. Меня зовут Colt McAnlis. Здесь вы можете связаться со мной по электронной почте и в различных социальных сетях. Еще раз спасибо за просмотр этого выпуска Google Developers Live. Надеюсь увидеть вас снова. Спасибо.