Нека продължа да започвам писанията си с цитати от любими книги.
Планирането е важно, но най-важната част от всеки план е да планирате плана, който не върви по план
- Морган Хаусъл
В тази статия ще обсъдя как подобрихме показателите на Lighthouse от 38% на 82% и намалихме времето за FCP (First Contentful Paint) от 5,7 секунди до около 1,0~1,7 секунди в проекти, в които използваме пакета Design System.
Позволете ми да започна, като обясня как стигнахме до тук. Ние като екип за разработка на Insider разработихме 11 различни продукта за нашата компания и за да управляваме по-добре предната част на тези продукти, използвахме Design System. Можете да намерите съответната статия тук.
Тъй като системата за проектиране съдържа всички компоненти, беше създаден 13,6 MB JavaScript файл. Както можете да си представите, изтеглянето на пакет от 13,6 MB за първоначалното зареждане, дори ако използвате приложение с една страница, създава отрицателно впечатление за ефективността ви и не прави потребителя щастлив.
И така, какво направихме?
Започнахме с отделяне на продуктите един от друг и сега всеки от тях продължава да съществува в отделни хранилища. Това ни помогна да намалим FCP от 5,7 секунди на 3,4 секунди. Темата как разделихме продуктите обаче е за друга статия.
Имаме VueJS NPM пакет, който изграждаме с Webpack. Първоначално преминахме от Webpack към Vite, което намали размера на пакета от 13,6 MB на 6 MB. Но това не беше достатъчно.
И така, какво беше различното във Vite?
- Бърз сървър за разработка: Vite може да стартира сървъра за разработка бързо, което ви позволява незабавно да видите промените. Това значително ускорява процеса на разработка и осигурява обратна връзка в реално време.
- Модулна разработка:Vite има модулна структура, даваща на всеки компонент и модул собствен обхват. Това ви позволява да работите върху независими модули.
- Поддръжка на динамично импортиране:Vite поддържа динамично импортиране, което му позволява да анализира по-добре зависимостите и да компилира само модулите, които се използват.
- Използване на ESModule: Vite използва стандарта ESModule, което позволява използването на модерни модули на JavaScript, които са по-ефективни от по-старите модулни системи като CommonJS.
6 MB (gzip:1,3 MB) с Vite изглеждаха достатъчни, нали?
Когато изградихме Design System, тя създаваше единичен JavaScript файл и активи. Това означаваше, че при всяко опресняване трябваше да зареждаме 1,3 MB. Както можете да видите в кода по-долу, в index.js експортирахме всички компоненти, което доведе до един голям изграден JS файл. Да, бяхме го намалили до 1,3 MB с Vite, но трябваше да бъде намален допълнително.
Тук решихме, че използването на RollupJS за система за изграждане, базирана на компоненти, би било по-логично. Всеки компонент вече може да бъде експортиран индивидуално и по време на изграждането всеки компонент ще бъде изграден само за себе си. По този начин няма да се налага да зареждаме ненужни компоненти за страницата, въведена от потребителя. Това ни позволи да изтегляме по-малки части, без да бъдем засегнати от ограничаване на честотната лента, осигурявайки по-бързи връщания за други необходими заявки и гарантирайки, че страницата ни се отваря по-рано.
Но как?
Ние конфигурирахме всеки компонент поотделно, което доведе до уникална JS компилация за всеки един. Този подход ни позволява да използваме всеки компонент поотделно, ако е необходимо.
В резултат на това успешно намалихме размера на пакета до 4 KB, в зависимост от използваните компоненти, със среден размер на компонента от 35 KB.
В обобщение, в тази статия обсъдихме начини за значително подобряване на показателите на Lighthouse и FCP времето в проекти, използващи пакета Design System. Първо, разбрахме как 13,6 MB JavaScript файл повлия негативно на потребителското изживяване и предприехме различни стъпки за справяне с този проблем.
Първо, организирахме проектите в отделни хранилища, като намалихме FCP от 5,7 секунди на 3,4 секунди. След това преминахме от Webpack към Vite, което намали размера на пакета от 13,6 MB на 6 MB. Като използвахме RollupJS за експортиране на всеки компонент поотделно, успяхме да намалим още повече размера на пакета, което доведе до размер на изтегляне само до 4KB, което позволява на потребителите да изтеглят само необходимите компоненти, което позволява на потребителите да изживейте FCP пъти бързо от 1~ секунда.
Пътуването към подобряване на производителността обаче не е приключило. Има още стъпки, които можем да предприемем, за да направим нашите уеб приложения по-бързи и по-ефективни. Ще обсъдя тези теми в предстоящите си статии. Дотогава оставайте на линия!
- Резервни варианти за зареждане на шрифтове
- Минимизиране
- Компресия
- Оптимизация на изображението
- Разделяне на код
- Проследяване на показатели
- Използване на CDN
- Мързеливо зареждане
- Кеширане на браузъра.
Ако се интересувате от теми, свързани с предната архитектура, не забравяйте да разгледате тази статия. Не забравяйте да следвате Insider Engineering Blog за по-проницателни статии! ✍️
