Сбой JavaScript может быть сложной вещью для изучения. Большинство аналитических программ, на которые мы привыкли полагаться, основаны на JavaScript, поэтому, когда JavaScript дает сбой, наши аналитические пакеты не знают, что вообще что-то произошло. Мы склонны недооценивать частоту сбоев JavaScript, а также потери, которые они несут, потому что их трудно измерить — яркий пример количественной ошибки в действии.
В октябре этого года исполнится ровно 10 лет с тех пор, как Цифровая служба правительства Великобритании опубликовала исследование о том, сколько ее пользователей упускают из виду улучшения JavaScript. Исследование отличало тех, кто отключил JavaScript, от тех, у кого он был включен, но просто не загружался по той или иной причине. Существует бесконечное количество причин, по которым это может произойти, от плохих сетей до вмешательства интернет-провайдеров и плагинов и расширений браузера. GDS обнаружила, что JavaScript не работал у их пользователей в 1,1% всех посещений, но только у 0,2% их пользователей был отключен JavaScript. Большинство людей, которые не получали JavaScript, 0,9% всех посещений, были пользователями, которые не отключили JavaScript. Они просто имели несчастье столкнуться с некоторыми проблемами при загрузке.
У меня была возможность повторить этот эксперимент на других веб-сайтах, и в целом я обнаружил, что это число ближе к 3%, хотя даже меньше пользователей фактически отключили JavaScript. Это согласуется с цифрами, которые часто используются в разговорной речи в индустрии веб-разработки. Мы часто представляем эту ситуацию так:
Конечно, нам бы хотелось иметь возможность предлагать одинаковую услугу всем нашим пользователям, но в реальном мире 97% успеха — это неплохо. Многие разработчики, возможно, потеряли много выходных и долгих ночей, исправляя проблему для браузера, которым пользовалось еще меньшее число пользователей, но в конечном счете организация может обоснованно считать такое положение дел приемлемым, особенно если ее исправление было бы хлопотным делом. крупное предприятие.
Но это не точно отражает ситуацию. Речь идет не о 3% затронутых пользователей, а о 3% посещений. Помните, проблема не в том, что люди выключили JavaScript, а в том, что JavaScript не надежен. Это означает, что это затрагивает всех нас примерно в 3% случаев. Мы должны представить это примерно так: это:
Если вы когда-либо ждали загрузки страницы, а затем, наконец, сдались, нажали «X», а затем перезагрузили страницу, чтобы увидеть, как она загружается немедленно, поздравляем: вы испытали, каково это, когда JavaScript терпит неудачу. Сколько раз вы ждали загрузки страницы и просто отказывались от нее? Сколько из них могло произойти просто из-за сбоя JavaScript?
Пользователи приходят на ваш сайт с определенным «резервуаром доброжелательности», как выразился Стивен Круг. От пользователя к пользователю и даже для одного и того же пользователя в разное время суток зависит его самочувствие в этот день, ел он недавно или нет, и так далее до бесконечности. Этот резервуар может быть пополнен, когда мы помогаем им выполнить задачу или дарим им восхитительный опыт, но мы отказываемся от него каждый раз, когда делаем их опыт трудным, раздражающим или разочаровывающим — что происходит каждый раз, когда наш JavaScript не загружается. Делайте это достаточно часто (скажем, 3% времени), и они быстро перестанут быть нашими пользователями. Так что на самом деле мы должны представить это примерно так: это:
Вы не получите опрос, в котором будет сказано, что пользователи покидают ваш сайт из-за того, что у вас не работает JavaScript. Если вы проводите серьезное исследование пользователей, вы можете услышать, что они считают ваш сайт медленным, неуклюжим, «дерганым», неудобным для пользователя или просто сложным в использовании. Это не та проблема, которую пользователи умеют точно указывать и точно описывать, но только потому, что они обычно не могут описать ее вам, не означает, что они ее не замечают или что она не замечает. т влияет на их поведение.
Если вы пытаетесь сделать Figma, вы, возможно, мало что можете с этим поделать. Вы должны знать, что тег <noscript> будет отображаться только для пользователей, которые активно отключили JavaScript, поэтому он не поможет большинству людей, которым он нужен. Вместо этого вам следует подумать о том, как загружается ваша страница. Возможно, вы захотите подумать, может ли базовый HTML-код выразить ваше состояние ошибки, а затем вы можете заставить JavaScript предоставлять предполагаемый опыт, когда (и если) он загружается. Но если вы создаете сложное приложение в браузере, предоставление улучшенных сообщений об ошибках может быть единственным, что вы можете сделать.
Но большинство из нас не делают Figma. Большинство из нас до сих пор создают документы — то, для чего Интернет изначально был разработан. Имеет ли смысл статья на новостном сайте быть делом «все или ничего», которое представляет пользователям пустую страницу, если комментарии не загружаются?
Прогрессивное улучшение – это подход к созданию веб-сайтов, который всегда приносит максимально возможную пользу пользователям, даже когда что-то идет не так. Мы часто выражаем ее основную идею шуткой покойного великого Митча Хедберга: «Эскалатор никогда не сломается; она может стать только лестницей».
Основные фреймворки JavaScript на данный момент — Angular, React, Next.js и т. д. — это лифты. С ними можно создать отличные впечатления, но они могут быть довольно хрупкими, дорогими в эксплуатации, а когда они ломаются, все или ничего. Прогрессивное улучшение не требует никаких новых технологий, фреймворков или библиотек. На самом деле, возможно, лучше он работает с ванильным JavaScript, четким, семантическим HTML и красивым CSS (хотя сам я неравнодушен к Sass).
Однажды я запустил новый веб-сайт со всем JavaScript, написанным для постепенного улучшения. Как оказалось, в коде старой версии Internet Explorer, которую до сих пор используют около 6% наших пользователей, была довольно критичная ошибка. А поскольку JavaScript, как правило, работает по принципу «все или ничего», когда один сбой приводит к остановке всего JavaScript на странице, это означало, что ни один из наших скриптов вообще не работал ни в одном месте в этом браузере. И все же прошло полгода, прежде чем специалист по обеспечению качества нашел его и довел до нашего сведения. Никто из наших пользователей никогда ничего не говорил и не жаловался — потому что они так и не поняли, что что-то сломалось. Они думали, что сайт должен выглядеть именно так. Они смогли осуществить все, что хотели. Они были счастливы и довольны. А когда мы исправили ошибку, они были еще больше довольны тем, что теперь все стало выглядеть еще лучше.
Когда Apple выпустила Apple Watch, мой начальник спросил меня, что потребуется, чтобы наш веб-сайт был готов к ним. Я сказал ему, что это уже было. Он мне не поверил, поэтому я отправил ему электронное письмо со ссылкой на наш сайт, чтобы открыть на его часах, и вот оно. Как я разработал наш веб-сайт для работы на устройстве, которого в то время даже не существовало? «Потому что я могущественный колдун», — сказал я ему, но настоящим ответом было прогрессивное улучшение. Предоставляя основной опыт и рассматривая все остальное как улучшение, которое некоторые пользователи могут (или не могут) получить, вы создаете страницу, ориентированную на будущее. Он готов к любому новому устройству или технологии с момента его появления в мире.
Это примеры прогрессивного улучшения, действующего как своего рода технический кредит — противоположность (гораздо) более распространенному техническому долгу.
В конечном счете, если вы решаете, как подойти к созданию веб-сайта, любой бизнес задаст этот вопрос с точки зрения рентабельности инвестиций. То, что стало «стандартным» подходом, может в конечном итоге стоить вам всех ваших пользователей, но если этот процесс достаточно медленный, и если «стандартный» подход достаточно дешев по сравнению с созданием веб-сайта, который постепенно улучшается, он все еще имеет смысл?
Наилучшие общедоступные оценки стоимости прогрессивного улучшения по сравнению со стандартным подходом исходят от Аарона Густафсона, который подсчитал, что переделка веб-сайта с прогрессивным улучшением обычно стоит около 40% первоначального бюджета. Означает ли это, что прогрессивное улучшение стоит всего 40% от стоимости стандартной разработки? Ну, может быть, нет; в конце концов, это проекты по редизайну, поэтому первоначальный проект, вероятно, включал в себя некоторые работы, которые значительно облегчили повторную работу. То же самое можно сказать и о переделке прогрессивно улучшаемого сайта в стандартном подходе (чтобы он мог сломаться в 3% случаев, я полагаю). По оценке большинства инженеров, которые работали с обоими подходами (и я отношу себя к этой категории), создание веб-сайта с постепенным улучшением не более трудоемко, чем его создание стандартным способом. Вы должны подходить к работе по-другому — вам, возможно, придется подвергнуть сомнению некоторые предположения и попробовать новые подходы, — но это не сложнее, просто другое.
Те, кто не разрабатывал с прогрессивным улучшением, часто утверждают, что это вдвое больше усилий и, следовательно, вдвое дороже. В конце концов, вам нужно сделать целый веб-сайт, который работает без JavaScript, а затем вам придется делать это снова с JavaScript, верно? Но прогрессивное улучшение работает иначе — по крайней мере, когда оно сделано разумно. Все остальные правила хорошей разработки программного обеспечения остаются в силе, в том числе «Не повторяйтесь». Вы не должны делать что-либо дважды, но вам может понадобиться подумать о том, как вы делаете что-то и где.
Итак, если прогрессивное улучшение не требует больших затрат, оно ориентировано на будущее, дает нам технический кредит и гарантирует, что наши пользователи всегда получают наилучший возможный опыт в любых условиях, почему оно отошло на второй план?
Потому что раньше, когда вы нажимали на ссылку, браузер на мгновение становился белым.
Фреймворки JavaScript сломали браузер, чтобы избежать мгновенной потери контроля. Затем им пришлось воссоздать все, что браузер предоставил бесплатно: маршрутизацию, историю, кнопку «Назад», специальные возможности, способность поисковых систем читать страницу, и так далее до бесконечности. Нахождение решений этих проблем уже много лет является целью сообщества JavaScript, и у нас есть исправные решения для всех этих проблем, но все вместе они создают невероятно сложную экосистему современного JavaScript, в которой так много разработчиков JavaScript. оплакивать и оплакивать.
Все, чтобы не обновлять браузер на мгновение.
Дизайнер во мне, безусловно, может иметь отношение к отчаянному желанию избежать этой потери контроля, но действительно ли оно соизмеримо с тем, сколько мы потеряли, чтобы этого избежать? С точки зрения опыта, который мы предоставляем нашим пользователям, ясно, что страницы, которые зависают или просто не загружаются вообще в 3% случаев, намного хуже, чем страницы, которые обновляют окно браузера при нажатии на ссылка.
Убеждены, что прогрессивное улучшение — отличная идея, но не знаете, как это сделать, особенно с современным JavaScript? Не волнуйтесь, специально для вас я написал дополнение к этой статье: Практическое руководство по прогрессивному улучшению в 2023 году.
¹ Мне сказали, что Vue уникален в этом отношении и на самом деле очень хорошо работает с прогрессивным улучшением. Я хотел бы попробовать это для себя, но у меня действительно не было хорошего проекта, чтобы попробовать это.
Приведенные выше анимации вдохновлены теми, что использовал Стюарт Лэнгридж в своем выступлении «Я обещаю, вам не нужен весь этот JavaScript» (также ссылка выше). Если хотите, вы можете поиграть с Codepen, который я использовал для их создания.
