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

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

Нам казалось, что в диспетчерской Яндекс Go всё под контролем. Потом мы запустили аналитический скрипт и выяснили, что 37% интерфейса частично не переведено и пользователи за рубежом видят винегрет из родного языка и дефолтного английского.

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

Я всю жизнь писал только бэк и подкапотщину - будь это классический КРУД, хайлоад, CLI, [вставьте свое]... И для любых сетевых взаимодействий чаще всего люди думают именно прикладными вещами - GRPC, REST, Kafka, не задумываясь об этом глубже - супер удобные инструменты с защитами от дураков и прочими радостями

Но тут спохватился я писать фронт - подключать свое же к себе же. И в этот момент я понял, насколько же это сложно, муторно и, главное, НЕУДОБНО взаимодействовать REST'ом

ЗАЧЕМ ОН НУЖЕН?? - У нас нет удобного контракта общения (eg Proto, Avro) кроме Swagger, который нужно поддерживать с обеих сторон. Да и к тому-же, сложность взаимодействия с JSONом с ОБЕИХ СТОРОН - одна постоянно маршаллит, защищается, ищет поля, в то время другая боится резких обновлений, что строчка получения поля может превратиться в что-то в роде

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

Представьте: пользователь заходит на ваш сайт с iPhone (неважно, нового или трёхлетней давности) — и страница зависает, изображения грузятся по одному, скролл дёргается. Через 5–10 секунд он просто закрывает вкладку и уходит к конкурентам. Проблема не в вашем телефоне или интернете, а в скрытых особенностях браузера Safari и устройств iOS.

Ниже — руководство по оптимизации, которое поможет избежать таких сценариев. Пройдитесь по чек‑листу и убедитесь, что каждый пункт выполнен. Даже если ваш сайт кажется быстрым, с большой вероятностью он теряет часть аудитории на Safari.

Давайте рассмотрим реализацию конвеевской игры «Жизнь» при помощи графической карты. Я хочу поэкспериментировать с разными библиотеками и методиками, чтобы понять, как обеспечить наилучшую производительность. Начнём мы с простого и постепенно будем повышать сложность.

Игра «Жизнь» — это простой клеточный автомат, поэтому она должна хорошо поддаваться GPU-ускорению. Правила просты: каждая ячейка в двухмерной сетке или жива, или мертва. На каждом шаге мы подсчитываем живых соседей ячейки (включая диагонали). Если ячейка жива, она остаётся живой, если живы два или три её соседа. В противном случае она умирает. Если клетка мертва, она оживает, если живы ровно три соседа. Из этих простых правил возникает потрясающий объём сложности, о котором написаны подробные статьи.

Для простоты я буду рассматривать только сети N×N и пропущу вычисления на краях. Всё будет работать на Nvidia A40, а бенчмарк производительности я буду проводить при N=2¹⁶. Пока мы будем хранить каждую ячейку в виде 1 байта, поэтому весь массив займёт 4 ГБ.

Весь код выложен в репозитории GitHub.

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

Поэтому три компромисса закладываются в дизайн исследования задолго до старта поля:

Yandexbot заходит на ваш SPA сайт, получает пустой <div id="root"></div> и уходит. Именно так выглядит индексация большинства одностраничных приложений без SSR. Страницы не попадают в выдачу, органический трафик стоит на нуле, а команда недоумевает: сайт же работает.

Проблема не в качестве кода, а в архитектуре рендеринга. Поисковые роботы медленно или вообще не выполняют JavaScript, а значит, видят страницу до того, как ваш React или Vue успел что-то нарисовать. Настройка Server Side Rendering для индексации SPA приложений поисковиками решает эту проблему: HTML приходит уже готовым прямо с сервера.

Привет! Я Пётр Гришечкин, эксперт в области SEO для e-commerce. Последние 15 лет я проектирую системы кратного роста трафика для крупнейших сайтов. И последнее время пишу всякие околоSEO статьи – https://t.me/seo_and_sem

Это статья написано для начинающих frontend и backend разработчиков, которые хотят разобраться с технической SEO-оптимизацией. Здесь будут конкретные команды, примеры кода для React/Next.js, Vue/Nuxt.js и Angular, а также чек-лист внедрения.

