Тъй като продължаваме да виждаме области като Машинно обучение, Изкуствен интелект, Наука за данни, квантово изчислениеда се развиват, областта на Уеб разработката също не е изоставен. Вече имаме прогресивни уеб приложения (PWA). Отминаха дните, когато вашето уеб приложение спираше да работи офлайн и показваше „красивия“ динозавър! Да, имам предвид. Динозавър, приятелю, съжалявам, ако това те е наранило, но е време потребителите да видят нещо по-„красиво“сега. Ето как трябва да работи еволюцията, нали? Както и да е, нека се потопим в основната дискусия.
Какво е App Shell?
Обвивката на приложениетое архитектурен модел за изграждане на прогресивни уеб приложениякъдето изпращате само минималните критични ресурсиза да заредите вашия сайт и по-късно да го забавите зарежда други некритични данни или ресурси, което дава на потребителите усещане за родно приложение.
С други думи, можете да мислите за App Shellкато за вашия скелет на страница, който трябва да бъде там, дори когато приложението ви е офлайн! Това означава, че ще кеширатевашите обвивка на приложението и критични ресурсиобщо за мощно зареждане при първи път и по-късно ще заредите останалите данни (отложено зареждане), необходими за вашето приложение. Популярни рамки като Angularи Reactвсе още се сблъскват с много проблеми поради тежката архитектура и оразмеряването на пакета по този въпрос, въпреки че тези неща могат да бъдат решени с някои много умни изпълнение на концепции.
Ще разгледаме предимствата и недостатъците, докато създаваме своя собствена надеждна обвивка на приложението и няма да използваме библиотека или рамка. Точно така, Vanilla JavaScript е правилният начин.
Примерна обвивка на приложението
Преди да започнем да копаем, добра идея е да разберете как всъщност изглежда App Shell и как се отразява производителността. Следният пример ще даде демонстрация на това:
Можете да видите колко бързо се зарежда обвивката и по-късно, след като обвивката се зареди, можете да я използвате, за да заредите други части от вашето приложение, които може да имат данни, извлечени асинхронно чрез използване на стратегии за отложено зареждане. (В демонстрацията App Shell не се използва за отправяне на заявки за данни към момента. В момента изграждам версия на Hacker News, която ще използва тази концепция.)
Близо до края на статията също изброих показателите за ефективност на времето за зареждане на страницата на App Shell. Но не пропускайте съдържанието, представено в следващите няколко раздела, което ще помогне за постигането на това приятно място от 1 секунда време за зареждане на страницата.
Скелетът на страницата
Скелетът на страницата представлява най-важната част от концепцията App Shell. Ето пример за index.html, който беше използван за горната демонстрация.
Тук ще откриете, че съм разделил горния код на следните части:
- Критични вградени стилове (Ред 10)
- HTML секция на обвивката на приложението (основна секция, обхващаща от ред 17 до 54)
- Секция за критични скриптове (Край на тялото на ред 53)
Също така, за да се постигне перфектен PWA резултат, файлът manifest.json ще бъде необходим заедно с иконите. Ще намерите връзката GitHub към пълния изходен код в края на тази статия.
Критични вградени стилове
Критичният раздел за вградени стилове е мястото, където трябва да влязат всички важни стилове, свързани само с обвивката на приложението. Основната причина за това е, че ако сте избрали да запазите CSSкато външен файл, докато и освен ако не бъде намерен в HTML файл и не бъде зареден, изгледът на страницата ви ще бъде блокиран за анализ (известно време се изразходва и за изтегляне на CSSи след това се анализира върху CSSOM).
Ето как конструкцията на DOM (обектен модел на документ)и CSSOM (обектен модел на CSS)работи под капака и CSSе ресурс, блокиращ изобразяването това начин. За повече информация защо CSSблокира изобразяването вижте по-подробно следните статии:
Следващата статия говори за критичния път на изобразяване и е изключително важна тема относно оптимизирането на производителността на времето за зареждане.
Следната статия говори за CSSкато ресурс за блокиране на изобразяването и как може да се избегне блокирането на изобразяване:
HTML раздел на обвивката на приложението
Ако забележите HTML секцията, ще откриете, че съм използвал секция за лентата за навигация и секция за основната част на приложението. Ако искате също можете да добавите в секцията за долен колонтитул под основната секция.
Можете да използвате основната секция на приложението (редове 48–50), за да заредите динамично асинхронно основното съдържание на вашето приложение. По този начин зареждането на страницата няма да бъде възпрепятствано или блокирано и вашите потребители със сигурност ще усетят скоростта на еволюцията незабавно (т.е. вашите потребители винаги ще получават обратна връзка от вашето приложение).
В момента използвам този модел в моята локална настройка за разработка, за да създам приложението Hacker News от самото начало. Разбира се, това е извървяло дълъг път и работи чудесно, като целият фураж се зарежда лениво. Определено ще пиша за това приложение, след като завърша проучването си върху него.
Секция за критични скриптове
Не съм вградил JavaScript за тази част, въпреки че е препоръчително да вградите и скриптове, тъй като вграждането винаги спестява време за изтегляне. Но имаме възможност да изберем да зареждаме JavaScript асинхронно, като използваме атрибутите asyncилиdefer. Използването на някой от тези атрибути ще ви помогне да изтеглите асинхронно съдържанието на вашия скрипт файл.
asyncпомага за асинхронно изтегляне на скриптове и ги зарежда веднага щом завърши изтеглянето. Това не зависи от реда, в който са намерени маркерите на скрипта, и може да причини проблеми, ако един от вашите скриптове зависи от друг скрипт. И така, как да решим този проблем, в случай че искаме да поръчаме?
deferидва на помощ, като ни помага да изтеглим скриптовете асинхронно и дори след като те не получат изтеглянето в ред, те поне се изпълняват в реда на маркерите на скрипта, намерени в HTML документа. Наистина доста удобно!
Чувствайте се свободни да изберете една от техниките за атрибути или вграден JavaScript според размера на вашия HTML. В края на краищата, ако нашият App Shell размер на JavaScript се увеличи, определено ще трябва да го отделим минифицирамеи gzipпреди да го сервираме на клиента.
Кеширане на критични ресурси
Бумът на Service Workersопределено предизвика много шум в областта на първите офлайн приложения. Да, нашият App Shell първо ще бъде офлайн. По-късно ще напиша статия относно отложеното зареждане на ресурси и динамичното им кеширане с помощта на service worker, но за момента тази статия ще се съсредоточи стриктно само върху App Shell.
Следният файл е известен като скрипт на service worker:
Този скрипт работи паралелно с основната нишка на браузъра и действа като прокси, което прихваща заявки и връща отговори.
Основните концепции от горния файл могат да бъдат разделени в общи линии на 3 области:
- Кеширане на статични ресурси по време на събитие за инсталиране (редове 8–23)
- Актуализиране на Service Worker и изтриване на стар кеш (Редове 25–44)
- Кеш след това мрежова стратегия (Редове-46–54)
За това ще са необходими основни познания за обслужващ работник. За повече подробности относно service worker и неговото използване вижте следната статия за подробни обяснения:
Можете също да се обърнете към този невероятен курс от Udacityв сътрудничество с Google:
Кеширане на статични ресурси по време на събитие за инсталиране
Много е важно, за да дадете имената на файловете, които трябва да бъдат кеширани с помощта на Cache API на браузъра. Този API на кеша прави дълъг път, за да гарантира, че допълнителни заявки се извличат от кеша, когато е необходимо.
Събитието install на service worker е идеалното време за указване на имената на файловете, които да бъдат кеширани.Редове 8–23 от кода помагат точно за това. Файловете, които се кешират, са index.html („/“ на ред 14 кешира директно HTML файла по подразбиране), offline.htmlи app.js. Да, offline.html прави точно това, което мислите. Показваше част от офлайн съдържание веднага щом превключих на офлайн режим в демонстрацията и всичко това идваше от кеша.
Актуализирайте Service Worker и изтрийте стария кеш
Събитието активиране на обслужващия работник(редове 25–44), което е събитието активиране. След като сервизният работник бъде инсталиран, събитието за активиране се задейства незабавно, ако преди това не е бил регистриран сервизен работник. Ние съответно филтрираме имената на кеша, така че да не е същото като текущото име на статичен кеш, което ще използваме, и по този начин изтриваме цялото наше предишно кеширано съдържание.
Тази част е много важна, ако искаме редовно да актуализираме браузъра на клиента с най-новите кеш данни и също така да почистваме ненужния стар кеш.
За това всеки път ще трябва да увеличавате името на статичния кеш (ред 1), когато променяте която и да е част от съдържанието на файла на service worker. Винаги помнете, че промяната на байта в service worker е равна на инсталиране на нов service worker.
Кеш след това мрежова стратегия
Тази част от кода (редове 46–54) всъщност помага при първо търсене на данните от кеша. Събитието fetch на service worker се извършва всеки път, когато XHR заявка се задейства от браузъра на клиента.
Ако кешът съдържа отговора, ние незабавно го изпращаме на клиента, без да губим време, в противен случай отиваме в мрежата, за да извлечем данните.
Така че, винаги когато има заявка за offline.htmlбраузърът винаги ще извлича елемента от кеша и ще го показва, когато приложението е в офлайн режим. Подобно нещо се случва, когато кеширате index.html ‘/’съгласно ред 14 и опресните страницата следващия път. Всички ваши заявки ще бъдат извлечени от кеша с помощта на service worker, а не от външна мрежа.
Този начин на динамично обработване на отговорите наистина помага много в показването на силата на сервизните работници и количеството данни, които наистина можем да хакнем.
За неетичните хакери, повярвайте ми, можете да използвате service worker само с HTTPSи localhostпо този въпрос. Следователно обслужващите работници бяха направени по такъв начин, че да се уверят, че съображенията за сигурност вече са налице. Съжаляваме за неетичните хакери!
Така че след всички тези новаторски промени все още може да попитате: „Какво получаваме от това? Какво е въздействието, създадено от него?”. По-долу съм изброил показателите за ефективност. Това ще отговори на всички ваши въпроси.
Сравнителни показатели за ефективност с помощта на Lighthouse
Обвивката на приложението беше тествана в режим инкогнито на браузъра Chrome с помощта на Lighthouseв режим намобилноустройство. Освен това тестът беше проведен на http://localhost:5000/, което е, а не HTTPS. Ето резултатите:
Резултатът PWAможе да стане 100след като внедрите приложението и използвате HTTPSв него. Резултатът за най-добри практики може да бъде направен 100с помощта на HTTP/2който също идва вграден с Firebaseи друг популярен хостинг услуги.
Но най-важната част може да се види в производителносттаназареждането на страницата на самата обвивка на приложението. Постигнахме време за зареждане (Първо значимо рисуване) от600ms тук с одита, което е много по-малко от желаното сладко място от 1 секундавреме за зареждане на страницата.
Размерът на приложението ще нараства в бъдеще, но ако App Shell е проектиран правилно, насочен към производителност, както е направено по-горе, заедно с Мързеливо зарежданеостаналите компоненти на приложението , ще постигнете и тези резултати. Да и винаги помнете, #perfmatters (Ефективността има значение!).
Мързеливо динамично зареждане на данни
Една от основните причини, поради които наблягам на лениво зареждане на съдържанието на приложението след това, е, че може да имате много данни, които трябва да бъдат извлечени от сървъра, през това време, ако потребителят все още вижда празна страница или нищо това ще се отрази силно на потребителското изживяване.
Например, след като Обвивката на приложениетосе зареди, може да искате да покажете въртящ се бутон като част от обвивката на страницата, по време на което приложението ще зареди данните от първата си страница асинхронно в областта на сивото пространство . По този начин вашите потребители ще имат известна обратна връзка, тъй като обвивката на страницата вече е заредена и вие ще използвате разумно времето на неактивност, за да заредите и динамичните данни от сървъра. Кокетни неща!
Заключение
Архитектурата на предния край е също толкова важна, колкото и архитектурата на задния край, която проектирате за вашите приложения. Често сме склонни да забравяме, че повечето проблеми, свързани с производителността, свързани със зареждането на страницата, възникват поради архитектурата на предния край. Да, важно е да проектиратепредния крайв случай, че искате да избегнете живота в каменната ера (Съжалявам, динозавър!).
Следната статия ме вдъхнови да създам своя собствена Обвивка на приложението от нулата.
Ако сте намерили тази статия за полезна, уведомете ме в секцията за коментари по-долу и моля, не забравяйте да ръкопляскате. Планирал съм още такива статии, които ще публикувам във връзка с текущото изследване на използването на всички тези концепции с приложение от реалния свят като Hacker News.
Ето връзката към моя изходен код на GitHub:
Чувствайте се свободни да разклоните това хранилище и да го използвате като част от вашия собствен начален шаблон за вашите бъдещи проекти и да, той е изграден с помощта на Vanilla HTML, CSS и JavaScript. Приятно хакване! 😄
Други публикации от мен
Намерете ме на: https://medium.com/@anurag.majumdar
➥ Уеб разработка
- „Супер“ и „разширява“ в JavaScript ES6 — Разбиране на трудните части
- Въведение в полифилите и тяхното използване
➥ Събитие в живота
- „Предизвикателството за стипендии за Google Mobile Web на Udacity и неговите великолепни ефекти!“
