Скажите, а слабыми с точки зрения отсутствия кода, или с точки зрения тем? Или с точки зрения подачи? Может быть что-то еще? Не могли бы вы прокомментировать, пожалуйста, чтобы сделать работу над ошибками. Спасибо.
Спасибо большое за обзор, Дарья. Очень рад что мой доклад Вас понравился и попал, что называется, «в точку». Надеюсь таковых было достаточно для того, чтобы начать что-то менять в нашем подходе :)
Спасибо за комментарий. Да, хоть и еще один на ту же тему что и 25 предыдущих, но все равно спасибо. Значит тема заинтересовала раз потратили время.
Очень жаль что Вы рассматриваете эту концепцию в свете «лгать, и выдумывать оправдания, если ложь не сработала». Это достаточно недальновидно. Если Вы не видите применение техники, это не значит что она не работает. Вы же уже являетесь пользователем этой техники на Facebook, и/или Twitter, и/или еще многих сервисах. То что Вы не знаете о том что являетесь пользователем этой техники не замечая ее говорит только о том, что Вас все устраивает :)
А теперь по существу – если ответ на лайк идет 10 секунда Вы НЕ ИСПОЛЬЗУЕТЕ оптимистичный интерфейс прежде всего. Если задержка связана с временными проблемами, то это частный случай. Если с сервером «временные» проблемы слишком часто, то надо что-то менять и на это время, возможно отключить оптимистичные операции. Не можете отключить временно? Надо что-то менять. На дата-центр упал метеорит? Не поверите, но это случается не так часто и называется «форс-мажор». Он случается еще реже чем ошибки сервера. Если на дата-центр упал метеорит, вся ваша база пошла кувырком! Вы, скорее всего, даже не сможете отобразить вот это вот «Извините…» :) Но если до этого дойдет, с удовольствием подискутирую с Вами на тему «негативного опыта, который запоминается сильнее». Заметьте я не оспариваю это утверждение (потому что так оно и есть), а просто хочу упомянуть что негативный опыт может быть в любом интерфейсе и в любом контексте.
Но по секрету я вам скажу большую тайну, которая многим не столь очевидна – пользовательский интерфейс не предназначен для закрытия дыр в вашей архитектуре. По крайней мере не в широком смысле этого понятия.
Я сам не сторонник ускорения всего что возможно, а только того что необходимо ускорить. Но когда люди на «молоток» говорят «утюг» только потому что не знакомы с молотком и не понимают как его применять – это может вызывать только улыбку :)
Согласен. если такая проблема для ваших пользователей существует, то просто не используйте оптимистичные взаимодействия на критичных элементах. Все просто.
Теоретически такая возможность существует. Но тут мы говорим даже не про 1-3%, а скорее про 0.01-0.03% если не меньше. Для того что бы забить все каналы на один хост в браузере так чтобы на еще один запрос «не хватило места» нужно постараться.
Например – загрузить что-то, что нагружет все доступные каналы (минимум 6) и пока эти запросы «держат» сервер, активировать оптимистичный элемент (или отправить запрос каким-то другим способом) и закрыть вкладку до того как освободится хоть один канал (если не успеть, то наш запрос от оптимистичного элемента займет его место). Так что по сути Вы правы – такая возможность существует. Но если мы не рассматриваем момент загрузки страницы и не говорим про проекты написанные ногой, то это маловероятно.
Плюс есть еще одно «но». Все это уже смахивает на преднамеренное желание поломать интерфейс. А это уже совсем не имеет отношения к оптимистичным запросам.
На самом деле, все зависит от того где и как реализуется оптимистичный интерфейс. По своей сути, сам по себе он не сильно влияет на стоимость. Но вот грамотная обработка ошибок может повлиять как в большую, так и в меньшую сторону.
НО, грамотная обработка ошибок нужна вне зависимости от того какие идеи вкладываются в интерфейс изначально. Поэтому по сути, на стоимости грамотно построенного проекта оптимистический интерфейс скорее всего не отразится. Тут нужно еще учитывать что оптимистичный интерфейс может быть интегрирован как к одному единственному элементу на сайте, так и ко всем видам взаимодействий – тут только голову включать и работать.
Спасибо за ссылку. В прошлом году я тоже писал похожее в контексте «Tolerance Management» – Show Me Your Progress если интересно посмотреть откуда вообще идет идея индикаторов прогресса и психологическое обоснование разных типов
Вот это интересное замечание. Спасибо. Это действительно возможный сценарий. Но, есть два момента:
1. Количество соединений к одному домену в контексте современного веба выглядит гораздо оптимистичнее – http://www.browserscope.org/?category=network&v=top
2. Если во время работы страницы (не загрузки страницы, когда подгружаются ассеты, а именно уже в процессе) Вам недостаточно 6 одновременных соединений к одному и тому же домену, то проблема кроется не в оптимистическом интерфейсе, а в архитектуре проекта.
Боле того, когда Вы внедряете интерфейс и проводите тестирование, Вы должны проводить его в тех же условиях что и пользователь. В таком случае Вы «отловите» ситуацию с исчерпанием лимита по соединениям на достаточно раннем этапе. Но, я вполне уверен что такая ситуация не случится в проектах написанных не «на коленке».
К счастью, этот случай не имеет ничего общего с оптимистичными интерфейсами :) То что кто-то не разработал адекватного механизма обработки ошибок это плохо. Но не имеет отношения к какой-либо технике разработки интерфейсов.
Хочу уточнить – не «несколько секунд», а МАКСИМУМ 2 (две). Если Ваша форма заказа на сервере обрабатывается в течение более долгого времени, то смотрите соответствующий пункт в Практических правилах (в конце статьи). Более того, если Вы не обрабатываете потенциальные ошибки на клиенте до отправки формы на сервер, то опять таки, оптимистический интерфейс внедрять пока рано. Обо всем этом есть в тексте статьи :)
Спасибо за комментарий. Совершенно верно – внедрение оптимистичных интерфейсов, в отличие от многих доступных на данный момент техник, требует подключения логики и адекватных размышлений. Это не та техника, которую можно «размазать» по сайту и все улучшится.
По поводу форм заказа, прочтите, пожалуйста, мой последний комментарий к оригинальной статье и все встанет на свои места, я надеюсь. Если нет, то просто-напросто это значит что техника Вам не подходит. И это абсолютно нормально. Вы пишите что это случай из реальной практики, а потом переходите в гипотетическое рассуждение, как мне показалось, но в любом случае, неправильное применение техники и ее контроля еще не означает что техника не работает. Просто она вам не подходит.
Что-то мне подсказывает что эта «традиция» далеко не добрая, поэтому такие традиции надо искоренять, на мой взгляд.
Для кого-то это элементарные техники, а для кого-то это что-то да значит. Для кого-то то, что написано в интервью имеет непосредственное отношение к оптимизации, а для кого-то это просто набор букв в котором он не найдет ничего интересного потому что *ему лично* неинтересно. Это нормально – каждый человек имеет свое мнение и свой круг интересов. И это прекрасно! Иначе мы бы жили в очень скучном мире.
Но по поводу Вашего комментария, Владимир, я могу сказать немного. Умный человек, глядя на то что он уже знает или на то что его в жизни не особо интересует, не задерживается, а идет дальше – у него еще целый мир впереди для изучения, открытия и постижения. Есть и другой тип людей, которые всегда найдут как проявить свое невежество по отношению к другим, как показать свое мнимое значение путем оскорбления или унижения других людей, чтобы самоутвердиться за их счет. Обычно такие люди – подростки пубертатного периода, либо программисты в годах, живущие одни или продолжающие жить с мамами, пописывая код в семейках ночи напролет.
Уверен, Владимир, несмотря на Ваш комментарий, Вы не относитесь ко второму, деструктивному, типу людей. Более того я уверен что Вы и сами понимаете всю абсурдность и нелепость Вашего комментария и написали его только лишь в порыве плохого настроения. Будем считать это досадным недоразумением и, уверен, если Вы побываете на одном из моих докладов, мы с Вами вместе посмеемся над этим случаем за бокалом пива.
Понятно. Наверное, можно прикрутить и настроить grunt-wpt, хотя я пробовал и меня не сильно устроило. Более того, вопрос с раскадровкой, как Вы хотите, этот плагин, конечно же, не решает.
Кстати, развернуть код webpagetest для доступа без ограничений можно абсолютно легально через приватные инстансы, но, опять-таки, раскадровка не получится. На вашем месте, если нет желание платить speedcurve, работайте надо оптимизацией самой нагруженной страницы, оптимизируйте ее, проверяйте через Webpagetest и переносите наработки на остальные страницы. НО, добиться улучшений даже на нескольких страницах – это уже лучше, чем работать без улучшений вообще, на мой взгляд.
Нет, webpack не пробовал. Спасибо за совет – обязательно попробую. Но тут дело в другом – использовать новый инструмент для нового продукта – замечательно. Перелопачивать огромный проект для внедрения нового инструмента когда старый (require.js в моем случае) полностью выполняет свои задачи – это непреиемлемая роскошь для меня, к сожалению. Но посмотрю все равно – если действительно стоящий инструмент с ясным и понятным путем миграции, то почему бы и нет? :)
Начнем с того что время начала отрисовки это всегда основополагающий фактор *для меня*. Не факт что для Вас это подходит, НО, для меня странно звучит что после отрисовки первого экрана происходило торможение. Практически гарантировано – это означает, что какой-то блокирующий скрипт или CSS присутствовал напрямую в HTML. Я бы попробовал вернуть вариант с быстрой отрисовкой первого экрана и убедиться в том что нету блокирующих скриптов дальше на странице. Посмотрите рекомендации по поводу включения и асинхронной подгрузки скриптов/CSS в этом интервью, или других источниках в интернете.
По поводу speedcurve. Если нужна визуализация отрисовки как в Вашем примере, то достаточно использовать бесплатный сервис http://www.webpagetest.org/. Например – http://www.webpagetest.org/video/compare.php?tests=160503_S7_HFP-r:1-c:0
Благодарю за оперативность.
Очень жаль что Вы рассматриваете эту концепцию в свете «лгать, и выдумывать оправдания, если ложь не сработала». Это достаточно недальновидно. Если Вы не видите применение техники, это не значит что она не работает. Вы же уже являетесь пользователем этой техники на Facebook, и/или Twitter, и/или еще многих сервисах. То что Вы не знаете о том что являетесь пользователем этой техники не замечая ее говорит только о том, что Вас все устраивает :)
А теперь по существу – если ответ на лайк идет 10 секунда Вы НЕ ИСПОЛЬЗУЕТЕ оптимистичный интерфейс прежде всего. Если задержка связана с временными проблемами, то это частный случай. Если с сервером «временные» проблемы слишком часто, то надо что-то менять и на это время, возможно отключить оптимистичные операции. Не можете отключить временно? Надо что-то менять. На дата-центр упал метеорит? Не поверите, но это случается не так часто и называется «форс-мажор». Он случается еще реже чем ошибки сервера. Если на дата-центр упал метеорит, вся ваша база пошла кувырком! Вы, скорее всего, даже не сможете отобразить вот это вот «Извините…» :) Но если до этого дойдет, с удовольствием подискутирую с Вами на тему «негативного опыта, который запоминается сильнее». Заметьте я не оспариваю это утверждение (потому что так оно и есть), а просто хочу упомянуть что негативный опыт может быть в любом интерфейсе и в любом контексте.
Но по секрету я вам скажу большую тайну, которая многим не столь очевидна – пользовательский интерфейс не предназначен для закрытия дыр в вашей архитектуре. По крайней мере не в широком смысле этого понятия.
Я сам не сторонник ускорения всего что возможно, а только того что необходимо ускорить. Но когда люди на «молоток» говорят «утюг» только потому что не знакомы с молотком и не понимают как его применять – это может вызывать только улыбку :)
Хорошего всем дня и настроения! :)
Например – загрузить что-то, что нагружет все доступные каналы (минимум 6) и пока эти запросы «держат» сервер, активировать оптимистичный элемент (или отправить запрос каким-то другим способом) и закрыть вкладку до того как освободится хоть один канал (если не успеть, то наш запрос от оптимистичного элемента займет его место). Так что по сути Вы правы – такая возможность существует. Но если мы не рассматриваем момент загрузки страницы и не говорим про проекты написанные ногой, то это маловероятно.
Плюс есть еще одно «но». Все это уже смахивает на преднамеренное желание поломать интерфейс. А это уже совсем не имеет отношения к оптимистичным запросам.
На самом деле, все зависит от того где и как реализуется оптимистичный интерфейс. По своей сути, сам по себе он не сильно влияет на стоимость. Но вот грамотная обработка ошибок может повлиять как в большую, так и в меньшую сторону.
НО, грамотная обработка ошибок нужна вне зависимости от того какие идеи вкладываются в интерфейс изначально. Поэтому по сути, на стоимости грамотно построенного проекта оптимистический интерфейс скорее всего не отразится. Тут нужно еще учитывать что оптимистичный интерфейс может быть интегрирован как к одному единственному элементу на сайте, так и ко всем видам взаимодействий – тут только голову включать и работать.
1. Количество соединений к одному домену в контексте современного веба выглядит гораздо оптимистичнее – http://www.browserscope.org/?category=network&v=top
2. Если во время работы страницы (не загрузки страницы, когда подгружаются ассеты, а именно уже в процессе) Вам недостаточно 6 одновременных соединений к одному и тому же домену, то проблема кроется не в оптимистическом интерфейсе, а в архитектуре проекта.
Боле того, когда Вы внедряете интерфейс и проводите тестирование, Вы должны проводить его в тех же условиях что и пользователь. В таком случае Вы «отловите» ситуацию с исчерпанием лимита по соединениям на достаточно раннем этапе. Но, я вполне уверен что такая ситуация не случится в проектах написанных не «на коленке».
По поводу форм заказа, прочтите, пожалуйста, мой последний комментарий к оригинальной статье и все встанет на свои места, я надеюсь. Если нет, то просто-напросто это значит что техника Вам не подходит. И это абсолютно нормально. Вы пишите что это случай из реальной практики, а потом переходите в гипотетическое рассуждение, как мне показалось, но в любом случае, неправильное применение техники и ее контроля еще не означает что техника не работает. Просто она вам не подходит.
Хорошего дня.
Для кого-то это элементарные техники, а для кого-то это что-то да значит. Для кого-то то, что написано в интервью имеет непосредственное отношение к оптимизации, а для кого-то это просто набор букв в котором он не найдет ничего интересного потому что *ему лично* неинтересно. Это нормально – каждый человек имеет свое мнение и свой круг интересов. И это прекрасно! Иначе мы бы жили в очень скучном мире.
Но по поводу Вашего комментария, Владимир, я могу сказать немного. Умный человек, глядя на то что он уже знает или на то что его в жизни не особо интересует, не задерживается, а идет дальше – у него еще целый мир впереди для изучения, открытия и постижения. Есть и другой тип людей, которые всегда найдут как проявить свое невежество по отношению к другим, как показать свое мнимое значение путем оскорбления или унижения других людей, чтобы самоутвердиться за их счет. Обычно такие люди – подростки пубертатного периода, либо программисты в годах, живущие одни или продолжающие жить с мамами, пописывая код в семейках ночи напролет.
Уверен, Владимир, несмотря на Ваш комментарий, Вы не относитесь ко второму, деструктивному, типу людей. Более того я уверен что Вы и сами понимаете всю абсурдность и нелепость Вашего комментария и написали его только лишь в порыве плохого настроения. Будем считать это досадным недоразумением и, уверен, если Вы побываете на одном из моих докладов, мы с Вами вместе посмеемся над этим случаем за бокалом пива.
Хорошего дня, Владимир.
Кстати, развернуть код webpagetest для доступа без ограничений можно абсолютно легально через приватные инстансы, но, опять-таки, раскадровка не получится. На вашем месте, если нет желание платить speedcurve, работайте надо оптимизацией самой нагруженной страницы, оптимизируйте ее, проверяйте через Webpagetest и переносите наработки на остальные страницы. НО, добиться улучшений даже на нескольких страницах – это уже лучше, чем работать без улучшений вообще, на мой взгляд.
Удачи.
По поводу speedcurve. Если нужна визуализация отрисовки как в Вашем примере, то достаточно использовать бесплатный сервис http://www.webpagetest.org/. Например – http://www.webpagetest.org/video/compare.php?tests=160503_S7_HFP-r:1-c:0