Мнение: JavaScript сломал интернет
Джоно Алдерсон – специалист по SEO-оптимизации. Его работа заключается в том, чтобы привлечь на ваш сайт как можно больше новых пользователей. И, по его мнению, с каждым годом делать это становится всё сложнее и сложнее. Но не потому, что поисковые алгоритмы постоянно меняются, и не потому, что заинтересовать пользователей уже не так просто, а потому, что современные сайты перегружены и максимально недружелюбны к тем, кто слабо представляет себе их устройство.
JavaScript сломал интернет, но почему-то это сочли прогрессом
Большинство сайтов ужасны.
Они не просто медленные, они до жути медленные: тяжёлые, лагучие, неоптимизированные и с тоннами скрытого мусорного кода. И почти весь мусорный код – это JavaScript. Из-за него и тормозят все ваши сайты. Из-за него ваши мобильники не вывозят даже браузер. Из-за него поисковая выдача превратилась в таргетированную кашу. Этот код бесполезен. Его невозможно нормально поддерживать. Но несмотря на весь этот кошмар мы всё ещё считаем, что интернет развивается. Если он и прогрессирует, то только в обратную сторону!
Всё настолько плохо, что мы тупо перестали обращать на это хоть какое-то внимание. Когда-то у нас был стабильный, быстрый и устойчивый интернет. И где он теперь? Вместо него мы получили неадекватный культ JavaScript. Сколько программистов нужно, чтобы изменить заголовок? Чем больше, тем лучше!
Это не эволюция, это усложнение ради усложнений. И это именно мы сделали это нормой: мы радовались каждой новой фишке, и в итоге сайты из сервисов, ориентированных на пользователей, мы превратили в витрину передовых, но не особо нужных обывателям технологий.
Как мы тут оказались?
Всё началось в 2010-м. Всё изменил iPhone. Нативные приложения были оптимизированными, быстрыми и плавными. И пользователям это нравилось. И тогда маркетологи вдруг задумались: «А можем ли мы превратить сайт в подобие приложений?».
Разработчики, вооружившись передовыми технологиями и ответили: «Почему бы и нет?». Чисто в теории JavaScript мог дать интерфейсам столь желанную плавность. Это и стало нашей целью на ближайшие годы. Но пора признать, что у нас вообще ничего не получилось.
Спойлер: в полноценные приложения сайты так и не превратились, пользовательский опыт ничуть не улучшился, а сайты становились всё тяжелее и тяжелее. Загрузка отдельных разделов и фейковая прогрузка макетов не помогают.
Параллельно с этим JavaScript перестал быть передовым языком. Его места занял Node.js, а классическому JS пришлось отойти в сторону. Со временем к разработкой сайтов стали заниматься те же люди, которые когда-то отвечали за приложения. Вот только они слабо представляли, как работают сайты, и всюду пытались пропихнуть знакомую только им структуру и логику. Как итог мы получили сложные перегруженные страницы, которые прогружаются даже тогда, когда пользователю это абсолютно не нужно. И именно из-за этого они работают так медленно.
Итак, мы зачем-то переписали уже существующие правила веб-разработки и адаптировали их под потребности нового мобильного мира. Нам было плевать на содержание, плевать на скорость и плевать на совместимость. Нам было важно, чтобы код сайта напоминал код приложений. Унификация ради унификации.
Чем дольше мы занимались этой ерундой, тем дальше мы уходили от оригинальных идей старого интернета. Классический HTML? А оно вам надо? Рендеринг на стороне сервера? Перепишем заново! Совместимость и доступность? Посмотрим! Производительность? Да кому она вообще нужна?! Если твой ПК или мобильник не вывозит даже работу с сайтом, купи новый. Это не наша проблема!
Постепенно интернет стал местом, в котором вам нужно выдохнуть и слегка подождать прежде, чем сайт прогрузится и позволит вам поделиться своими мыслями по этому поводу. И это не потому, что пользователи хотели перенести опыт мобильных приложений в браузер, а потому, что так хотели разработчики. Им нравилось чувствовать себя новаторами и визионерами.
И расплачиваться за эти решения нам приходится до сих пор.
Культ разрабов
Ох, уж этот DX! Собственное удобство – единственное, о чём думают современные разработчики. Ни о пользователях, ни об оптимизации, ни о производительности, ни о конечном продукте, а о том, чтобы другим разрабам было проще разобраться с чужим кодом.
Все современные фреймворки ориентированы именно на удобство разрабов. Элементарная документация, простое встраивание, понятная интеграция. Вы можете запустить новое приложение даже без интерфейса и почувствовать себя дико продуктивным и умным.
Но удобство разработки не гарантирует удобство использования. На самом деле в большинстве случаев всё наоборот, ведь, чем удобнее реализован процесс разработки, тем больше слоёв абстракции приходится добавлять. А любая абстракция – это неминуемая задержка между командой и её реализацией.
Сейчас у нас есть специальные библиотеки, генерирующие разметку и кнопки, тонны метаданных, спрятанных на странице, и разные стратегии загрузки изображений, похороненные в файлах конфигурации. Это оптимально для разработчиков, но враждебно ко всем остальным.
И это не случайность. Это культ! Мы создали индустрию, которая поощряет усложнения. Сложность реализации сейчас ценится куда больше, чем удобство использования и общая эффективность.
Всегда легче сослаться на проблемы в совместимости с SSR, чем объяснять, зачем нам вообще понадобился React для блога.
Мы оптимизируем сайты и приложения, но в кардинально другом смысле этого слова. Потому, что это красиво и весело. Потому, что так сайты выглядят современнее. И потому, что никто даже не пытался это остановить.
Усложнение стало стандартом
Это замкнутый цикл. Всё идёт по спирали.
Перегруженные сайты перестали нас пугать. Мы привыкли. Мы даже ждём, что сайт будет открываться медленно и со скрипом. Нам кажется, что это нормально: сайт должен сперва прогрузиться, а потом собраться, слой за слоем, фрагмент за фрагментом. Мы даже про кэш начали забывать. Зачем нам кэш, если трафик никто не ограничивает? И теперь даже базовые действия требуют выполнения кучи строк кода.
Неважно, на какой сайт вы зашли: в блог, в электронную почту или в свой банк. Вы точно знаете, что во многом они будут похожи: они тяжёлые, неповоротливые и не настолько навороченные, чтобы так тормозить.
Так почему никто не обращает на это внимания?
Ни маркетологи, ни SEO-оптимизаторы, ни даже разрабы уже не в состоянии на это повлиять. Каждая новая функция ещё больше замедляет сайт. Капля за каплей, милисекунда за милисекундой. Нельзя просто взять и сделать то, что ещё вчера было можно.
Это натуральное безумие.
Почему раньше интернет был маленьким и быстрым, а теперь стал таким тормозным и неповоротливым? Вы ж обещали, что 256кб хватит всем!
И знаете, что самое страшное? Всё это нужно лишь для того, чтобы обслуживать саму эту систему: собирать метаданные, кэшировать страницы, прогружать фейковые макеты для визуального ускорения загрузки.
Это не инновации. Мы не придумываем ничего нового, мы тупо пытаемся починить то, что сами и сломали. И мы тупо не справляемся!
Стек воспроизводится по своему образу и подобию
Но вернёмся в наши дни. Иронично, но сейчас именно JavaScript пытается вернуться к тому, что мы когда-то потеряли.
Рендеринг на стороне сервера? Почему бы и нет? Маршрутизация? Давайте заморочимся и настроем! URL, метаданные, HTML? Всё это теперь снова можно перестроить без особых затрат по времени и ресурсам.
Всё это всё больше напоминает то, с чего мы когда-то начинали: лёгкие HTML-страницы, рендеринг на сервере и кэширование поближе к пользователю. Ну разве что теперь всё это работает в разы медленнее и зависает от любого чиха.
Мы заново перестраиваем платформы вроде WordPress, но не ради удобства, а потому, что они были слишком перегруженными. Хуже уже некуда.
Каждый новый слой создаёт всё новые ошибки и новые проблемы совместимости. Но нам почему-то кажется, что, если даже сайт-визитка открываются по три часа, значит, это с сетью что-то не так. Надо тариф подороже взять, и тогда всё наладится. И, если бы мне не приходилось наблюдать это год за годом, было бы даже забавно.
Разрабы, одержимые новизной и инновациями, сами загнали себя в технологический тупик. Сайты не становятся лучше. Мы не меняем подход. Мы тупо переизобретаем то, что до нас нормально работало, и радуемся, когда оно снова шевелится.
Циклы (не)стабильности
Стек никогда не останавливается. Он будет меняться до бесконечности.
В разработке нет ничего стабильного, нет ничего завершённого и нет ничего готового к работе. Каждый квартал, каждая задача порождают новую инициативу: обновим это, изменим то, поменяем сё. Это никогда не закончится и вряд ли когда-нибудь будет полезно.
Большая часть таких инноваций вообще не решает реальных проблем обычного пользователя. Зато это благоприятно сказывается на поддержке инфраструктуры и финансировании. Мы меняем сеть не для того, чтобы она становилась лучше, а для того, чтобы мы оставались хоть кому-то нужны.
Поэтому всё и замедлилось.
Маркетинговые кампании откладываются из-за недостаточно гибких библиотек. A/B-тесты отменяются потому, что аналитический уровень несовместим с общий стратегией. Базовые настройки SEO похоронены где-то глубоко в фундаменте.
А у пользователей страница по полчаса грузится!
И это именно то, что случается, когда во главу угла ставят сложность и комплексность, а не удобство. Мы оптимизируем не реальный продукт, а свою работу над ним.
Снова и снова.
Побочный ущерб для маркетологов и пользователей
Перегруженность разочаровывает разрабов и мешает всем остальным.
Маркетологам стало сложнее экспериментировать. Они не могут запустить страницу с тестовым макетом и посмотреть, как будет выглядеть финальный результат. Каждое крупное изменение должно пройти через кодеров, а иногда и через несколько отделов. Куча шагов и куча времени, чтобы в итоге узнать, что всё это никуда не годится и нужно срочно всё переделывать.
SEO-оптимизаторы упёрлись в тщетные попытки диагностировать проблемы с рендерингом, которые они всё равно не могут контролировать. Страницы грузятся пустыми, потом появляется фейковым макет, а уже потом, если повезёт, и сама страница. Всё лагает, метаданные теряются, структурные данные объединяются в один объект и тупо исчезают.
Разметка страницы свелась к пузырям, которые мало связаны как с изначальным содержимым, так и с тем, что в итоге увидит пользователь.
Даже в базовом QA бардак! У страницы правильный заголовок? А теги правильные? А вы загляните под капот и проверьте. Может да, а может нет.
А что с пользователями? Они вынуждены залипать на полоску загрузки, дёргать курсором по экрану и кликать по не до конца прогрузившимся кнопкам. Фейковый макет страницы больше фейковый, чем макет.
И это точно не будущее интернета, это слоупочная катастрофа!
Мы придумали сайты, которые трудно запустить, трудно найти, трудно использовать и трудно поддерживать. И всё это во имя прогресса!
JavaScript – отличный инструмент (но не для всех)
Давайте проясним: JavaScript – вовсе не вселенское зло. Это отличный, функциональный инструмент. И это важная часть всего интернета. Именно благодаря JS у нас есть хоть какая-то интерактивность, динамический контент и обновления страниц в реальном времени. Именно благодаря JS мы перешли от страниц к полноценным сервисам.
В умелых руках JavaScript может многое. И если бы JS использовали только те, кто точно знает, что делает, интернет бы поднялся до таких высот, которые мы и представить не можем.
Вот только большинству сайтов этого не нужно. Им не нужно быть сложными сервисами. И пользователи никогда не ждали, что такие сайты превратятся в полноценные сервисы. Блоги должны быть блогами, каталоги должны быть каталогами. Ну так и зачем им JavaScript? Даже онлайн-магазинам не особо нужны полноценные фреймворки под капотом. Они могли бы быть минималистичными, лёгкими и быстрыми.
Несколько строк нормально написанного JS-кода (и даже jQuery) способны покрыть 95% потребностей большинства современных сайтов. Быстрее, проще, доступнее.
Да даже CSS в одиночку может выполнять почти все задачи, для которых сейчас используется JS: переключатели, модули, и даже карусели. Так зачем нам скрипты?
И да, я понимаю, что некоторым сайтам JavaScript действительно нужен. Например, чтобы в реальном времени отслеживать какие-то параметры и показатели: курс валют, региональную доступность и т.д. Но даже это могло бы работать на стороне сервера. Зачем такие сложности ради переключения между долларами и евро? Но нет, нам нужны фреймворки. Мы дошли до того, что даже странице с контактами нужен React.
Это уже не просто расточительство ресурсов, это натуральное вредительство. Мы впустую теряем внимание пользователей, время разрабов и ресурсы бизнеса ради интерактивности, о которой никто не просил.
Парадокс мощности
Чем сложнее и комплекснее стек, тем больше мощности ему нужно.
Маркетологи, копирайтеры, редакторы, сеошники, дизайнеры – всех их тупо отстранили от творческого процесса. Даже элементарные задачи требуют недюжих технических знаний. Хотите поменять заголовок? Идите к технарям!
Абсолютно любое действие требует координации с командой кодеров. А это в свою очередь означает, что теперь именно кодеры решают, какие изменения важны для сайта, а на какие можно забить. И чем больше они усложняют сайты, тем важнее они себя чувствуют.
Они редко это осознают и редко делают из злого умысла. Стек создан разрабами для разрабов. Если что-то ломается, чинить это должны именно те, для кого это всё и создавалось. Но в итоге технари получили слишком много контроля, хотя на самом деле он им не особо нужен.
И это не техническая проблема, а организационная. Мы отдали интернет в руки тем, кто разбирается в его механизмах. А теперь они слишком заняты его починкой и у них тупо нет времени на решение повседневных проблем.
Сайты, которые работают
Есть ли способ всё это исправить? Есть. Причём нам даже не придётся снова переписывать интернет или возвращаться в 2005-й.
Не нужно отказываться от CMS. Не нужно запрещать JavaScript. Нам просто нужно перестать относиться к сайтам как к приложениям. Это страница, а не софт.
Большинству сайтов важна скорость и простота навигации. От них требуются максимально простые вещи: чтение, прокрутка, покупка. Всё. И у нас уже есть инструменты для реализации этих элементарных функций: рендеринг на стороне сервера, семантическая разметка, чистые URL-адреса, лёгкие шаблоны, кэширование и разумное использование JavaScript там, где он действительно нужен.
Отталкивайтесь от потребностей пользователей, производительности и удобства последующего обслуживания. Не умничайте и идите простым путём. Не забывайте, что вы работаете с сетью, а не с приложением и его оболочкой.
И дело тут не в том, чтобы вернуться назад, а в том, чтобы тупо перестать закапывать себя ещё сильнее. Интернет может работать как раньше. Просто не мешайте ему.
Восстановление интернета
Если вы хотя бы раз чувствовали, что управлять вашим сайтом становится всё сложнее и сложнее, вам даже объяснять ничего не нужно. Вы и так в курсе.
Если на то, чтобы тупо обновить теги или заголовки, временами уходят целые дни, если всё работает явно не так, как должно, если ваш блог не грузится с заблокированными на уровне браузера скриптами, это вообще не то, как должен работать интернет. Это выбор, который мы когда-то сделали. Вас там, возможно, даже не было, но разгребать это придётся в том числе и вам.
Спросите себя:
- Зачем мы засунули JavaScript в статичные сайты?
- Почему я не могут отредактировать собственный сайт без помощи технарей?
- Куда делся банальный HTML?
И вам не нужно заново изобретать велосипед. Просто в следующий раз сделайте вид, что вам действительно важны быстродействие и оптимизация.
И помните: комплексность и сложность – это не только технические заморочки, но и лишние финансовые траты. Вам нужно больше кодеров, больше инженеров. И как бы усердно они ни работали, работать ваш сайт будет всё медленнее и медленнее, а затраты на его обслуживание будут всё выше и выше. Так зачем вы платите за то, чтобы потом страдать и платить ещё больше?
Быстрые сайты проще обслуживать. И быстрые сайты явно больше понравятся вашим пользователям. И вы можете потребовать этого прямо сейчас!
Перегруженные сайты впустую сжирают наши ресурсы, ресурсы, которые мы могли бы пустить на что-то действительно полезное. Вы в праве требовать. Это ваш сайт, а не того парня, который писал для вас код. Объясните свою позицию и не соглашайтесь на меньшее.
Интернет сломался не сам по себе и не просто так. Это мы его сломали, причём сломали намерено. Разумеется, никто не думал, что спустя десять лет мы окажемся там, где оказались. Но это факт.
И это вовсе не означает, что нам не нужны фреймворки и полноценные веб-приложения. Нужны, но далеко не всем и далеко не везде. Таким сайтам нужны большие команды и чёткое видение. Но чаще всего именно «большие» сайты и грешат излишней перегруженностью. Неужели этого нельзя избежать?
И да, фреймворки могут быть быстрыми и удобными для SEO. Но давайте честно: вы хоть раз с таким сталкивались? Я вот что-то не припомню. Большинство разрабов забили на оптимизацию. Они даже с настройками не заморачиваются: взяли дефолтные, и понеслась!
Что в итоге? Сломанные кнопки, растянутые изображения, глючная разметка, URL-адреса, которые больше напоминают зашифрованные послания инопланетных цивилизаций, метаданные, которые исчезают сами по себе, контент, который даже скопировать не получается, дёрганный скроллинг, поехавшие вбок заголовки, лживая аналитика и непрогружающиеся страницы.
Но всё это ещё можно исправит. Всё это вызвано неправильным выбором инструментов, которые тупо не подходят для задач, в которых их используют. И речь тут даже не о возвращении к допотопным макетам и не об отказе от JavaScript. Речь о том, чтобы хотя бы не раздувать этот пузырь ещё сильнее.
И речь не чистоте кода. Речь о его работоспособности. Пользуйтесь тем, что работает. Кто-то возможно возразит: но сайты ж и так работают. Это у вас. А у пользователей?
Комментарии
Отправить комментарий