На рождественских каникулах я ехал на автобусах из одного штата в другой, и мне нужно было как-то убить 24 часа. Я читал об UTF-8 и узнал об этой кодировке нечто интересное: все традиционные символы ASCII сохранены в ней в их исходном однобайтовом представлении, поэтому их можно сканировать крайне быстро. Я решил поэкспериментировать с кодом, максимально быстро подсчитывающим такие символы, в результате получив готовый парсер CSV, который вполне сравним с предыдущими парсерами, а то и быстрее них.

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

Кошмар с автозавершением

Наше префиксное дерево было в 8 раз медленнее хэш-таблицы. И оно потребляло 128 МБ памяти, в отличие от хэш-таблицы с 24 МБ.

Такого не должно было произойти. Префиксные деревья — стандартное решение для автозавершения: поиск за O(k), где k — длина строки вне зависимости от размера датасета. Идеально подходит для сопоставления префиксов. Обычно всегда используется для автозавершения, проверки правописания и таблиц IP-маршрутизации.

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

Поэтому мы реализовали префиксное дерево. Результаты бенчмарка оказались ужасными:

Префиксное дерево было в 8 раз медленнее простой хэш-таблицы. И оно использовало 128 МБ памяти, в то время как хэш-таблица — всего 24 МБ.

Где мы ошиблись?

Загадка базы данных

Вся наша база данных находилась в памяти, однако операции поиска по ней занимали 12 тысяч тактов. При миллионе показаний датчика IoT-устройства с 64 КБ кэша реализация красно-чёрного дерева оказалась слишком медленной для запросов в реальном времени.

«Давайте попробуем B-дерево», — предложил я.

«Разве они нужны не только для баз данных на дисках? — спросил лид, — У нас всё находится в памяти. Чем нам будет полезно B-дерево?»

Вопрос был вполне разумным. B-деревья были придуманы для доступа к диску; каждый узел в них — это блок диска. Однако паттерны промахов кэша выглядели подозрительно похожими на паттерны дискового ввода-вывода — всего в 100 раз, а не в 100000 раз быстрее.

В итоге мы реализовали B-дерево. Результаты удивили всех...

Катастрофа с красно-чёрным деревом

Компилятор тратил 60% времени на поиск символов. Не на парсинг, не на генерацию кода, просто на поиск в таблице символов.

Для типичной программы на встраиваемой системе с 10 тысячами символов это было неприемлемо. В таблице символов хранились имена переменных, имена функций и определения типов. В реализации использовалось красно-чёрное дерево — самобалансирующееся дерево двоичного поиска.

«У него O(log n); судя по учебникам, оно идеально подходит для этой цели», — сказал мой коллега.

Но профилировщик показывал иное...

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

Наверняка вы слышали о новых версиях HTTP — второй и третьей. Что за этими версиями? Зачем они были разработаны? Чем они отличаются от классического HTTP/1.1 и где могут быть полезны? Какие настройки предоставляет веб‑сервер Angie для этих протоколов? Все эти вопросы мы будем разбирать в этой статье.

Начнём с краткой истории развития протокола HTTP.

Миф про O(1)

Говорят, что хэш-таблицы обеспечивают поиск за O(1) — константное время, вне зависимости от размера. В теории они идеальны.

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

Я оптимизировал таблицу символов для компилятора. Таблица символов использовала хэш-таблицу с 1024 бакетами, и у нас было примерно 500 символов. Расчёты выглядели отлично: средний размер бакета = 500/1024 ≈ 0,5, поэтому большинство операций поиска должно выполняться за один запрос.

Но профилировщик рассказал иную историю...

Привет, Хабр!

Менеджеры продаж не всегда вовремя и полно заносят данные о сделках в CRM после звонка. Часть информации может забыться, а часть может быть записана сокращенно.

Прослушивать звонки вручную и восстанавливать детали слишком трудоёмко, а ресурсов на это часто не хватает. Поэтому в этом материале соберём MVP-сервис на Python, который получает событие о завершённом звонке из МТС Exolve, забирает текст разговора, выделяет из него ключевые поля через YandexGPT и записывает результат в Bitrix24. На выходе получится рабочий пайплайн: вебхук, транскрибация, извлечение полей квалификации и обновление существующей сделки в CRM.

За основу возьмём BANT — базовый фреймворк квалификации лида: Budget, Authority, Need, Timing, то есть бюджет, лицо, принимающее решение, потребность и сроки. И расширим его, добавив оценку интереса клиента, фиксацию конкурентов и возражений. Такого набора достаточно, чтобы квалифицировать лид, приоритизировать сделку и сохранить контекст следующего контакта, но не превращать карточку в анкету на десятки полей.

