Ади Османи

1 август 2018 г. · 20 минути четене

Изграждане на интерактивни сайтове може да включва изпращане на JavaScript на вашите потребители. Често твърде много от него. Били ли сте на мобилна страница, която изглеждаше така, сякаш се е заредила само за да докоснете връзка или сте се опитали да превъртите и нищо не се случва?

цената

Байт за байт, JavaScript все още е най-скъпият ресурс, който изпращаме на мобилните телефони, тъй като той може да забави интерактивността в голяма степен.

4s. Сравнете с

13s среден телефон (Moto G4) взема или

36-те снимки, направени от телефон от нисък клас през 2018 г. (Alcatel 1X).

Днес ще разгледаме някои стратегии, които можете да използвате за ефективно доставяне на JavaScript, като същевременно предоставяте на потребителите ценно изживяване.

  • За да останете бързи, заредете само JavaScript, необходим за текущата страница. Приоритизирайте това, от което потребителят ще се нуждае, и лениво заредете останалото с разделяне на кода. Това ви дава най-добрия шанс за бързо зареждане и интерактивна работа. Стековете с разделяне на кодовете по маршрути по подразбиране са играчи, които променят играта.
  • Прегърнете бюджетите за изпълнение и се научете да живеете в тях. За мобилни устройства се стремете към JS бюджет на Научете как даодит и отрежете вашите JavaScript пакети. Има голям шанс да изпратите пълни библиотеки, когато се нуждаете само от фракция, поли запълване за браузъри, които не се нуждаят от тях, или дублиран код.
  • Всяко взаимодействие е началото на ново „Време до взаимодействие“; помислете за оптимизации в този контекст. Размерът на предаване е критичен за мобилните мрежи от нисък клас и времето за анализ на JavaScript за устройства, свързани с процесора.
  • Ако JavaScript от страна на клиента не е от полза за потребителското изживяване, попитайте се дали наистина е необходимо. Може би рендерираният от сървъра HTML всъщност би бил по-бърз. Помислете за ограничаване на използването на рамки от страна на клиента до страници, които абсолютно ги изискват. Предаването на сървъри и клиенти са катастрофа, ако се направи лошо.

Когато ние достъпваме вашия сайт, вие вероятно изпращате много файлове, много от които са скриптове. От гледна точка на уеб браузърите това изглежда малко по следния начин:

Колкото и да обичам JavaScript, това винаги е най-скъпата част от вашия сайт. Бих искал да обясня защо това може да е основен проблем.

Понастоящем средната уеб страница разполага с около 350 KB умален и компресиран JavaScript. Некомпресиран, който издухва до над 1 MB скрипт, който браузърът трябва да обработи.

Забележка: Не сте сигурни дали вашите пакети на JavaScript забавят колко бързо потребителите взаимодействат с вашия сайт? Разгледайте фар .

350KB минимизиран и компресиран скрипт. Тези страници отнемат до 15 секунди, за да станат интерактивни.

Опитът, който доставя толкова много JavaScript, отнема повече от 14+ секунди за зареждане и получаване на интерактивност на мобилни устройства.

Голям фактор за това е колко време отнема изтеглянето на код в мобилна мрежа и след това обработката му на мобилен процесор.

Нека разгледаме мобилните мрежи.

Тази диаграма от OpenSignal показва колко последователно 4G мрежите са глобално достъпни и средната скорост на връзката за потребителите във всяка държава. Както виждаме, много страни все още изпитват по-ниски скорости на свързване, отколкото си мислим.

Не само, че 350 KB скрипт за среден уебсайт от по-рано отнема известно време за изтегляне, реалността е, че ако разгледаме популярни сайтове, те всъщност доставят много повече скрипт от този:

Постигаме този таван както за настолни компютри, така и за мобилни мрежи, където сайтовете понякога доставят код на стойност няколко мегабайта, който след това браузърът трябва да обработи. Въпросът, който трябва да зададете, е, можете ли да си позволите толкова много JavaScript ?

Днес сайтовете често изпращат следното в своите JS пакети:

  • Клиентска рамка или библиотека на потребителския интерфейс
  • Решение за държавно управление (напр. Redux)
  • Polyfills (често за съвременни браузъри, които не се нуждаят от тях)
  • Пълни библиотеки спрямо само това, което използват (напр. Всички lodash, Moment + локали)
  • Набор от UI компоненти (бутони, заглавки, странични ленти и др.)

Този код се сумира. Колкото повече има, толкова по-дълго ще отнеме една страница да се зареди.

Зареждането на уеб страница е като филмова лента, която има три ключови момента.

Има: Случва ли се? Полезно ли е И използва ли се?

Случва ли се е моментът, в който можете да доставите малко съдържание на екрана. (стартира ли навигацията? сървърът започна ли да отговаря?)

Полезно ли е е моментът, в който сте нарисували текст или съдържание, който позволява на потребителя да извлече стойност от опита и да се ангажира с него.

И тогава може ли да се използва е моментът, в който потребителят може да започне смислено да взаимодейства с преживяването и да се случи нещо.

По-рано споменах този термин „интерактивен“, но какво означава това?

За да бъде една страница интерактивна, тя трябва да може да реагира бързо на въведеното от потребителя. Малък полезен товар на JavaScript може да гарантира, че това се случва бързо.

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

Това обикновено се случва, когато хората от страна на сървъра представят опит и след това изпращат куп JavaScript след това, за да „хидратират“ интерфейса (прикачване на манипулатори на събития и допълнително поведение).

Когато браузър стартира много от събитията, които вероятно ще ви трябват, вероятно ще го направи в същата нишка, която обработва потребителското въвеждане. Тази нишка се нарича основна нишка.

Зареждане на твърде много JavaScript в основната нишка (чрез