Русский
Русский
English
Статистика
Реклама

Сайтостроение

Поговорим об инструментах для создания клиентских веб-приложений с использованием традиционных языков программирования

25.01.2021 18:10:11 | Автор: admin

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

Вместе с тем со временем всё чаще стала возникать потребность в написании монолитных как правило, простых и непритязательных веб-приложений, не требующих для работы серверной части. Естественно, с широким распространением HTML5 подобные приложения начали обретать весьма богатый функционал, однако... Однако же не все разработчики были готовы смириться с существующим положением вещей, когда все доступные им решения, по сути, имели своим краеугольным камнем всё тот же пресловутый JavaScript.

В конце концов, многие, что называется, с младых ногтей привыкли к другому подходу к проектированию и созданию приложений широкого профиля. Это, в первую очередь, различные RAD-среды, среди которых в нашей стране наибольшей популярностью (по крайней мере, в академической среде), всегда пользовалась Delphi. Натянул пару кнопок на форму, прописал нужные обработчики событий на привычном языке Pascal красота!.. Чего ещё можно желать, в особенности если вы сосредоточены на реализации каких-то нужных вам алгоритмов, а интерфейс для вас не играет такой уж принципиальной роли?

При традиционном дизайне и проектировании веб-приложений всё совсем не так. Тут тебе бы неплохо помнить и все основные детали описаний различных тэгов HTML-разметки и атрибутов CSS-стили, и уметь сверстать всё это дело воедино, да ещё и оживить интерактивными сценариями, реализованными на JavaScript. Очевидно, что такой подход, ориентированный в первую очередь на дизайн, а не на саму разработку как таковую, вряд ли устроит нашего традиционного разработчика, воспитанного на классических алгоритмах и структурах данных, с возможным вкраплением зачатков объектно-ориентированного подхода. (Напоминаем, что речь идёт в первую очередь о разработчиках небольших приложений, где теоретически мог бы управиться и один человек.)

Выход из подобной ситуации пытаются найти уже довольно длительное время. Когда-то возможным решением проблемы считались расширения для популярных браузеров, позволяющие создавать в них виртуальное окружение для создания приложений с функционалом, основанным на более привычных языках программирования. В разное время ряд компаний предлагали свои собственные разработки, базирующиеся на продвигаемых ими языках: Sun со своей Java (на нём были основаны приложения специального вида, предназначенные для запуска в браузере, сервлеты), Adobe c языком ActionScript (в составе технологии, известной всем как Adobe Flash, а ранее Macromedia Flash), Microsoft со своей реализацией .NET Framework для веба (Silverlight). Все они к настоящему моменту благополучно канули в Лету. Формально дольше всех продержался AdobeFlash, окончательно похороненный лишь в январе 2021 г. При этом, что характерно, про Silverlight или другие подобные разработки многие из нынешнего поколения айтишников уже и вообще редко когда слышали.

Так что и мы не будем подробнее их затрагивать. Каждой технологии своё время, что называется. Сейчас нас интересуют не столько окончательно отжившие своё разработки, сколько те более современные инструменты, которые пришли им на смену.

Надо сказать, что тенденции придать веб-разработке некоторые черты RAD-технологии (Rapidapplicationdevelopment, т.е. дословно быстрой разработки приложений именно так принято именовать подход к разработке приложений, реализованный, в частности, в BorlandDelphi) существуют уже достаточно давно. Здесь нельзя не упомянуть хотя бы о DHTML (или Dynamic HTML) подходе, так же позволяющем придавать некоторую интерактивность самим приложениям и, в частности, используемым в них элементам пользовательских веб-форм, интерактивность, похожую на то, что мы можем видеть в Delphi, VisualBasic и прочих RAD-средах проектирования традиционных приложений.

DHTML-приложения подразумевали полноценную автономную браузерную реализацию, без какой-либо поддержки со стороны сервера именно то, что сейчас известно как Richwebapplication (ранее RichInternetapplications, RIA) и тесно соприкасающиеся с ними SPA (Single-page applications одностраничные веб-приложения). Однако сама по себе технология DHTML так и не оправдала возложенных на неё надежд, и была вытеснена всё теми же альтернативными подходами, требующими установки автономных плагинов, такими, как AdobeFlash или JavaServlet (позднее JavaFX). В то же время она в числе прочих компонентов составила прочную основу, на которой базируется такой широко известный в веб-разработке подход, как AJAX (где уже широко задействуется и серверная часть).

