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

По същия начин, по който разработчиците обръщат внимание на качеството на кода, като пишат и изпълняват тестове, правят сравнителен анализ на производителността на кода от страна на сървъра и извършват статичен анализ на кода, също е възможно непрекъснато да се одитират различни аспекти на производителността на UI/UX на уеб приложението.

Един от начините да го направите е да използвате инструмент, наречен фар от Google, който е вграден в браузъра Chrome на Google? Можете да получите достъп до него, като отворите инструментите за разработка на Chrome и отидете до раздела Audits.

Чрез непрекъснат одит на ефективността на уеб приложението можем да наблюдаваме тенденцията на ефективността и да открием по-рано понижаването. В тази публикация бих искал да ви покажа как можем да изпълняваме тестовете на базата на график, като напишем малък скрипт на възел и го изпълняваме периодично в конвейера на Azure DevOps Build.

Да започнем със сценария

Изходният код е достъпен на https://github.com/AndrejsAbrickis/lighthouse-azure-devops

Ето какво се случва, когато изпълним метода run.

  1. Първо, програмата за стартиране на chrome стартира нов екземпляр на браузъра Google Chrome с предоставения chromeFlags (използваме Chrome в режим без глава с флаг--headless) и съхранява номера на порта на работещия екземпляр на Chrome в опциите. L8-L9
  2. След това изпълняваме одита на фара, като предоставяме URL адреса за одит и опции и съхраняваме резултатите от одита локално. Lighthouse комуникира с браузъра през порта, който съхранихме в предишната стъпка. L12
  3. За да генерираме JSON отчет (алтернативна опция е HTML), трябва да използваме метода generateReport() на ReportGenerator и да предадем обекта с резултати от фара от предишната стъпка и типа изход. L13
  4. В този пример изходът се записва във файла results.json с помощта на API на файловата система на възела - fs. L15-L23
  5. И накрая, убиваме екземпляра на chrome, преди да излезем от скрипта. L27

За да видите резултатите, можете да плъзнете и пуснете results.json или да копирате и поставите съдържанието му в програмата за преглед на фарове на Google Chrome на „https://googlechrome.github.io/lighthouse/viewer/“

Настройте конвейера за изграждане на Azure DevOps

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

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

След това ще добавим две npm задачи за инсталиране на пакети и стартиране на тестовия скрипт за производителност, който е дефиниран в package.json като тестов скрипт.

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

След като стартираме конвейера за компилация, виждаме, че results.json е наличен като изходен артефакт на компилацията.

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

С този прост скрипт и конвейер за изграждане на Azure DevOps ние настроихме планиран тест за ефективност, който изпълнява одитите на фара на Google Chrome. Вече можем да качим results.json в Azure Blob Storage или AWS S3 контейнер, за да събираме и анализираме данни за ефективността във времето. Това ще ни позволи да видим как промените в кода и конфигурацията на уеб приложението влияят върху производителността на уеб приложенията. И като изпълняваме теста преди всяко производствено издание, можем да сме сигурни, че не предоставяме актуализация, която може да понижи производителността за нашите крайни потребители.

Ако сте намерили тази публикация за полезна и искате да прочетете повече за произволни теми за уеб разработка, просто аплодирайте за тази статия или пуснете коментар тук. И както винаги можете да ме намерите на Twitter@andrejsabrickis