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

Ожидание может состоять из активной и пассивной фаз. Для того, чтобы в восприятии пользователя ожидание было менее длительным, мы обычно увеличиваем активную фазу и уменьшаем пассивную. Но что делать, когда событие вообще не содержит активную фазу, полностью являясь пассивным ожиданием?

Оглавление серии «Производительность как восприятие»:

• Производительность как восприятие: восприятие времени;
• Производительность как восприятие: управление восприятием;
• Производительность как восприятие: управление терпением. (эта статья)

Ну ладно, заголовок жёлтый, признаюсь. HolyJS 2017 Moscow отгремела уже неделю как, а я только сподобился осмыслить произошедшее. Ах да, меня зовут Женя, я работаю в Wrike, часто выступаю на фронтенд-конференциях, и, да, я — член программного комитета одной из них. С HolyJS я с первого дня, сначала как спикер, а потом как-то раз меня попросили помочь с модерацией докладов, вот оно и завертелось. Поэтому осмысление получится скорее в формате отчёта-ретроспективы, а не отзыва участника (например читайте прошлогоднюю статью Дарьи Пушкарской, рекомендую). Поэтому описывать доклады дословно не буду, лучше посмотрите видео. Но хотелось бы рассказать что происходит за кулисами большой конференции, что прошло хорошо, что можно было сделать лучше, как мы все устали заберите нас отсюда.


_{ПК в полном составе. Фотография из vk.com/holyjs}

Те из нас, кто считают себя разработчиками (в т.ч. и автор этой статьи), очень ориентированы на задачи. Нам нравится, когда нас ведут к оптимальному результату, и мы ощущаем себя некомфортно, когда у нас нет понятного пути к цели. По этой причине мы любим знать, как что-то делать; нам нравятся туториалы и how-to. Однако подобные руководства основываются на некоторых теориях, глубоком знании и опыте.

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

• Почему важны время и производительность?
• Почему мы не любим ждать?
• Почему «быстрее» не всегда означает «лучше» в онлайн-мире?

Алиса: А сколько это — «вечность»?
Белый Кролик: Иногда, лишь одна секунда.

Льюис Кэрролл, «Приключения Алисы в стране чудес»

JavaScript-мир развивается так бурно, что даже за полгода между петербургской и московской HolyJS многое успело произойти: например, летом о Yarn ещё никто не знал, а сейчас у него больше 20 000 звёзд на GitHub. И для самой конференции тоже многое изменилось: в июне она проходила в самый первый раз, так что тогда ещё не было фидбэка зрителей, очень помогающего при организации. Отличалась ли в таком случае московская версия, и как вообще она прошла? О некоторых докладах уже написали в блоге Mail.Ru Group, а теперь мы публикуем собственный текст о мероприятии.

В минувшее воскресенье, 11 декабря, мне представилась возможность поучаствовать в HolyJS Moscow, грандиозном мероприятии, целиком и полностью посвящённом JavaScript. Количество информации на конференции поражало воображение (не обошлось даже без упоминания других технологий, хотя это логично: в мире веб-разработки всё взаимосвязано), однако из всего массива лично мне запомнилось четыре доклада. Сразу оговорюсь: дело не в том, что другие были лучше или хуже, просто именно эти привлекли моё внимание больше остальных. И здесь я поясню подробно, почему это так.

Что происходит, если вдруг на клиенте пропадает интернет? Возможно, на долю секунды, а может быть, на более ощутимый период? Все мы как пользователи сталкиваемся с нестабильным сигналом, плавающим качеством связи. Иногда это неважно, ведь хочется посмотреть какое-то весёлое видео, иногда от этого может зависеть очень многое – представьте, что вам срочно надо купить билет на поезд или оплатить тот же самый интернет.

Те сферы, где очень важен конечный пользователь – например, СМИ, говорят, что уже 13% пользователей уходят, если ваш сайт открывается больше четырёх секунд, не разбираясь в причинах. А теперь давайте представим такого пользователя, который еще пробует отправить комментарий, и он постоянно «отваливается» из-за проблем со связью?

Процент уходов и отказов будет заведомо больше. Как этого избежать? Что можно сделать в ситуации, когда данные должны быть гарантированно отправлены как от клиента, так и со стороны сервера?

На этот и другие вопросы отвечает Андрей Ситник – автор PostCSS и Автопрефиксера, ведущий фронтендер в «Злых Марсианах».









– Почему мы вообще говорим о проблемах связи? Разве это не вопрос, исключительно связанный с физическими/сетевыми возможностями?

– OSI тут не совсем в тему. Logux заменяет REST и AJAX. То есть это чисто прикладной уровень. Logux решает следующие проблемы:

Недавно опубликованная в Smashing Magazine статья Дениса Мишунова показалась нам очень интересной: она посвящена подходу, о котором многие до сих пор не задумываются, хотя он уже окружает нас в популярнейших сервисах. С разрешения автора и первоисточника мы решили перевести этот материал для хабрасообщества.

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



Оптимистичный подход к UI не в том, чтобы смотреть на веб через розовые очки — по крайней мере, не только в этом.

Петербургская JavaScript-конференция HolyJS начиналась почти как авантюра. Затевать совершенно новую конференцию, когда время на подготовку очень ограничено — смелое решение.

Такой авантюризм хорошо соответствует духу самого JavaScript-мира, где всё происходит стремительно, а смелые решения зачастую необходимы. Но возможно ли в таком случае провести конференцию на высоком уровне, с интересными докладами и без организационных проблем? Что в итоге было на мероприятии? Под катом — рассказ о том, как оно прошло.

Большое дело начинается с малого шага. Какой-то студент из Питера смастерил веб-сайт на коленке. Никому не известный энтузиаст из Финляндии прислал анонс в тематическую эхо-конференцию по Minix. Кто может предположить, к чему это приведёт?

Спустя много лет интересно взглянуть, как начинались некоторые популярные ИТ-проекты.

Как сделать сайт, который понравится пользователю? Какой он должен быть: красивый, с удобной навигацией, с запоминающимся URL? Прежде всего, сайт не должен тормозить — у пользователя должно складываться впечатление, что всё летает. Это первично. Всё остальное решается по мере разработки. О том, как воспринимают сайт пользователи, от чего это зависит и когда производительность решает, мы поговорили с Денисом Мишуновым, frontend-разработчиком (в прошлом контрибьютор в CMS Plone в составе Plone UI Team), автором статей про производительность в Smashing Magazine и активным спикером на профессиональных конференциях (среди которых From The Front, JSConf EU, JSConf Budapest, Smashing Conference, а теперь и HolyJS)



— Расскажи о себе. Какой был путь к web-разработке, почему именно она? Чем ты сейчас занимаешься?

— До того, что сейчас называют веб-разработкой, я дошёл быстро, уверенно и предсказуемо: первый компьютер, первый, никому не нужный, сайт, осознание бренности бытия. Дальше было чтение первых страниц «Программирование на Perl» Ларри Уилла и Тома Кристиансен с депрессивным верблюдом на обложке, повторное осознание бренности бытия и, как следствие, откладывание верблюдокниги. А потом я открыл для себя «Designing with Web Standards» Джеффри Зельдмана. Потом было, конечно же, «Ководство» Лебедева и много всего остального. Но книга Зельдмана была переломной. Хотелось бы сказать что-то красивое типа: «мир веба захватил меня после прочтения», но на самом деле я просто понял, что по сравнению с «конструктор электронных аппаратов» (которых из нас тщетно пытались сделать в институте), интернет-разработчик, а именно так это называлось в начале нулевых, звучит откровенно круче.