Колко бързо първоначално се зарежда вашият уебсайт или приложение е първото впечатление, което получават вашите потребители. В това ръководство ще изброим доказани техники за спестяване на ценни секунди от първоначалното зареждане на страницата.
Съдържание
Първоначално време за зареждане
Времето, което отнема от момента, в който вашият потребител или клиент въведе името на домейна на уебсайта ви до момента, в който видят съдържание, са най-важните няколко секунди, които имате, за да направите добро първо впечатление.
Amazon установи, че всеки 100 милисекунди латентност им струва 1% от продажбите.
И въпреки това много уеб разработчици приемат това като закъснение. Добавят се все повече и повече библиотеки за все повече и повече функции и постепенно с течение на времето те започват да виждат по-малко реализации. Още по-лошо, тези загуби в преобразуването са трудни за откриване, защото те изоставят бавно зареждаща се страница, преди да има време да изпрати каквито и да било показатели.
Някои от тях са техники, които могат да бъдат приложени в предния край, а други в задния край. Независимо от това, уеб приложенията трябва да се зареждат бързо.
Добавете правилните измервания
Първото нещо, което трябва да направите, е да добавите измервания. Има много етапи на процеса на зареждане и няма да разберете къде е тясното място, без да измерите правилните сегменти.
Следните са най-важните етапи от процеса на зареждане:
Измервания | Диаграмата е създадена на Terrastruct
Това означава, че трябва да проследявате показатели за всеки сегмент от тази диаграма.
Нека да разгледаме как можете да направите това.
Обслужена заявка за отговор от браузъра:
Измерете това на вашия сървър. Искате да получите момента, в който вашият API получи заявката, когато обслужва отговор. В зависимост от това дали се правят външни повиквания към, например, бази данни, това може да бъде или много кратко, или значително затруднение.
Отговорът е връчен на получения отговор:
Това е по-трудно за измерване, но един от начините да го направите е да добавите клеймо за време, когато вашият отговор напусне вашия сървър и да го измерите с текущото време от страна на потребителя в първия възможен момент (таг на скрипт в главата на HTML страница).
Отговор, получен за първото боядисване със съдържание:
Първото рисуване със съдържание се отнася до момента, в който първият елемент е изобразен в DOM. Това може да бъде нещо толкова просто като текст, фон или зареждащ се бутон. Това може да се измери чрез стартиране на Lighthouse в инструментите за разработка на Chrome.
Първо боядисване със съдържание до боядисване с най-голямо съдържание:
Най-голямото боядисване на съдържание се отнася до това, когато най-големият елемент е изобразен в прозореца за изглед на браузъра на потребителя. Това обикновено сигнализира за края на частта за „изобразяване“ от зареждането на страницата и потребителят вижда попълнен екран. Това също се измерва чрез стартиране на Lighthouse.
Най-голямото боядисване на съдържание до време за интерактивност:
И накрая, времето за интерактивност се отнася до това, когато потребителят може да извършва действия като превъртане, щракване и въвеждане. Може да бъде особено разочароващо, ако тази продължителност е дълга, защото те ще видят изобразен екран пред себе си, но не могат да направят нищо, когато очакват, че могат! Това е друг показател, който Lighthouse ни помага да измерим.
Намалете кода
Сега, след като имате измервания, можете да започнете да правите оптимизации. Оптимизациите имат компромиси и измерванията ще ви кажат кои си заслужават.
Най-бързо зареждащата се страница е празна страница, но към приложение може да се добави много код, преди някой да забележи разликата в скоростта на зареждане между него и празна страница. Това, което често се случва, е, че увеличенията са толкова малки, че не усещате разликата от компилация до компилация, докато един ден просто не започне да се чувства бавно. Осъзнавате, че приложението ви е раздуто и точно в този момент намаляването на кода ще има значение.
Получавате две подобрения в скоростта, когато намалите кода:
- Вашето приложение се прехвърля по мрежата по-бързо.
- Браузърът на потребителя завършва анализирането на кода по-бързо.
Първото ускорение е малко; тъй като заявките се компресират по кабела, ако изрежете 1 MB изходен код, това може да възлиза на само 10 KB спестявания от честотната лента. Въпреки това, ускоряването от по-малко анализиране е значително. Вашите потребители вероятно изпълняват приложението ви на цял спектър от браузъри и компютри, много от които нямат изчислителната мощност, която може да анализира кода толкова бързо, колкото го прави сами.
Или могат да работят на мобилни устройства с дори по-малко изчислителна мощност. Разликата може да бъде в големината на секундите.
Така че колкото по-малко код имате, толкова по-бързо браузърът може да завърши анализирането и да стартира приложението ви. Дори ако искате да покажете екран за зареждане, който Javascript контролира, той е предшестван от анализ на този код.
Но не искате да изрязвате функции или всъщност да изтривате код. За щастие има няколко стандартни практики за намаляване на кода, без да се налага да правите това.
- Изпълнете кода си чрез минификатори. Минификаторите извършват оптимизации като съкращаване на дълги имена в кратки (signUpDarkModeButton става ss), премахване на знаци за интервали и други, за да направите кода си възможно най-компактен, без да губите нищо.
- Импортиране на части. Библиотеките често са препълнени с неща, от които не се нуждаете, но идват опаковани под общ пакет. Може би искате само конкретна функция на библиотека с помощни програми, така че вместо да импортирате цялата библиотека, можете да импортирате само кода, от който се нуждаете.
- Мъртъв код за разклащане на дърво. Понякога оставяте код за целите на отстраняване на грешки или не сте почистили напълно отхвърлена функция и въпреки че е във вашия изходен код, тя никога не се изпълнява. Има инструменти в инструменталната верига на JavaScript, като Webpack, които могат да открият мъртъв код или неизползвани зависимости и да ги премахнат автоматично от производствената компилация вместо вас.
Разделете кода на части
След като намалите възможно най-много код от цялостното си приложение, можете да помислите за по-нататъшно притискане на тази идея и намаляване на кода, необходим за първоначалното зареждане.
Да приемем, че 20% от кода ви захранва някаква функция на приложението ви, до която потребителите могат да стигнат само след няколко кликвания. Ще бъде загубено време за браузъра да анализира този код, преди да покаже екран за зареждане. Разделянето на вашия код на части може значително да намали времето за интерактивност.
Вместо да имате преплетена графика на зависимости на импортиранията за всички ваши Javascript файлове, идентифицирайте области, които лесно се изрязват. Например, може би даден компонент зарежда някои тежки библиотеки. Можете да изолирате този компонент в негов собствен файл и след това да импортирате само когато потребителят е готов да взаимодейства с този компонент.
Има няколко библиотеки за отлагане на зареждането, в зависимост от това коя рамка използвате. Няма нужда да прекалявате с това и да разделяте всеки компонент, защото тогава потребителят има бързо първоначално зареждане и трябва да чака всяко следващо взаимодействие. Намерете най-големите части, които можете да сегментирате, и разделете своя изходен код там.
Рендиране от страна на сървъра
Като се има предвид, че браузърите трябва да извършват цялото това интензивно анализиране и компилиране и имат потребители на Chromebook и мобилни устройства, една често срещана техника за намаляване на времето за зареждане е вашите сървъри да поемат част от това натоварване. Това означава, че вместо да дадете празна страница и след това да използвате Javascript за попълване на цялото съдържание, както правят повечето приложения с една страница в наши дни, можете да стартирате Javascript машина на вашия сървър (обикновено Node.js) и да попълните колкото можете повече от данните и съдържанието.
Вашите сървъри ще бъдат много по-бързи и предвидими от браузърите на потребителите. Неизбежно те все пак ще трябва да анализират някакъв Javascript код, за да бъде приложението интерактивно. И все пак изобразяването от страна на сървъра може да запълни голяма част от първоначалното съдържание, така че когато потребителят получи страницата, тя вече показва поне екран за зареждане или лента за прогрес.
И ако са необходими данни за първоначалния изглед, клиентът не трябва да прави отделна заявка, за да ги получи; вече ще бъде хидратиран в приложението, за да може клиентът да го използва.
Компресиране на активи
Активите карат страницата да оживее и страницата не изглежда напълно заредена, докато тези активи не завършат изобразяването. Това може да е вашият фон, икони на потребителския интерфейс, снимка на потребителския профил, дори бутонът за зареждане. Често активите също могат да изместят оформлението, така че ако потребителят започне да се опитва да взаимодейства с нещо, страницата може да продължи да скача наоколо, докато активите се зареждат. Понякога тези активи са най-голямата боя със съдържание.
Но активите също са една от най-тежките части на приложението. Едно изображение може да достигне няколко мегабайта и зареждането на много икони може лесно да надхвърли максималното ограничение за едновременни мрежови заявки на браузъра, причинявайки зашеметяваща опашка за зареждане.
Почти никога не искате да изтеглите изображение от интернет и след това да го посочите в приложението си. Изображенията трябва да бъдат преоразмерени до най-малките възможни размери, в които ще се показват. Ако имате потребителски профил, показан в малък елемент с размери 50 на 50 пиксела, без преоразмеряване, приложението ви ще отдели време, за да изтегли пълното изображение, което изглежда остро като тапет на работния плот, и след това ще го преоразмерите до малкия размер.
Второ, изображенията могат да бъдат компресирани в зависимост от техния формат. В наши дни webm е предпочитаният формат, но областта на компресиране в мрежата непрекъснато се подобрява и много нови формати са на хоризонта. Поради променящия се характер на форматите, някои браузъри може да не поддържат по-новите! За щастие технологията на браузъра може да позволи на браузъра на потребителя да зарежда какъвто и формат да поддържа.
Така че, компресирайте до най-новия и най-добрия формат, но също така запазете по-малко модерна версия и използвайте картинни и видео елементи, които поддържат резервни формати.
Заключение
Това са пет от най-ефективните техники за предоставяне на вашите потребители на светкавично бързо първо зареждане на вашето приложение. Те ще подобрят вашите проценти на реализация, потребителското щастие и дори класирането при търсене, тъй като SEO възнаграждава бързо време за зареждане. При Terrastructние използваме тези техники и други, така че потребителите да могат да създават и преглеждат диаграми, които виждате в тази статия, възможно най-бързо.