Веб-разработка *

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

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

И тут не всегда помогает ответ «надо ещё поработать над текстами». Иногда текстов уже достаточно. Блоков тоже достаточно. Страница видна, но плохо объясняет машине, что именно она предлагает: услугу, регион, исполнителя, условия, цену, замер, гарантию, филиал.

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

С сайтом услуг это особенно заметно. Интернет-магазин размечать проще: товар, цена, наличие, доставка. У услуги всё грязнее.

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

Всем привет! Это Денис Сметнев. Я тут рассказываю про вайбкодинг, про то, как один человек теперь может заменить команду, и как узкое горлышко переместилось из разработки в сторону маркетинга. При этом я наставник у ребят, которые пилят SaaS, но не справились бы без разработчиков. Речь про Reels-Boss — сервис, который нарезает длинные видео на вирусные вертикальные куски для Shorts, Reels и TikTok. Рассказываю, как ребята втроем обслуживают 50 000 клиентов и почему вайбкодеры не справятся с таким сервисом.

Хайп-цикл фронтенда, кажется, наконец-то выдохся. Мы вышли из фазы бесконечного переизобретения колеса, где каждый месяц появлялся «убийца React», и вошли в эпоху убийцы Fable инженерной зрелости. Сегодня опытного инженера сложно впечатлить очередным фреймворком: ценность сместилась в сторону предсказуемости, скорости поставки (delivery) и снижения когнитивной нагрузки.

Привет, меня зовут Павел Востриков, и я — архитектор веб-направления в «Лаборатории Касперского». В этой статье хочу разобрать JS-экосистему как набор инженерных компромиссов.

На HolyJS Spring 2026 мы предложили 120+ инженерам оценить свой реальный стек. Получившийся радар мог быть просто списком библиотек, но в итоге вышел срезом того, как выглядит рациональный подход к коду в 2026 году. Мы видим, как разработчики массово идут в сторону предсказуемой скорости масштабирования решений и инженерной гигиены.

За 15 лет WebPKI — экосистема доверия между сайтами и пользователями — сильно выросла. Появились технологии, которые делают это доверие более прозрачным и проверяемым, изменились подходы к управлению, а многие процессы стали автоматическими: выпуск и обновление сертификатов, публичный аудит через Certificate Transparency и другие механизмы. 

И, конечно, в истории WebPKI были серьёзные инциденты безопасности, которые показали: правила доверия должны быть публичными, прозрачными и проверяемыми.

Однако один вопрос не решается автоматически: кому браузер должен доверять и на каких условиях. Каждый вендор определяет это сам. Поэтому мы открываем Yandex Browser Root Certificate Program — публичную программу добавления корневых сертификатов в хранилище Яндекс Браузера. В ней описаны требования к участникам, аудит и понятная процедура подачи заявки.

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

После сборки на Tauri голос начал трещать, автокалибровка почти минуту вмешивалась в разговор, а демонстрация экрана через минуту становилась чёрной. Разбираем запись и логи, находим усиление до ×4 без лимитера, резкие разрывы 20-мс аудиопакетов и зависший видеотрек при живом соединении LiveKit — и показываем, как исправили каждый сбой в версии 0.0.26.

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

Как и писал ранее — сайты — это моё хобби. Иногда я прибегал к помощи сторонних веб‑дизайнеров, что‑то делал сам. Такое поверхностное занятие сайтами с годами привело к тому, что сайты устарели на десятилетие в плане дизайна и UX. В этом году в бизнесе артистов для корпоративов наступило затишье и появилось много свободного времени. Было принято решение обновить сайты! И именно во время этого обновления появилась проблема, из которой в итоге вырос HeadInspect.

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

Разберём, как тестировать такие ситуации через последовательные и параллельные запросы, какие ответы считать корректными и почему одного успешного HTTP‑ответа недостаточно, чтобы подтвердить безопасность изменений.

Чтобы сказать Яндексу «страница изменилась, приди посмотреть», аккаунт в Вебмастере не нужен. Есть протокол IndexNow: вы кладёте в корень сайта файл с ключом, шлёте POST со списком адресов — и поисковик приходит за часы вместо недель. Ни регистрации, ни OAuth, ни капчи. Реализуется тридцатью строками на Node.js без единой зависимости.

Ниже — рабочий скрипт целиком, шесть кодов ответа, которые он может получить, и три грабли, на которые я наступил, пока доводил его до состояния «запустил и забыл». Одна из них интереснее прочих: fetch в Node падает с fetch failed на том же запросе, который curl отправляет с первого раза.

После экспорта из Figma иконка 24×24 может оказаться в браузере крошечной, огромной или размытой. Обычно файл при этом исправен — просто разные части цепочки смотрят на разные параметры. Разбираем систему координат, viewBox, контракты и ловушки в React.

Два месяца назад мы взялись перенести в веб мою настольную игру. «Release любой ценой» — карточная игра про хаос IT‑разработки: собираешь релиз из Backend, Frontend и Database, соперники его валят, ты отбиваешься. Про саму настолку я здесь уже писал.

Нас в проекте трое: разработчик (ditayler), я (dimbo‑design, дизайнер) и Claude Code, через которого работаем оба. Ему досталась реализация логики игры и фундамент: монорепо, сеть, движок. Мне видимая часть: интерфейс, анимации, поведение карт, UX. Прочитать код я, в общем‑то, могу, а вот понять нет: моё ревью проходит на экране, как дизайн‑ревью.

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

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

В этом есть своя прелесть и свои ограничения. С которыми я прямо столкнулся во время решения задачи.

Агент несколько раз писал «готово» или «да, теперь идеально!», но на экране оставались углы в воздухе, узкая колонка по центру и сетка вместо одной формы. По итогу у меня получился стресс-тест для моделей, с которыми они так и не справились.

Состояние во Vue обновилось, а интерфейс остался прежним — и начинается охота на watch, nextTick и принудительный ререндер. Разберём, где именно рвётся реактивная связь, почему это происходит и как находить такие проблемы до того, как вокруг них вырастут костыли.

После статьи о выборе Tauri нас спросили, сколько памяти будет занимать программа, которая живёт в трее рядом с игрой. Мы запустили старый БОЛТУН на Win32 и новый на Tauri в одинаковом пустом лобби. Получилось 2,2 МБ против 128 МБ. Разбираемся, откуда взялись девять процессов WebView2, что показал замер и почему это не стало автоматическим отказом от нового интерфейса.

Что происходит, если вместо массовой раздачи AI-инструментов сначала изучить, как на самом деле работают команды?

Рассказываю, как мы начали AI Enablement в крупной финансовой организации: оценили 13 команд, визуализировали их delivery pipelines, обучили около 800 человек и построили программу вокруг реальных ботлнеков, а не вокруг модных AI-инструментов.

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

Обычно мы не замечаем эти этапы. Они становятся заметны, когда сайт начинает тормозить. Задержка может появиться ещё до обращения к серверу — например, во время DNS-резолвинга, — или уже после получения ответа, когда браузер разбирает JavaScript и строит интерфейс.

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

Тот же Rust‑код, что рисует топологию на десктопе, собирается в wasm и рисует в <canvas> через WebGPU. Сайт при этом не знает про GPU: кликнул на нарушение в списке, камера уехала на место, маркер показал дефект. Ниже как это устроено, где «просто пересобрали» было бы враньём, и какие ловушки сидят не в Rust, а в вебе.

Задача

У нас десктопный инструмент для топологии интегральных схем, layout в формате GDSII (и OASIS). Файл описывает геометрию кристалла: иерархия ячеек, на листьях прямоугольники и полигоны по слоям (металл, поликремний, диффузия). Координаты целые, в DBU, единицах базы данных; в микрометры переводим уже при развороте сцены. Реальный проект: сотни мегабайт на диске, миллионы фигур после разворачивания иерархии.

Рядом выросла веб‑платформа с результатами анализа этих дизайнов. Захотелось показать сам layout в браузере, в том же UI: клик по нарушению в списке открывает его место на топологии. В десктопных пакетах это называют RVE, results viewing environment. Нам нужна была такая навигация без второго рендер‑движка.

Что отсекли сразу

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

Canvas2D или SVG на JS. На миллионах прямоугольников не работает. И это был бы второй движок.

Отдельный JS/TS‑парсер и рендер. Формат один, интерпретации через полгода две. Для GDS это особенно опасно: иерархия, зеркала, массивы ссылок.

Остался вариант, который мы и сделали: тот же Rust, цель wasm32-unknown-unknown, картинка в <canvas> через WebGPU.

Переписал с Perl/GTK3 на C++/GTK4 ds-measurer — утилиту для измерений поверх живого экрана, снятия скриншотов (в буфер обмена и/или на диск) и цветов в различных CSS-нотациях (в буфер обмена и/или c выводом на экран).

Есть поддержка цветовых схем с переключением по ним, направляющих с прилипанием к ним, выделение из центра и/или с фиксированным соотношением сторон, настраиваемые сетки и хоткеи.

Знакомая ситуация: продукт написан за выходные, гипотеза подтвердилась, кто‑то уже платит. Приходит дизайнер и просит файл.

Файла нет. 

Есть интерфейс, который существует только в виде кода. Кнопка там называется.btn‑primary,.btn‑add и.button‑save — три класса, одна кнопка, паддинги отличаются на пиксель. Серый цвет записан тремя способами, и один из них, судя по всему, опечатка. Отдать это дизайнеру нельзя. Нарисовать заново — значит выбросить полгода работы и начать спорить про радиусы. 

Мне стало интересно, что тут реально может AI. Не «сделай красиво», а честный замер: я собрал маленькое демо, намеренно заложил в него шестнадцать несогласованностей, записал их в отдельный файл и спрятал. Потом запустил на этом коде свежую сессию Claude Code, которая файла с ответами не видела.

В статье — что из этого вышло, с цифрами и с местами, где всё сломалось.

Скролл-фильм на лендинге — это обычно сотни WebP и десятки мегабайт. Рассказываю, как заменил секвенции кадров сырым H.264-потоком без контейнера и WebCodecs-декодером: 84 → 18 МБ на мобиле. С параметрами кодирования и тремя честными тупиками: почему HEVC оказался хуже x264, зачем шумодав не нужен и как B-кадры сломали фильм на живом iPhone так, что валидация этого не увидела.