Однажды я задумался: если современный смартфон среднего сегмента в тысячи раз мощнее первого Pentium, а в кармане у нас лежит устройство, способное выполнять сотни миллиардов операций в секунду, то почему простое листание веб-страницы с текстом и картинками иногда вызывает микрозадержки и рывки? Pentium 60 МГц с 32 мегабайтами памяти в 1995 году открывал Word и таблицы без малейшего намека на задумчивость. А сейчас восемь гигабайт оперативки и восьмиядерный чип с тактовой частотой под три гигагерца просят аппаратного ускорения, чтобы плавно проскроллить ленту новостей. Давайте разберемся, как так вышло и куда катится мир технологий.
В начале девяностых программы писали с оглядкой на каждый байт. Оперативной памяти было мало, жесткие диски размером с две дискеты, а процессоры работали на частотах, которые сегодня вызывают улыбку. Однако простые действия выполнялись моментально: нажал на иконку — окно открылось, нажал кнопку «Пуск» — меню вылетело без задержек. Сегодня же кнопка «Пуск» может плавать по экрану, а анимация её появления требует расчета теней, прозрачности и физики движения, будто это не меню, а спецэффект в блокбастере.
Возьмем обычную новостную ленту. Казалось бы, что сложного: текст, пара jpeg-картинок, фон. Но откроем мониторинг ресурсов и увидим, что браузер загружает процессор и видеокарту так, словно мы запустили не чтение статей, а шутер начала двухтысячных. Дело в том, что современная веб-страница — это уже не набор html-тегов с парой картинок. Это многослойный «слоеный пирог» из десятков скриптов, трекеров, рекламных модулей, шрифтов с серверов Google и прочего багажа. Каждый элемент анимирован, каждая тень под кнопкой просчитывается графическим процессором, каждый плавный скролл обсчитывается как 3D-сцена. В Windows 95 интерфейс использовал простой вывод графики: взяли прямоугольник из памяти, положили на экран — быстро и дешево. Сегодня каждый пиксель может иметь свой слой, свою прозрачность и свой шейдер. Чтобы буквы казались гладкими на retina-дисплеях, их рендерят как геометрические фигуры с субпиксельным сглаживанием. И все это происходит 60 раз в секунду, даже если вы просто читаете неподвижный текст.
Но самое забавное начинается, когда мы смотрим на размер программ. Канонический пример — программа «Hello World». В эпоху Turbo Pascal или C она занимала несколько килобайт и запускалась мгновенно. Сегодня, если написать то же самое на Electron или с использованием React, размер легко перевалит за сто мегабайт. Внутри лежит фактически целый браузер Chromium, Node.js, тысячи зависимостей в node_modules, о которых разработчик даже не подозревает. Это как если бы для того, чтобы зажечь спичку, вы строили бы газоперерабатывающий завод. И ведь это не утрирование: пустой проект на современном фреймворке весит сотни мегабайт еще до того, как вы написали хоть строчку полезного кода.
Почему так происходит? Тут работает сразу несколько факторов. Первый — экономика. Час работы программиста стоит дорого, а гигабайт оперативной памяти и гигабайт дискового пространства — копейки. Дешевле заставить пользователя купить устройство с запасом по ресурсам, чем платить разработчикам за оптимизацию. Второй фактор — мода и карго-культ. Многие студии и фрилансеры делают сайты-визитки из трех страниц на WordPress с плагинами и тяжелыми темами не потому, что иначе нельзя, а потому, что «так принято». Заказчик просит красивый сайт, и дизайнер выдает макет с параллакс-эффектами и анимированными элементами, которые требуют мегабайты скриптов. Сайт-визитка 1999 года весил меньше ста килобайт и открывался мгновенно, а сегодняшний аналог может весить десятки мегабайт, грузиться несколько секунд и нагружать процессор, даже когда пользователь просто смотрит в экран. И ладно бы речь шла о сложном интернет-магазине с кучей функций, но нет — это просто пара страниц с контактами и фотографиями.
Здесь напрашивается прямая аналогия с маркетинговыми мегапикселями в фототехнике. Производители смартфонов и фотоаппаратов годами впаривали покупателям число мегапикселей как главный показатель качества. В итоге на крошечную матрицу втискивали 48, 64, а то и 200 мегапикселей, забывая о размере пикселя и реальной светосиле. Профессионалы знают: важнее оптика, динамический диапазон и алгоритмы обработки, а не сухие цифры. С софтом та же история. Маркетинг продвигает «современный дизайн», «материальный интерфейс», «анимацию», а пользователь получает продукт, который по сути делает то же, что и двадцать лет назад, но потребляет ресурсов в сотни раз больше. Мы попали в ловушку, где внешний вид важнее содержания. Windows XP до сих пор многими вспоминается как эталон удобства: кнопки понятные, меню логичные, все предсказуемо. Сейчас интерфейсы меняют облик каждые пару лет не ради функциональности, а чтобы оправдать выход новой версии и зарплату дизайнеров.
Однако зреет и обратное движение. Терминал в Linux и новый Windows Terminal набирают популярность не просто так. Это своего рода бунт против украшательств. Командная строка — честный инструмент: вы даете команду, машина выполняет. Никаких анимаций наведения, никакой рекламы, никаких теней. Нажал Enter — получил результат. Профессионалы все чаще уходят в CLI, потому что он не тратит ресурсы впустую и дает полный контроль. В мире, где каждый мессенджер и почтовый клиент норовит занять побольше памяти и внимания, черное окно с мигающим курсором становится оазисом эффективности. Можно сказать, что терминал — это RAW-формат для взаимодействия с компьютером: без украшений, зато с максимальной отдачей.
То же самое начинает происходить и в веб-разработке. Появляются статические генераторы сайтов, которые берут текст и шаблон и выплевывают чистый HTML без лишнего кода. Движение за «маленький веб» (small web) пропагандирует легковесные страницы, которые быстро грузятся и не мучают процессор. Это не возврат к технологиям девяностых, а разумный баланс: использовать мощность современных устройств для сложных задач, а для чтения новостей хватает простой верстки. К сожалению, таких проектов пока меньшинство.
Показателен мысленный эксперимент с играми. Представьте, что мы решили переиздать классический Doom 1993 года. Оригинал работал на 386-м процессоре с 4 мегабайтами ОЗУ и весил чуть больше двух мегабайт, умещаясь на паре дискет. Если бы сегодня собрали команду, которая никогда не слышала про оптимизацию по Кармаку, и поручили сделать тот же самый шутер на современных движках типа Unity или Unreal Engine, размер игры легко перевалил бы за полгигабайта. Пустой проект движка сам по себе тянет на сотни мегабайт, а каждая текстура была бы сжата в несвойственный оригиналу формат, звуки обрабатывались бы продвинутым аудиодвижком, шейдеры компилировались бы на лету, вызывая микрофризы при первом выстреле. Даже на мощном «железе» такая поделка ощущалась бы менее отзывчивой, чем оригинал на древнем 486-м, потому что между мышью и игрой встала длинная цепочка абстракций.
И вот здесь мы подходим к самому важному. Прогресс железа не должен быть индульгенцией на ленивый код. Да, современные процессоры и видеокарты творят чудеса, но если их использовать в качестве костылей для плохо спроектированного софта, мы так и будем ждать по полсекунды на открытие меню и удивляться, почему батарея смартфона садится к обеду. Парадокс: чем мощнее устройства, тем менее рационально мы ими пользуемся. Когда-то давно программисты боролись за каждый байт, потому что ресурсов не хватало. Теперь ресурсов в избытке, и мы их бездумно разбазариваем, окутывая простые операции слоями абстракций ради сомнительной красоты.
К счастью, маятник способен качнуться обратно. Пользователи устают от перегруженных интерфейсов и садящихся аккумуляторов. Растет интерес к «скучному» софту, который просто работает. Если какой-нибудь разработчик прочитает эти строки и в следующий раз вместо тяжелого фреймворка выберет легковесное решение или хотя бы почистит зависимости, мир станет чуточку лучше. А мы, обыватели, сможем читать новости, не гадая, почему для показа текста нужно больше вычислений, чем для запуска космического корабля. В конце концов, компьютер — это инструмент, а не сцена для циркового представления. Давайте помнить об этом.