Можете да имате най-добрите функции в света, но те не означават нищо, ако някой екран на приложението ви се зарежда дори малко бавно. Тази публикация ви казва как да не разочаровате потребителите с вашето приложение и разкрива някои нови технологии.

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

1. Използвайте webpack, за да групирате вашите файлове

Спомням си времето, когато почти никой не събираше файловете си, но сега това е стандарт. В повечето случаи трябва да изпратим кода в един пакетен файл (за разделяне на код вижте точка 9). Защо? По-бързо е. Прехвърлянето на един голям файл е по-бързо от изпращането на много по-малки заявки (въпреки това може да се промени в бъдеще, вижте следващата точка). Можем да използваме инструменти като webpack, за да го направим вместо нас и в рамките на минута да направим конфигурация за нашия проект, която може да обедини файловете, да минимизира кода, да премахне коментари, да оптимизира стилове и да добави необходимите префикси и да транспилира кода, за да разшири поддръжката на браузъра.

Ето един прост пример как изглежда:

За да ви помогна да разберете как работи, препоръчвам ви да прочетете тази публикация: Как работи webpack на примери.

Ако искате нещо по-усъвършенствано, с оптимизации до краен предел, можете да проверите нашата конфигурация на SwingDev webpack. Поддържа .env файлове, Typescript, различни конфигурации за среда и много повече!

2. Използвайте Gzip, разбира се

Можете да спестите много KB само като се уверите, че gzip кодирането е включено на вашия сървър. Можете да проверите дали вашият сървър използва gzip с този уебсайт Checkgzipcompression.com или можете да го проверите сами с Google Chrome DevTools.

Отидете до раздела Network, изберете който и да е CSS/JS файл и потърсете заглавка Content-Encoding. Ако е там, вие използвате gzip 🎉

Ако търсите нещо още по-добро, можете да проучите Brotli. Препоръчвам ви да прочетете „Разбиране на потенциала на Бротлис“. Ще ви покаже защо си струва да проверите.

3. Използвайте кеша, когато е възможно

Заявки: Често не е необходимо повторно извличане на данни от API, ако знаем, че е малко вероятно те да са се променили в рамките на определен период. Като не извличаме данните, ние сме приятелски настроени към потребителите на мобилни данни, ограничавайки ненужните извиквания на API и свеждайки до минимум повторното представяне на приложения поради актуализации на състоянието.

Активи: Механизмът за кеширане на браузъра е ваш приятел. По време на разработката може да доведе до някои много разочароващи ситуации, но наистина помага да подобрите ефективността на вашия сайт. Всеки браузър кешира съдържание като изображения, JavaScript или CSS. В наши дни можем да го изведем на друго ниво. Използвайки Service Workers, можем да получим офлайн достъп до нашите ресурси.

„Документи за обслужващ работник“

Кеширане на файлове със Service Worker

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

4. Сервирайте изображения в подходящи размери

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

Имаме нужда от поне четири различни размера на изображението. Защо не можем да използваме само едно изображение? Представете си, ако оригиналната снимка е 1 MB и показваме десет продукта на страница. Потребителят ще изтегли 10 MB само снимки, а това не е това, което искаме. Ако можете, опитайте се да генерирате различни изображения за различните части на вашия сайт, това ще спести много KB за вашите потребители. Трябва също да вземете предвид текущата разделителна способност на екрана. Например, ако някой отвори вашия сайт на мобилния си телефон, няма нужда да показвате огромното заглавно изображение, което обикновено използвате. Вероятно също искате различна картина за вашия ясен дисплей на iPad Pro и различна за бюджетно устройство с Android с ниска резолюция.

Можете да използвате <source/> HTML таг, който може да се използва вътре в HTML5 <picture/>, за да определите кои изображения трябва да използва уеб браузърът в зависимост от ширината или височината на екрана. Документи

Или използвайте CSS медийни заявки

5. Изпращайте само делта при актуализации

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

За дълбоки делти можем да използваме следния пример:

Не забравяйте, че PUT и PATCH заявките са създадени за различни цели. Методът PUT е описан по следния начин в RFC 5789:

Няколко приложения, разширяващи протокола за прехвърляне на хипертекст (HTTP), изискват функция за частична промяна на ресурса. Съществуващият HTTP PUT метод позволява само пълна подмяна на документ. Това предложение добавя нов HTTP метод, PATCH, за модифициране на съществуващ HTTP ресурс.

Така че PUT трябва да се използва само ако заменяте ресурс в неговата цялост, а не когато просто актуализирате някои части от него.

6. Показване на значка, че потребителят е загубил интернет връзка

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

7. Използвайте HTTP-2

Той позволява на сървърите да „избутват“ отговорите проактивно в клиентските кешове, вместо да чакат нова заявка за всеки ресурс. Той използва новото разширение ALPN, което позволява по-бързи криптирани връзки, тъй като протоколът на приложението се определя по време на първоначалната връзка. Вижте и други предимства от използването на HTTP/2.

Друг ресурс, който мога да ви препоръчам, за да научите за това предимство на протокола, е презентация, направена от Patrick Hamann на JSConf EU 2018

8. Разделяне на кода

Най-описателната дефиниция, която знам за разделянето на код, е от React документация:

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

За да избегнете навиването с голям пакет, добре е да изпреварите проблема и да започнете да „разделяте“ пакета си. Code-Splitting е функция, поддържана от пакети като Webpack и Browserify (чрез factor-bundle), които могат да създават множество пакети, които могат да се зареждат динамично по време на изпълнение.

Разделянето на кода на вашето приложение може да ви помогне да „заредите лениво“ само нещата, които в момента са необходими на потребителя, което може драматично да подобри производителността на вашето приложение. Въпреки че не сте намалили общото количество код в приложението си, вие сте избегнали зареждането на код, от който потребителят може никога да не се нуждае, и сте намалили количеството код, необходим по време на първоначалното зареждане.

Прочетете повече за разделянето на код в React

Анализиране на разделянето на кода на размера на пакета в приложението за създаване на реакция

„Разделяне на код в Angular“

„Разделяне на код във Vue“

Както можете да видите, има много области, в които можем да подобрим ефективността на нашето приложение.

Ако искате повече примери и решения, можете да погледнете Ръководство за разработчици на Frontend на SwingDev. Вложихме много работа, за да го направим, но определено си заслужаваше, вижте сами.

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

ПРИЯТНО КОДИРАНЕ и оптимизиране! 🦄

Харесва ли ви? Докоснете бутона 👏! Благодаря ви!

Можете да ме намерите в GitHub.