Какие-то весточки вновь намечающихся позитивных сдвигов в отношении упрощения создания RIA- и SPA-приложений начали проявляться только где-то с принятием WebAssembly (или просто WASM) в качестве нового промышленного стандарта для веба. Именно с подходом, заложенным в самой основе WASM, связана поддержка расширений, позволяющих отныне использовать для написания кода, выполняемого в браузере, более привычный для программистов старой закваски бинарный формат -- именно в него в свою очередь могли транслироваться программы, написанные на самых разных языках, в том числе и тех, с которыми они уже имели дело раньше (например, даже C++, если использовать такой инструмент, как Emscripten). Но, что самое характерное, теперь всё это богатство стало разом доступно во всех браузерах (включая и мобильные), и больше не требовало, как раньше, установки каких-либо дополнительных сторонних расширений!

Разумеется, многие уже наслышаны и о Blazor проекте, который Microsoft довольно быстро подмяли под себя, выдвинув его в качестве своеобразного аналога для их же собственного, ныне почившего проекта Silverlight. Ура, отныне все желающие снова могут разрабатывать свои веб-решения, пользуясь лишь традиционными средствами, основанными на использовании VisualStudio и языков .NET-семейства (в первую очередь C# и VB.NET)! И никакого вам больше Джаваскрипта... Нет, на самом-то деле при желании JavaScript тоже вполне можно интегрировать с этими решениями, как и все порождённые им фреймворки. Более того, при отсутствии поддержки WASM со стороны используемого вами браузера первые же версии Blazor умели налету конвертировать код в JavaScript (используя для этого более раннюю технологию под названием asm.js). В настоящий момент Blazor активно развивается. Если его предшественник технология MicrosoftSilverlight пребывает в стагнации уже как минимум с 4-й версии (первоначально выпущенной аж в 2010 г.), то сам Blazor всего за два года активного применения дорос уже до 5-й версии. Всё это, бесспорно, не может не радовать. Но мы сейчас хотели поговорить и о менее распространённых альтернативах последних из названных нами технологий для реализации подходов к созданию RIA- и SPA-приложений, заставляющих вспомнить привычный для кого-то RAD-подход.

Мы отнюдь не случайно уже упомянули здесь Delphi. И пусть сама эта среда (а в случае с Delphi можно говорить и о среде, и о положенном в её основу языке как о едином целом) и не обеспечила нас широко доступными средствами для создания подобных веб-приложений. В конце концов, нашлись другие разработчики, которые это сделали! В первую очередь на память здесь приходят создатели SmartMobileStudio это такая альтернативная инструментальная среда программирования на Delphi, позволяющая реализовывать различные кросс-платформенные проекты (о современном уровне развития инструментов разработки кросс-платформенных решений в целом можно почитать, например, в этом обзоре: http://personeltest.ru/aways/habr.com/ru/post/528614/). Причём под кросс-платформенностью в данном случае понимаются именно мобильные разработки (отсюда и название Smart MobileStudio), в числе которых поддерживаются и -- внимание, - веб-приложения! Разработчики сумели в данном случае добиться прямой трансляции кода на Delphi в аналогичный код JavaScript, исполняемый прямо в браузере. Закоренелые паскалисты могут торжествовать.

Надо сказать, что и приверженцы других кросс-платформенных языков и фреймворков тоже не остались в стороне. Например, возвращаясь к тому же миру .NET, следует отметить, что в настоящий момент имеется уже как минимум несколько попыток портирования популярных инструментов и фреймворков, ориентированных на создание кросс-платформенных приложений, для работы чисто в веб-среде. Среди них сразу же вспоминаются такие проекты, как Ooui (задавшийся целью перенести такой популярный мобильный фреймворк, как Xamarin, в приложения, исполняемые исключительно в браузере) или UnoFramework (авторы которого пытаются продвигать в веб идеологию UWP-приложений). Основная провозглашаемая авторами подобных оригинальных разработок цель -- добиться того, чтобы проектируемые нами приложения по возможности выглядели одинаково что под iOS и Android (либо, как вариант, Win, Mac и Linux), что и непосредственно в браузере.

Правда, такие приложения уместнее сравнивать скорее с создаваемыми посредством майкрософтовской технологии ASP.NET

Вспомним заодно уж и о Xojo кросс-платформенной объектно-ориентированной среде программирования, основанной на языке REALbasic (своеобразном аналоге VisualBasic почти как Lazarus по отношению к BorlandDelphi; правда, на сей раз речь идёт о коммерческом продукте). Она тоже в настоящий момент позволяет создавать код не только для Windows, macOS или Linux, но и напрямую для веба используя для этого всё те же принципы проектирования RAD. Правда, такие приложения уместнее сравнивать скорее с создаваемыми посредством майкрософтовской технологии ASP.NET в последних, конечно же, тоже широко используются принципы проектирования RAD, но тем не менее требуют для своего развёртывания веб-сервер.

Наконец, нельзя не упомянуть под конец и о другой, скорее прямо противоположной описанным здесь ранее подходам, но не в пример более модной тенденции последних лет желании по возможности полностью упаковать проектируемое приложение в свой собственный контейнер веб-браузера, в котором и будет реализована вся программная логика и пользовательский интерфейс с применением технологий HTML5 (вспомнить хотя бы те же средства для разработки UWP, на которых зачастую и основаны приложения, похожие на те, что принято именовать прогрессивными progressivewebapplications, PWA, которые выглядят почти как чисто браузерные, но при этом ведут себя подобно другим приложениям для соответствующих устройств). Возможно, это явные признаки того, что на смену разработчикам старой формации (кнопкодавителям, клепателям формочек - как их иногда пренебрежительно именуют) уже пришло новое поколение, для которого все эти веб-стандарты и принципы разметки уже, что называется, прочно вошли в подкорку. Равно как и по-прежнему отталкивающий многих синтаксис JavaScript и базирующиеся на нём принципы построения приложений. Хорошо это или плохо покажет время... Возможно, пройдёт ещё несколько лет, и в моду начнёт постепенно входить уже какой-нибудь совершенно новый подход в плане дизайна и компоновки приложений, не имеющий ничего общего с прежним структурированием на базе HTML-тэгов. Не сразу, но по мере своей естественной эволюции он начнёт занимать всё более прочные позиции в тех областях, где пока ещё безраздельно правят HTML5 и JavaScript. Поживём увидим.

Пусть другие теперь строят прогнозы, мы же лишь попытались дать краткий сравнительный обзор технологий для построения приложений, работающих прямо в браузере пользователя (что называется, из коробки) как имеющих на данный момент скорее историческое значение, так и пока ещё актуальных.

Подробнее..

Проверка разметки сайтов-участников W3C

15.07.2020 22:07:35 | Автор: admin
Учитывая возможные сложности с дорогой на собеседование в одну известную фирму, я запланировал один час как запас времени. Два поезда не пришли и запас времени быстро закончился. В приглашении вместо номера телефона и емейла была ссылка на корпоративный сайт, где можно отправить сообщение любому работнику.

Оказалось, что сайт живёт своей собственной жизнью, если его открыть с мобильного телефона. В результате, простая отправка сообщения об опоздании заняла у меня 20 минут и четверть заряда аккумулятора, которого до этого была только половина.

Это был случай, когда технологии, которым я стал доверять, подвели меня.
Позже я заметил, что технологии стали подводить всё чаще и стал меньше на них полагаться.

Во многих случаях причиной является простая ошибка организации интернет-сайтов.
Всё чаще мы используем мобильный телефон и мобильный интернет, ресурсы которых ограничены. Достаточно простые сайты перегружены рекламой, трекерами, библиотеками, анимациями, гигантскими картинками и свёрстаны с большим количеством ошибок.
Всё чаще оно просто не работает.

Интересно, что интернет также перегружен всевозможными советами, SEO, правилами, как делать правильно. Существует даже организация, призванная улучшать интернет.

Члены W3C клуба


Несмотря на критику в адрес организации, она занимается стандартизацией интернета и предоставляет много бесплатных ресурсов. Насчитывает более 400 участников.

Мне стало интересно, как относятся сами участники клуба к своим сайтам.
Ниже приведены результаты эксперимента по проверке их вёрстки с помощью валидатора validator.w3.org.

Результаты проверки разметки сайтов-участников W3C




Без проверки (значение -1) оказались адреса, которые внесены с ошибкой в список участников или не дали себя анализировать. Ко вторым относятся, например, facebook и google. Можно объяснить особенностью их бизнес-модели. Хотя Youtube можно проверить и показывает 53 ошибки, одна из них указана как фатальная.

Совсем без ошибок оказалось 23 сайта. Это около 5%. Подтверждает внутреннее ощущение того, что именно столько Интернета нормально работает.

Главная страница W3C свёрстана с одной ошибкой и похожий результат показывают ещё 88 сайтов её членов.

Остальных 297 участников, видимо, не сильно волнуют стандарты на своих сайтах. Может быть потому, что у гигантов нет времени на такие мелочи.

Например, проверка Хабра показывает 61 ошибку.

Вывод


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

Ссылки


Хорошим примером организации, которая действительно улучшает Интернет, можно назвать w3schools.
В разделе CSS шаблонов бесплатно можно скачать примеры оформления. Технологии хорошо структурированы и описаны.
Файл результатов эксперимента в формате csv.
Подробнее..

Вам показалось! Все о Perceived Performance

21.01.2021 14:15:10 | Автор: admin

Перед вами быстрый, удобный и отзывчивый сайт? Возможно, это не результат плодотворной работы множества людей, а всего лишь набор психологических и инженерных трюков, направленных на улучшение Perceived Performance.

В большинстве случаев с ростом реальной производительности улучшается и Perceived Performance. А когда реальная производительность не может быть с легкостью увеличена, существует возможность поднять видимую. В своем докладе на Frontend Live 2020 бывший разработчик Avito Frontend Architecture Алексей Охрименко рассказал о приемах, которые улучшают ощущение скорости там, где ускорить уже нельзя.

Производительность обязательное условие успеха современных Web-приложений. Есть множество исследований от Amazon и Google, которые говорят, что понижение производительности прямо пропорционально потере денег и ведет к слабой удовлетворенности вашими сервисами (что снова заставляет терять деньги).

Первопричина полученного стресса ожидание. Научно доказано, что оно может вызывать:

  • беспокойство;

  • неуверенность;

  • дискомфорт;

  • раздражение;

  • скуку.

Вряд ли кто-то хочет, чтобы пользователи испытывали эти эмоции. Поэтому так важно уменьшать время ожидания.

Самое простое решение все делать быстро. Но прежде, чем вы скажете: Спасибо, капитан!, хочу напомнить, что увеличение производительности ведет к прямому уменьшению времени ожидания.

Не игнорируйте этот момент: вы обязательно должны его учитывать.

Для этого есть множество разнообразных техник, в том числе:

  • lighthouse;

  • devTools profiler.

Но даже если все сделать идеально, этого может оказаться недостаточно.

Есть интересная история про аэропорт Huston. Она отлично вписывается и в современные реалии разработчиков.

Существует некий сценарий использования аэропорта: самолет прилетает, высаживает пассажиров, выгружает багаж. Пассажиры идут в зону выдачи, чемоданы через какое-то время появляются на транспортере.

Люди часто жаловались на долгое ожидание багажа в аэропорту. И инженеры аэропорта Huston не спали ночами, работали сверхурочно, но реализовали выдачу багажа всего за 8 минут. Однако клиенты все равно продолжали жаловаться.

Инженеры не знали, что делать. И они решили попробовать один трюк. Высадив людей как можно дальше от зоны выдачи багажа, они вынудили их быть в активном ожидании. Пока те добирались до места назначения, багаж уже ждал их. В результате все жалобы прекратились. Но самое интересное, что реальное время выдачи багажа осталось абсолютно таким же: 8 минут.

Почему же клиенты пришли в восторг от происходящего, хотя реальная производительность никак не изменилась?

Perceived Performance

Инженеры аэропорта улучшили Perceived Performance, или видимую производительность. Это очень глубокий термин. Видимая производительность включает в себя реальную производительность.

Если вы ускорите работу своего сайта, увидите, что он ускорился абсолютно логичная закономерность.

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

Все это базируется на том, что люди не очень хорошо умеют измерять реальную производительность. И именно эту особенность можно эксплуатировать.

Все дальнейшие примеры будут для Angular приложений, но, несмотря на это, они применимы к любому современному фреймворку. Приступим!

Не блокируйте пользователя

Первый совет: ни в коем случае не стоит блокировать пользователя. Вы можете сейчас сказать: Я и не блокирую!.

Попробуйте узнать себя в этом примере:

Допустим, мы кликаем на удаление какого-то элемента, запрашиваем данные, после чего удаляем.

Все равно не узнаете? А так?

Спиннеры это не выход! Хоть они и могут стать ленивым способом разобраться с неудобной ситуацией.

Что можно предложить в качестве альтернативы спиннеру?

Можно нажать на кнопку УДАЛИТЬ и показать статус этой кнопки (item удаляется только для одного элемента), не демонстрируя спиннер. В дальнейшем можно отправить запрос на сервер, и когда он придет, показать, что элемент удалился, либо при ошибке передать данные о ней. Вы можете возразить: Но я могу делать только 1 запрос за раз! это ограничение бэкенда. С помощью RxJs и оператора concat можно буквально одной строчкой кода создать минимальную очередь:

Более серьезная имплементация, конечно, займет больше, чем одну строчку.

Вы можете сказать: Я не могу не блокировать компонент потому, что он состоит из какой-то логики. То есть существуют набор элементов и действия, которые я не могу совершать.

Но ничто вам не мешает не показывать спиннер на весь экран, а поместить его только в той области, которая должна быть заблокирована по факту:

В Angular есть ngx-spinner, который поддерживает такой функционал.

Это, как минимум, уменьшит время ожидания, и пользователь сможет в этот момент сделать хоть что-то.

Обманывайте

Обман зачастую базируется на иллюзиях скорости.

Допустим, есть два спиннера с точками. Если увеличить количество точек в одном из них, кажется, что он начинает крутиться быстрее. На самом деле скорость спиннеров одинакова.

Иллюзия базируется на простом эффекте: чем больше точек, тем больше Motion Blur (размытие движения). Этот трюк используется в мультфильмах. Возможно, вы видели, что когда койот бежит очень быстро, у него размываются ноги, и вместо них появляется облако.

Где можно применить такую методологию?

  • Progress Bar;

Есть исследование, показывающее, что если добавить полоски, которые идут в обратном направлении внутри Progress Bar, то визуально он выглядит как более быстрый. В такой настройке можно получить до 12% ускорения, просто применив дополнительный скин. И пользователи воспримут работу, прошедшую под этим Progress Bar, на 12% быстрее. Вот пример того, как можно реализовать такой слайдер на CSS.

  • Скелетон;

Если спиннеры это плохо, что же тогда показать на экране? Можно продемонстрировать силуэт, некий образ того контента, который будет отображен.

Скелетон это некое схематическое отображение сайта до момента его загрузки:

В этом примере мы видим, где будут расположены чаты.

Существует исследование, которое показывает, что люди воспринимают скелетоны быстрее от 10 до 20%.

То есть по ощущениям пользователей, сайты со скелетоном работают быстрее.

Существует огромное количество нужных компонентов для Angular, React, View. К примеру, для Angular есть skeleton-loader, в котором можно прописать внешний вид и сконфигурировать его. После чего мы получим наш скелетон:

  • Экспоненциальная выдержка.

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

Мы можем сделать так, что API будет выглядеть более стабильным за счет одной простой функции. Получив ошибку на запрос, просто повторяем его.

Это одна из best practice в энтерпрайз-приложениях, потому что бэкенд может не работать по разным причинам. Например, происходит деплой или хитрая маршрутизация. В любом случае очень хорошее решение: попробовать повторить. Ведь никакое API не дает 100% гарантии, 99,9% uptime.

Но есть маленький нюанс. Если мы будем повторять бесконечно, то в какой-то момент повалим наш сервер. Поэтому обязательно поставьте ограничение. Например, повторять максимум 3 раза.

Но даже с этим сценарием мы сами себе можем сделать DDOS (Distributed Denial of Service). На это попадались многие компании. Например, Apple с запуском своего сервиса MobileMe.

В чем идея? Представьте на секунду, что ваш сервис падает под нагрузкой, то есть он с ней не справляется. Если сервер перегружен, то скорее всего ответит статус-кодом 500. Если вы попробуете еще раз, возможно, следующий запрос получит ответ.

Но если сервер упал под нагрузкой, и у всех одновременно запросы ответили с ошибкой, то все начнут перезапрашивать в одно и то же время, вы сами устроите себе DDOS. На сервер будет идти постоянная нагрузка, он не сможет передохнуть и наконец-то начать отвечать нормально.

Best practice: применять exponential backoff. В rxjs есть хороший дополнительный npm пакет backoff-rxjs, который за вас имплементирует данный паттерн.

Имплементация очень простая, 10 строчек кода. Здесь вы можете обойтись одной. Указываете интервал, через который начнутся повторы, количество попыток, и сбрасывать ли увеличивающийся таймер. То есть вы увеличиваете по экспоненте каждую следующую попытку: первую делаете через 1 с, следующую через 2 с, потом через 4 с и т.д.

Играя с этими настройками, вы можете настраивать их под ваше API.

Следующий совет очень простой добавить Math.random() для initialInterval:

Идея в том, что изначально, если все одновременно начнут повторять запросы, все равно может возникнуть ситуация, когда появится огромное количество запросов одномоментно. Поэтому добавив некий рандомный запрос, вы как бы размажете нагрузку повторных запросов на бэкенд.

Предугадывайте!

Как уменьшить ожидание, когда невозможно ускорить процесс?

Вы можете просто делать все заранее. К примеру, если вы занимаетесь изготовлением мороженого и знаете, что оно готовится очень долго, можете сделать его заранее, поставить в холодильник и избежать огромной очереди. Этот прием можно применить в сценариях с веб-производительностью.

  • Предзагрузка картинок;

Один из самых простых примеров это предзагрузка картинок. К примеру, у вас есть SPA-приложение. Вы открываете одну страничку, а на следующей есть набор иконок. Вы можете очень простым скриптом написать preload и загружать на конкретной странице картинки, необходимые для другой:

Этот способ слишком олдскульный, потому что есть предзагрузка для взрослых.

  • Предзагрузка 18+

Наверняка вы сталкивались в HTML со стеком link, который позволяет переподключить stylesheets:

Немного поменяв атрибуты, мы можем применить его для предзагрузки:

Можно указать атрибут rel ="preload", сослаться в ссылке на наш элемент (href="styles/main.css"), и в атрибуте as описать тип предзагружаемого контента.

  • prefetch.

Еще один вариант это prefetch:

Главное запомнить, что preload и prefetch два самых полезных инструмента. Отличие preload от prefetch в том, что preload заставляет браузер делать запрос, принуждает его. Обычно это имеет смысл, если вы предзагружаете ресурс на текущей странице, к примеру, hero images (большую картинку).

ОК, это уже лучше, но есть одна маленькая проблема.

Если взять какой-нибудь среднестатистический сайт и начать префетчить все JavaScript модули, то средний рост по больнице составляет 3 МБ. Если мы будем префетчить только то, что видим на странице, получаем примерно половину 1,2 МБ. Ситуация получше, но все равно не очень.

Что же делать?

Давайте добавим Machine Learning

Сделать это можно с помощью библиотеки Guess.js. Она создана разработчиками Google и интегрирована с Google Analytics.

Анализируя паттерны поведения пользователей и, подключаясь к вашему приложению и системе сборки, она может интеллектуально делать prefetch только 7% на странице.

При этом эта библиотека будет точна на 90%. Загрузив всего 7%, она угадает желания 90% пользователей. В результате вы выигрываете и от prefetching/preloading, и от того, что не загружаете все подряд. Guess.js это идеальный баланс.

Сейчас Guess.js работает из коробки с Angular, Nuxt js, Next.js и Gatsby. Подключение очень легкое.

Поговорим о Click-ах

Что можно сделать, чтобы уменьшить ожидание?

Как предугадать, на что кликнет пользователь? Есть очевидный ответ.

У нас есть событие, которое называется mousedown. Оно срабатывает в среднем на 100-200 мс раньше, чем событие Click.

Применяется очень просто:

Просто поменяв click на mousedown, мы можем выиграть 100-200 мс.

Мы можем заранее предсказать, что пользователь кликнет на ссылку.

Я пытаюсь кликнуть на ссылку, и сайт мне говорит, что он знал об этом на 240-500 мс раньше того, как я это сделал.

Опять магия ML? Нет. Существует паттерн: когда мы хотим на что-то кликнуть, мы замедляем движение (чтобы было легче попасть мышкой на нужный элемент) .

Есть библиотека, которая анализирует скорость, и благодаря этому может предсказать, куда я кликну.

Библиотека называется futurelink. Ее можно использовать абсолютно с любым фреймворком:

Вы передаете ей те DOM элементы, которые должны участвовать в прогнозе. Как только библиотека предсказывает нажатие на элемент, сработает callback. Вы можете его обработать и начать загружать страницу или залогинить пользователя заранее.

Что пользователь хочет получить при переходе на страницу? В большинстве сценариев: HTML, CSS и немного картинок.

Все это можно реализовать за счет серверного рендеринга SSR.

В Angular для этого достаточно добавить одну команду:

ng add @nguniversal/express-engine

В большинстве случаев это работает замечательно, и у вас появится Server-Side Rendering.

Но что, если вы не на Angular? Или у вас большой проект, и вы понимаете, что внедрение серверного рендеринга потребует довольно большого количества усилий?

Здесь можно воспользоваться статическим prerender: отрендерить страницы заранее, превратить их в HTML. Для этого есть классный плагин для webpack, который называется PrerenderSPAPlugin:

В нем нужно указываете директорию, куда вы хотите сохранять пререндеренные urls, и перечислить те, для которых нужно отрендерить контент заранее.

Но вы можете сделать все еще проще: зайти в свое SPA приложение и написать:

document.documentElement.outerHTML,

получить пререндеренный HTML и воспользоваться им: сохранить это в файл. И вот у вас за пару минут появилась пререндеренная страница. Если ваша страница меняется очень редко, это неплохой вариант (как бы глупо он ни выглядел).

Заключение

Несмотря на то что Perceived Performance очень субъективная метрика, ее можно и нужно измерять. Об этом говорилось в докладе Виктора Русаковича на FrontendConf 2019.

Он рассказывал о том, что в Скелетоне есть анимация в плавном фоне, и слева направо она воспринимается на 68% быстрее, чем справа налево. Есть разные исследования, которые показывают, что неправильно примененные техники Perceived Performance могут визуально сделать сайт хуже. Поэтому обязательно тестируйте.

Сделать это можно при помощи сервиса под названием Яндекс.Толока.

Он позволяет выбирать, какой из двух объектов лучше. Можно сделать два видео с разной анимацией и предложить пользователям оценить, какой из них быстрее. Это стоит недорого, скейлится очень хорошо. В сервисе зарегистрировано огромное количество людей из разных регионов, то есть можно делать разнообразные выборки по разным параметрам. Благодаря этому есть возможность провести серьезное UX-исследование за небольшую сумму.

Даже если в конце концов вашему начальнику покажется, что быстрее не стало, проведите исследование и попробуйте улучшить ситуацию с помощью Perceived Performance.

Perceived performance это низковисящий фрукт почти в любой компании. Именно сейчас у вас есть возможность, применив вышеперечисленные техники, улучшить воспринимаемую производительность и сделать пользователей и менеджеров счастливыми.

Конференция, посвященная всем аспектам разработки клиентской части веб проектов, FrontendConf 2021 пройдет 29 и 30 апреля. Билеты можно приобрести здесь. Вы можете успеть купить их до повышения цены!

А для того, чтобы стать одним из героев конференции, подайте доклад.

Черновик

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru