Клиентская оптимизация *

Представьте, что ваш пользователь нажимает «Установить» — и уже через минуту кидает коллеге ссылку на готовую инструкцию. Никаких «позже разберусь», форм авторизации и лишних вкладок. Это и есть оптимальный он-бординг, за которым сегодня охотится каждый продукт.

Меня зовут Алексей, я делаю Steppo — расширение, превращающее клики в наглядные гайды. Последние полгода я усердно измеряю Time‑To‑Value (TTV): сколько секунд проходит между установкой и ценностью, когда человек говорит «Вау, оно работает!». Всё, что дольше 60 секунд, статистически превращается в болотце, где тонут конверсии.

Какое-то время назад memorysafety.org объявил о конкурсе по повышению производительности rav1d — порта AV1-декодера dav1d на Rust.

Моя фамилия Равид, совсем как название декодера, поэтому я решил, что будет забавно попробовать (хоть я и, вероятно, не смогу участвовать в конкурсе).

Эта статья посвящена двум найденным мной небольшим улучшениям производительности (первый PR, второй PR) и рассказу о том, как я их нашёл.

Скорость загрузки страниц — один из ключевых факторов, влияющих на успех сайта в интернете. Она влияет на пользовательский опыт, конверсию и SEO. Google учло это уже в 2010 году, сделав скорость загрузки фактором ранжирования. В 2018 году метрики были расширены, а в 2020 — дополнены новыми обновлениями.

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

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

Разбираемся, в каких сценариях «Аврора» уже превосходит Android: безопасность, кастомизация, импортозамещение — и где системе ещё есть куда расти.

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

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

Привет! Это снова Максим из Яндекс Браузера. Мы с командой продолжаем делиться историями об интересных и неочевидных оптимизациях производительности, которые внедряем в наш браузер. В прошлый раз мы писали о том, как улучшили стабильность GPU‑процесса, воспользовавшись оптимизациями в драйверах видеокарт, сделанными специально для Google Chrome. А сегодня речь пойдёт об ускорении старта нашего браузера на Windows.

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

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

Рассматриваем различные «приколюхи» из C++20 на примере хеш‑мапы!

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

В течение последнего полугода команда Discord по обслуживанию медиа-инфраструктуры модернизировала конвейер обработки изображений, добавив поддержку анимированных форматов WebP и AVIF. Теперь на платформе можно делиться анимированными картинками WebP и AVIF как в виде прикреплённых файлов, так и в виде вставок. При этом все эмодзи выдаются в виде анимированных WebP — и бесшовно отображаются на любой платформе Discord. Эти изменения были реализованы для того, чтобы повысить качество анимации и воспроизведения роликов на всех платформах. При этом одновременно резко уменьшается размер файлов, и поэтому их загрузка ускоряется!

Здравствуйте, дорогие читатели! Сегодня мы рассмотрим policy-based routing (маршрутизацию на основе политик) и его практическое применение в лабораторной работе с использованием GNS3. Вся информация будет представлена на практике. Вот наша топология, с которой мы будем работать. Маршрутизация будет осуществляться с помощью протокола OSPF.

Наша топология:

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

Теперь, с высоты уже немалого времени докладываем: 1) идея себя оправдала и даже превзошла самые смелые ожидания; 2) работа по совершенствованию технологии была проделана; 3) работы было и будет очень много. Собрали для вас хайлайты этой увлекательной и яркой истории.

Я написал на C# консольный клон Wordle, но попытался сделать двоичный файл максимально крошечным.

Я взял популярную игру Wordle с такими правилами:

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

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

В работе с консолью мне помогла игра Console Games - Snake

Проект запускается в новой консоли dotnet.

Сериализация

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

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

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

Обычный день нарушений на ratpstatus.fr.

В репозитории GitHub сайта ratpstatus.fr содержатся все файлы JSON, запрашиваемые из open-data API каждые две минуты. Данные сохраняются там уже почти год. Репозиторий с 188 тысячами коммитов и более чем 10 ГБ собранных данных всего лишь в одном последнем коммите (измерено при помощи git clone --depth=1) — это определённо интересный выбор для реализации базы данных! Уточню, что в этом посте я не собираюсь критиковать эту систему. Веб-сайт статуса сети RATP — превосходный веб-сайт, мгновенно и стабильно предоставляющий полезную информацию без обычного сегодня раздувания веб-сайтов. [И нет, сайт не написан на Rust. Веб-сайт на PHP тоже может быть невероятно быстрым!]

Тем не менее, размер базы данных (10 ГБ) заставил меня призадуматься: а можно ли сжать её лучше, потратив на это приемлемое количество времени (скажем выходные)? В этом подробном посте я расскажу, как использовал шаблон проектирования interning в Rust, чтобы сжать этот датасет в две тысячи раз! Мы посмотрим, как лучше структурировать сам интернер, как настроить схему данных для оптимальной работы с ним и как сделать так, чтобы сериализация использовала interning наилучшим образом.

Если у вас в хранилище накопилось множество файлов JSON, то вам стоит прочитать эту статью!

Зимой 2024 года я восстанавливал IBM PS/1 486-DX2 66Mhz, «Mini-Tower», model 2168. В подростковом возрасте я мечтал о таком компьютере, но не мог себе его позволить. Не могу выразить словами, насколько меня радовала работа над этой машиной.

Как только мне удалось его запустить, я сразу же провёл бенчмарк одного ПО.

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

Как уместить словарь размером 250 КБ в 64 КБ ОЗУ с возможностью выполнения быстрого поиска? Для справки: даже современные методики сжатия наподобие gzip -9 не могут сжать этот файл до размера меньше 85 КБ.

В 1970-х Дуглас Макилрой столкнулся с этой непростой задачей при реализации проверки правописания для Unix в AT&T. Из-за ограничений компьютера PDP-11 весь словарь должен был умещаться всего в 64 КБ ОЗУ. Кажется, подобную задачу решить невозможно.

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

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

Привет, хабрачитатели! Server-Driven UI (SDUI) — это подход, при котором сервер управляет отображением интерфейса на клиенте. Важное преимущество SDUI — возможность внедрять изменения без выпуска новых версий приложений. Но это же преимущество есть его недостаток, ведь передача всех данных по сети зависит от качества соединения и увеличивает объём данных. 

Качество связи мы не можем контролировать, а вот уменьшить количество передаваемой информации посредством сокращения JSON, — вполне.