Стек: Python 3.10+, Flask, SQLite, Call Transcribation API МТС Exolve, YandexGPT API, Bitrix24 REST API.

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

Для измерения скорости сервисов в Яндексе используется метрика Velocity Index — это агрегация метрик Web Vitals (FCP, LCP, TBT, INP, CLS). Итоговое значение получается в диапазоне от 0 до 100 баллов. Хорошим результатом считается индекс больше 85.

Мы поставили себе амбициозную цель: увеличить Velocity Index до 85, а заодно подлечить очевидные «узкие места» в скорости и ускорить всё, до чего сможем дотянуться.

Но до заветных 85 баллов мы так и не добрались.

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

В помощь начинающему, продолжающему и заканчивающему автору.

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

В этом гайде я покажу, как собрать двунаправленный бесконечный скролл с нуля. Здесь React и @tanstack/react-virtual, но сама техника — просто математика над scroll offset. Работает так же в Vue, Svelte или на ванильном JS.

Демо | Исходный код

Привет, Хабр! Меня зовут Виктория Мохирева, я консультант SAP MM. Сегодня расскажу о том, как мы с командой решили колоссальную задачу инвентаризации — пересортицу товаров — с помощью интеграции SAP с большой языковой моделью (ИИ).

Вот как бывает в обыденности магазина: пришёл товар, на учете кружка, а на полке по факту тарелка. Начинается танец с бубном из таблиц, сверка номенклатур и постоянные акты. Чтобы автоматизировать подбор правильных групп для пересортицы, мы написали инструмент, который позволяет общаться с ИИ напрямую из SAP GUI. Решение получилось достаточно компактным и элегантным. А под капотом у нас — архитектура, ключевые куски кода и логика, которые помогли нам превратить «регулярный ручной труд» в интеллектуальный диалог с машиной, и теперь у нас не разрозненная масса товаров, а сформированные по определенным параметрам логичные группы.

«Простота — требование, необходимое для обеспечения надёжности», — Эдсгер Дейкстра

Невидимая структура данных

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

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

Однажды я отлаживал вылет прошивки во встраиваемой системе RISC-V. У системы был планировщик задач, использующий очередь для управления ожидающими задачами. При большой нагрузке система вылетала с переполнением стека.

Переполнение стека? Очередь должна была находиться в куче, а не в стеке.

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

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

Краткий итог нашего изучения рынка и создания собственного бота (почему это так - читайте ниже):

Промпт-бот (500 ₽ фриланс + 50 000 ₽/месяц API):
Используйте, если нужно простое FAQ-покрытие, вся база знаний умещается в короткий промпт, нет регуляторного риска и вы понимаете, что принимаете риск галлюцинаций и нарушений ограничений. Хорошо для демонстрации возможностей. Не подходит для финансовых услуг, медицины, юридических вопросов или любой области, где неверный ответ бота имеет последствия.

SaaS-платформа (3 000–100 000+ ₽/месяц):
Используйте, если главным образом нужно FAQ-отклонение и маршрутизация обращений, каталог продуктов стабилен и прост, есть команда поддержки, которая хочет единый inbox, и вы хотите запуститься за несколько дней. Aimylogic и BotHelp достаточно хороши для своего предназначения. Российские платформы решают вопрос 152-ФЗ лучше западных аналогов.

Open-source-фреймворк (Rasa/Botpress, $0 ПО + инфра + программисты):
Rasa даёт полный контроль с локальным NLU и управлением диалогом. Требует Python-инженера и реальных обучающих данных. Корпоративное лицензирование начинается от $35 000/год. Подходит для ML-тяжёлых сценариев, где нужен полный контроль. Требует постоянной поддержки, которую SaaS берёт на себя.

Кастомный гибрид (инвестиции в код + ~5 000 ₽/месяц API):
Используйте, если нужны управляемые многошаговые квалификационные потоки, данные о продуктах синхронизированы с существующей системой, есть требования к локализации данных или соответствию 152-ФЗ, нестандартная интеграция с каналами или предсказуемость затрат на долгий срок. Не проект выходного дня, но при масштабировании экономика очевидна. По данным рынка, полная разработка «под ключ» в России стоит 70 000–1 000 000 ₽ единоразово (медиана 227 000 ₽ по исследованию Aimylogic).