ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/9569| Title: | Система оцінювання якості WEB-ресурсів |
| Authors: | Немов, Руслан Григорович Новак, Владислав Олександрович |
| Keywords: | браузерне розширення;page analyzer;аналіз веб-ресурсів;технологічний стек;SEO-аудит;CSS viewer;продуктивність веб-сторінки;доступність;react;manifest v3;chrome extension;browser extension;page analyzer;WEB resource analysis;technology stack;SEO audit;CSS viewer;WEB page performance;accessibility;react;manifest v3;chrome extension |
| Issue Date: | 17-Jun-2026 |
| Abstract: | АНОТАЦІЇ
Виконавець: Новак Владислав Олександрович
Назва роботи: «Система оцінювання якості WEB-ресурсів»
Спеціальність: 121 Інженерія програмного забезпечення.
Навчальний заклад: «Черкаський державний технологічний університет»
м. Черкаси, 2026р.
Мета роботи: розробити сучасне браузерне розширення для комплексного аналізу сторінки, яке поєднує в собі виявлення технологічного стеку сайту, SEO-аудит, аналіз продуктивності, перевірку доступності та інтерактивні інструменти для аналізу сторінки.
Цілі:
–
провести аналіз існуючих інструментів та виявити їхні недоліки;
–
сформувати функціональні та нефункціональні вимоги до розширення;
–
спроектувати логічну архітектуру та модель предметної області;
–
реалізувати основні модулі аналізу (технології, SEO, продуктивність, доступність);
–
забезпечити високу швидкодію, зручність використання та можливість подальшого масштабування.
У розділі аналізу вимог були поставлені вимоги для програмного забезпечення.
У розділі моделювання програмного забезпечення було описано архітектуру програмного забезпечення.
У розділі аналізу якості були описані основні тест-кейси та стани системи після проведення тестування.
У розділі впровадження та супроводу було описано процеси розгортання програмного забезпечення. ANNOTATIONS Performer: Novak Vladyslav Oleksandrovych The title of the work: «WEB resource quality assessment system». Specialty: 121 Software engineering. Educational institution: Cherkasy State Technological University, Cherkasy, 2025. Goal: to develop a modern browser extension for comprehensive page analysis that combines technology stack detection, SEO audit, performance analysis, accessibility checking, and interactive tools for page analysis. Objectives: – to analyze existing tools and identify their shortcomings; – to formulate functional and non-functional requirements for the extension; – to design the logical architecture and domain model; – to implement the main analysis modules (technologies, SEO, performance, accessibility); – to ensure high performance, usability, and the possibility of further scaling. In the requirements analysis section, the requirements for the software were defined. In the software modeling section, the architecture of the software was described. In the quality analysis section, the main test cases and the state of the system after testing were described. In the implementation and maintenance section, the processes of software deployment were described. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/9569 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфікаційна_робота_бакалавра Новак Владислав Олександрович.pdf Restricted Access | 6.6 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
бакалавра
на тему: «Система оцінювання якості WEB-ресурсів»
Виконав: студент 4 курсу, групи ПЗ-2204
спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Новак В.О.
(прізвище та ініціали)
Керівник Немов Р.Г.
(прізвище та ініціали)
Рецензент Русалівський Б.В.
(прізвище та ініціали)
Черкаси 2026
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
____________________ С. Голуб
«___» _______________ 2026 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Новак Владислав Олександрович
(прізвище, ім’я, по батькові)
1. Тему проекту (роботи) Система оцінювання якості WEB-ресурсів
Керівник проекту (роботи) Немов Руслан Григорович, асистент
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від « 12 » березня 2026 року
№56/03-03
2. Строк подання студентом проекту (роботи)
3. Вхідні дані до проекту (роботи) Технічне завдання на розробку, методичні рекомендації до виконання
бакалаврської роботи, автоматизовані системи, терміни та визначення
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Вступ;
Розділ 1. Існуючі методи та засоби розв’язання поставлених завдань;
Розділ 2. Впровадження результатів досліджень у практику проектування програмного
забезпечення інформаційних систем;
Розділ 3. Розробка та тестування програмного забезпечення;
Висновки;
Список використаних джерел;
Додатки.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту); Слайд 1; Слайд 2;
Слайд 3; Слайд 4; Слайд 5; Слайд 6; Слайд 7; Слайд 8; Слайд 9; Слайд 10; Слайд 11; Слайд 12; Слайд 13;
Слайд 14; Слайд 15; Слайд 16; Слайд 17; Слайд 18; Слайд 19; Слайд 20; Слайд 21; Слайд 22;
6. Консультанти розділів роботи
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3
7. Дата видачі завдання 05 грудня 2025 р.
КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№ етапів
Назва етапів випускної роботи Примітки
п/п кваліфікаційної
роботи
1 Постановка задачі 05.12.2025 виконано
2 Підготовка завдання 13.12.2025 виконано
3 Погодження завдання 16.12.2025 виконано
4 Затвердження завдання 12.03.2026 виконано
Основна стадія
1 Підбір матеріалів 27.03.2026 виконано
2 Аналіз шляхів вирішення поставленої задачі 04.03.2026 виконано
3 Розрахунок основних параметрів роботи 10.03.2026 виконано
4 Вибір кінцевого варіанту проектного рішення 17.03.2026 виконано
5 Оформлення первісної редакції роботи 25.03.2026 виконано
Заключна стадія
1 Узгодження прийнятих проектних рішень з 31.04.2026 виконано
керівником
2 Оформлення пояснювальної записки роботи в 13.05.2026 виконано
кінцевій редакції
3 Попередній захист роботи 19.05.2026 виконано
4 Затвердження роботи 19.05.2026 виконано
5 Рецензування роботи виконано
26.05.2026
6 Захист роботи 03.06.2026 виконано
Студент _____________________ Новак В.О
(підпис) (прізвище та ініціали)
Керівник роботи _____________________ Немов Р. Г.
(підпис) (прізвище та ініціали)
АНОТАЦІЇ
Виконавець: Новак Владислав Олександрович
Назва роботи: «Система оцінювання якості WEB-ресурсів»
Спеціальність: 121 Інженерія програмного забезпечення.
Навчальний заклад: «Черкаський державний технологічний університет»
м. Черкаси, 2026р.
Мета роботи: розробити сучасне браузерне розширення для комплексного
аналізу сторінки, яке поєднує в собі виявлення технологічного стеку сайту, SEO-
аудит, аналіз продуктивності, перевірку доступності та інтерактивні інструменти
для аналізу сторінки.
Цілі:
– провести аналіз існуючих інструментів та виявити їхні недоліки;
– сформувати функціональні та нефункціональні вимоги до розширення;
– спроектувати логічну архітектуру та модель предметної області;
– реалізувати основні модулі аналізу (технології, SEO, продуктивність,
доступність);
– забезпечити високу швидкодію, зручність використання та можливість
подальшого масштабування.
У розділі аналізу вимог були поставлені вимоги для програмного
забезпечення.
У розділі моделювання програмного забезпечення було описано архітектуру
програмного забезпечення.
У розділі аналізу якості були описані основні тест-кейси та стани системи
після проведення тестування.
У розділі впровадження та супроводу було описано процеси розгортання
програмного забезпечення.
Ключові слова: браузерне розширення, page analyzer, аналіз веб-ресурсів,
технологічний стек, SEO-аудит, CSS viewer, продуктивність веб-сторінки,
доступність, react, manifest v3, chrome extension.
ANNOTATIONS
Performer: Novak Vladyslav Oleksandrovych
The title of the work: «WEB resource quality assessment system».
Specialty: 121 Software engineering.
Educational institution: Cherkasy State Technological University, Cherkasy, 2025.
Goal: to develop a modern browser extension for comprehensive page analysis that
combines technology stack detection, SEO audit, performance analysis, accessibility
checking, and interactive tools for page analysis.
Objectives:
– to analyze existing tools and identify their shortcomings;
– to formulate functional and non-functional requirements for the extension;
– to design the logical architecture and domain model;
– to implement the main analysis modules (technologies, SEO, performance,
accessibility);
– to ensure high performance, usability, and the possibility of further scaling.
In the requirements analysis section, the requirements for the software were
defined.
In the software modeling section, the architecture of the software was described.
In the quality analysis section, the main test cases and the state of the system after
testing were described.
In the implementation and maintenance section, the processes of software
deployment were described.
Keywords: browser extension, page analyzer, WEB resource analysis, technology
stack, SEO audit, CSS viewer, WEB page performance, accessibility, react, manifest v3,
chrome extension.
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ І СКОРОЧЕНЬ ............................................. 6
ВСТУП .......................................................................................................................... 7
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВЯЗУВАННЯ
ПОСТАВЛЕНИХ ЗАДАЧ ......................................................................................... 10
1.1. Огляд сучасних підходів до аналізу та тестування WEB-ресурсів ............ 10
1.2. Огляд аналогів ................................................................................................. 10
1.2.1. Огляд розширення для виявлення використовуваних технологій
«Wappalyzer» ....................................................................................................... 10
1.2.2. Огляд інструменту для аудиту WEB-сторінок Google Lighthouse ........11
1.2.3. Огляд сервісу технологічного тестування «BuiltWith» ........................ 15
1.3. Постановка задачі ........................................................................................... 16
1.4. Опис технологій для розробки розширення ................................................. 17
ВИСНОВОКИ ДО ПЕРШОГО РОЗДІЛУ ........................................................... 20
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ .................................................................................................................... 21
2.1. Моделювання предметної області ................................................................. 21
2.1.1. Предметна область моделювання. Модель предметної області.
Словник предметної області .............................................................................. 22
2.1.2. Елементи моделювання предметної області .......................................... 24
2.1.3. Робоча область моделювання .................................................................. 25
2.2. Формування та аналіз вимог .......................................................................... 25
2.2.1. Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги. ................................................................................................................. 26
2.2.2. Формування вимог за діаграмою прецедентів ...................................... 28
2.3. Проектування логічної структури програмного комплексу ....................... 31
2.3.1. Діаграми класів ......................................................................................... 32
2.3.2. Діаграми пакетів ....................................................................................... 34
ЧДТУ 242253.014 ПЗ
Зм Арк. № докум. Підпис Дата
Розроб. Новак В.О. «Система оцінювання якості Літ. Арк. Акрушів
Перевір. Немов Р. Г 4 106
. WEB- ресурсів»
Реценз. Русалівський Б.В
Н. К онтр. Півень О.Б. Пояснювальна записка. ФІТІС, кафедра ПЗАС, ПЗ-2204
Затверд. Голуб С.В.
2.4. Архітектурне проектування ........................................................................... 36
2.4.1. Діаграма компонентів............................................................................... 36
2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма
розгортання. ........................................................................................................ 38
2.5. Моделювання поведінки системи ................................................................. 39
2.5.1. Діаграма діяльності .................................................................................. 39
2.5.2. Діаграма послідовності ............................................................................ 41
2.5.3. Діаграма комунікації ................................................................................ 43
2.5.4. Діаграма скінченного автомату ............................................................... 44
ВИСНОВОКИ ДО ДРУГОГО РОЗДІЛУ ................................................................. 45
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 46
3.1.1 Обґрунтування вибору засобів реалізації ............................................... 47
3.1.2 Опис структурної (функціональної) схеми ............................................. 48
3.1.3 Опис логічної схеми .................................................................................. 50
3.1.4 Розробка бази даних .................................................................................. 52
3.1.5 Розробка інтерфейсу користувача ............................................................ 52
3.1.6 Опис розробки програмних компонентів ............................................... 58
3.2 Тестування системи......................................................................................... 61
3.2.1 Модульне тестування ................................................................................ 61
3.2.2 Інтеграційне тестування ........................................................................... 64
3.2.3 Системне тестування ................................................................................ 65
3.2.4 Приймальне тестування ............................................................................ 67
3.3 Приклади впровадженого програмного комплексу ..................................... 69
ВИСНОВКИ ДО ТРЕТЬОГО РОЗДІЛУ .................................................................. 72
ВИСНОВКИ ............................................................................................................... 73
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ................................................................. 75
ДОДАТОК А .............................................................................................................. 82
ДОДАТОК Б ............................................................................................................... 84
ДОДАТОК В ............................................................................................................... 95
ДОДАТОК Г ............................................................................................................. 100
ЧДТУ 262253.014 ПЗ
Змн. Арк. № докум. Підпис Дата
ЧДТУ 26.2253.014 ПЗ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ І СКОРОЧЕНЬ
SEO (Search Engine Optimization) – оптимізація веб-сторінок для
пошукових систем з метою підвищення їх позицій у результатах
пошуку
CSS (Cascading Style Sheets) – каскадні таблиці стилів, мова опису
зовнішнього вигляду веб-документів.
DOM (Document Object Model) – об’єктна модель документа,
програмний інтерфейс для доступу та керування структурою
HTML- або XML-документа у браузері
WEB (World Wide Web) – всесвітня мережа, система взаємопов’язаних
гіпертекстових документів, доступних через мережу Інтернет.
WCAG (Web Content Accessibility Guidelines) – міжнародні настанови
щодо доступності веб-контенту, які визначають вимоги до
доступності сайтів для людей з інвалідністю.
ЛКМ Ліва кнопка миші
HTTPS (HyperText Transfer Protocol Secure) – безпечний протокол передачі
даних у мережі Інтернет, який використовує шифрування для
захисту інформації між браузером і сервером.
JS (JavaScript) – високорівнева, інтерпретована мова програмування,
що використовується для створення інтерактивних веб-сторінок і
браузерних розширень.
6
ЧДТУ 262253.014 ПЗ
ВСТУП
Актуальність теми зумовлена стрімким розвитком WEB-технологій,
зростанням складності WEB-ресурсів та постійним збільшенням вимог до
швидкості, якості та зручності їх аналізу [14]. На сьогоднішній день, WEB-
розробники та SEO-спеціалісти щодня стикаються з необхідністю швидкого та
комплексного аналізу WEB-сторінок. Однак більшість існуючих інструментів є
вузькоспеціалізовані та вимагають використання кількох різних сервісів одночасно,
в той час як на різних системах різні сервіси можуть бути недоступні. Це суттєво
уповільнює час на розробку, тестування та оптимізацію WEB-ресурсів.
Для оцінки якості WEB-ресурсів розробники традиційно використовують ряд
інструменті, наприклад: Wappalyzer для виявлення технологій [1], Google
Lighthouse для комплексного аудиту [2], Chrome DevTools для детального
дослідження DOM дерева та мережі, а також різноманітні онлайн-сервіси. Кожен із
вищеназваних інструментів чудово виконує свою вузьку задачу, проте має ряд
суттєвих обмежень. Більшість рішень є спеціалізованими та вузько направленими і
не дозволяють отримати повну картину стану WEB-ресурсу в одному місці.
Такі обмеження призводять до необхідності використовувати декілька або
більше різних інструментів одночасно, що значно уповільнює процес розробки,
тестування, оптимізації, дослідження конкурентів, аналогів, навчання тощо.
Відсутність єдиного універсального рішення, яке поєднувало б детекцію
технологій, SEO-аудит, аналіз продуктивності, перевірку доступності та
інтерактивні інструменти аналізу, типу переглядача CSS стилів або піпетки,
створює реальну проблему для нинішніх WEB-розробників.
У зв’язку з цим виникає об’єктивна потреба у створенні браузерного
розширення, яке б об’єднувало в собі найбільш затребувані функції аналізу веб-
сторінок і працювало безпосередньо в браузері. Таке розширення повинно
дозволяти користувачеві швидко отримувати повну технічну інформацію про будь-
яку відкриту сторінку, не перериваючи робочий процес і не переходячи між різними
сервісами.
Мета роботи – проектування та розробка браузерного розширення під
7
ЧДТУ 262253.014 ПЗ
назвою Page Analyzer, універсального інструменту для комплексного аналізу та
тестування WEB-ресурсів, який буде поєднувати в одному UI детекцію технологій,
SEO-аудит, оцінку продуктивності, перевірку доступності та інтерактивний ряд
інструментів для аналізу сторінкок.
Для досягнення поставленої мети потрібно вирішити наступні завдання:
– провести комплексний аналіз існуючих інструментів та розширень для
аналізу веб-ресурсів, виявити їх функціональні можливості, переваги та недоліки;
– визначити функціональні та нефункціональні вимоги до розроблюваного
розширення на основі виявлених проблем і потреб цільової аудиторії;
– дослідити та обґрунтувати вибір оптимального технологічного стеку для
реалізації браузерного розширення;
– спроектувати архітектуру розширення з урахуванням специфіки роботи
Chrome Extension API, розділення на popup, content scripts та background;
– реалізувати основні модулі: визначення технологій, SEO-аналіз, аналізу
продуктивності та перевірку доступності;
– забезпечити зручний, сучасний і інтуїтивно зрозумілий інтерфейс popup-
вікна з підтримкою швидкого перемикання між розділами;
– провести тестування функціональності розширення, перевірити його
стабільність та оптимізувати продуктивність.
Об’єкт розробки – процеси аналізу, тестування та оптимізації сучасних веб-
ресурсів у середовищі браузера, що включають виявлення використовуваного
WEB-сторінкою стеку технологій, SEO-аудит, оцінку швидкодії та стабільності
сторінки, перевірку її доступності відповідно до стандартів WCAG.
Методи проектування та конструювання включають – системний аналіз
існуючих рішень, об’єктно-орієнтоване та компонентне проектування архітектури
програмного забезпечення, використання сучасних веб-технологій для розробки UI,
технології створення браузерних розширень на базі Chrome Extension API (Manifest
V3) та фреймворку WXT та методи роботи з DOM-деревом.
Опис отриманих результатів – у ході виконання кваліфікаційної роботи
було створено повнофункціональне браузерне розширення під назвою Page
Analyzer для комплексного аналізу веб-ресурсів у реальному часі. Розширення
8
ЧДТУ 262253.014 ПЗ
включає п’ять основних модулів:
– модуль виявлення технологій з сортуванням по категоріях виявленого
стеку технологій сторінки;
– модуль SEO-аналізу, ціль якого, оцінка якості технічної оптимізації для
пошукових систем з подальшим формуванням оцінки та рекомендацій щодо
усунення виявлених недоліків або критичних помилок;
– модуль аналізу продуктивності WEB-сторінки, який здійснює моніторинг
швидкості завантаження сторінки та сторонніх ресурсів, на основі яких формує
оцінку та рекомендації щодо оптимізації;
– модуль перевірки доступності, що реалізує ряд тестів з перевіркою веб-
сторінки стандартам доступності WCAG [10] з формуванням оцінки та конкретних
порад щодо виправлення певних недоліків.
Додатково в розширенні присутній модуль CSS Viewer, який дозволяє
користувачеві при наведенні курсора на елемент сторінки отримувати всі обчислені
стилі.
Практичне значення отриманих результатів – полягає у створенні готового
до використання інструменту, який може застосовуватися WEB-розробниками та
SEO-спеціалістами для швидкого та всебічного аналізу будь-яких веб-ресурсів
безпосередньо в браузері. Розроблене розширення Page Analyzer дозволяє суттєво
скоротити час на аналіз сторінок, підвищити ефективність розробки та тестування,
а також полегшити процес дослідження конкурентів або використовуватися в
навчальних цілях. Крім того, розроблене рішення може служити основою для
подальшого розширення функціоналу та створення нових інструментів аналізу
WEB-ресурсів.
Особистий внесок автора – розроблено систему оцінювання якості WEB-
ресурсів, проведено аналіз існуючих аналогів, їх проблем та недоліків, виконано
програмну реалізацію, тестування та підготовку документації. Також
обґрунтований стек обраних технологій, спроектована архітектура розширення та
реалізація усіх функціональних модулів. Проведено повний цикл тестування та
оформлено результати згідно вимог до кваліфікаційних робіт бакалавра.
9
ЧДТУ 262253.014 ПЗ
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВЯЗУВАННЯ
ПОСТАВЛЕНИХ ЗАДАЧ
1.1. Огляд сучасних підходів до аналізу та тестування WEB-ресурсів
У сучасних умовах швидкого розвитку WEB-технологій та їх вимог,
ефективний аналіз та тестування таких ресурсів набуває більшої важливості. WEB-
розробники та SEO-спеціалісти щодня стикаються з такої необхідністю зручно та
швидко отримати повну технічну інформацію про WEB-сторінку. Це включає
визначення використовуваних технологій, оцінку пошукової оптимізації, аналіз
продуктивності, перевірку доступності та вивчення структури сторінки та стилів.
Для вирішення цих завдань на ринку існує ряд інструментів та сервісів. Серед
найбільш поширених можна виділити:
– Wappalyzer [1] – спеціалізоване розширення для виявлення
технологічного стеку веб-сторінок;
– Google Lighthouse [2] – потужний інструмент комплексного аудиту веб-
сторінок від компанії Google;
– Chrome DevTools – вбудований набір інструментів браузера Google
Chrome для глибокого аналізу DOM-структури, стилів, мережі та продуктивності;
– BuiltWith [3] – WEB-сервіс для технологічного сканування сайтів.
1.2. Огляд аналогів
Розширення для аналізу та тестуванню WEB-ресурсів є необхідним
інструментом в арсеналі кожного WEB-розробника для продуктивної роботи та
автоматизованої певної частини роботи, її пришвидшення та зменшення
ймовірності похибки.
1.2.1. Огляд розширення для виявлення використовуваних технологій
«Wappalyzer»
«Wappalyzer» – розширення для браузерів, яке виявляє технології, що
використовуються на WEB-сторінках, виявляє системи керування контентов,
платформи електронної комерції, WEB- сервери, фреймворки JavaScript [15],
аналітичні інструменти та багато інш.. Розширення може аналізувати наступну
10
ЧДТУ 262253.014 ПЗ
інформацію:
– виявлення систем керування контентом (wordpress, joomla, drupal, shopify
тощо);
– визначення javascript-фреймворків та бібліотек (react, vue, angular, jquery
та інш.);
– виявлення web-серверів (nginx, apache, cloudflare тощо);
– визначення платформ електронної комерції (woocommerce, magento,
shopify);
– виявлення інструментів аналітики (google analytics, facebook pixel, hotjar
тощо);
– визначення crm-систем (creatio, keycrm та інш.);
– визначати cdn, мови програмування та купу інших технологій.
Основними перевагами Wappalyzer є висока точність аналізу технологій та
величезну їх кількість, більше тисячі технологій. Зі своїм завданням розширення
справляється надзвичайно добре та наврядчи вийде перевершити результати його
аналізу, та проте, розширення вузькоспеціалізоване а приблизитись до результатів
реально.
Недоліком розширення є вузько направленість – воно лише визначає
технології, не проводить SEO-аудит, аналіз продуктивності чи доступності. Воно не
працює в реальному часі з окремими елементами сторінки і не надає рекомендацій
щодо покращення сайту.
В результаті маємо те, що Wappalyzer є найпотужнішим інструментом для
швидкого технологічного сканування, та проте не може замінити комплексний
аналіз WEB-ресурсів
1.2.2. Огляд інструменту для аудиту WEB-сторінок Google Lighthouse
Google Lighthouse – це потужний автоматизований інструмент аудиту веб-
сторінок, розроблений компанією Google. Він є одним із найпопулярніших і
найбільш всебічних інструментів для оцінки якості сучасних веб-сайтів. Lighthouse
доступний як у складі Chrome DevTools, так і у вигляді окремого браузерного
розширення для браузерів Chrome [2].
11
ЧДТУ 262253.014 ПЗ
Інструменти Lighthouse здатні проводити комплексний аудит сторінки по
п’яти окремим категоріям:
1 Performance (Продуктивність)
Розділ Performance є одним із найважливішим компонентів для аутиду
Lighthouse та не менш складним, в технічному сенсі, компонентом. В ньому
оцінюється швидкість та ефективність завантаження WEB-сторінки.
Lighthouse в цьому розділі вимірює продуктивність за допомогою 100 бальної
оцінки на основі певної кількості реальних метрик проведених на сайті.
Можна виділити такі метрики в розділі Performance які аналізує Lighthouse:
– First Contentful Paint (FCP) – час до першої появи контенту;
– Largest Contentful Paint (LCP) – час завантаження найбільшого видимого
елемента [8];
– Cumulative Layout Shift (CLS) – стабільність макету (зсув елементів під
час завантаження) [8];
– First Input Delay (FID) / Interaction to Next Paint (INP) – швидкість реакції
сторінки на дії користувача;
– Time to Interactive (TTI) – час до повної інтерактивності сторінки.
2 Accessibillity (Доступність)
В даному розділі перевіряється WEB-сторінка на відповідність по
міжнародним стандартам доступності WCAG (Web Content Accessibility
Guidelines).
Lighthouse сканує сторінку та оцінює її за 100 бальною шкалою. Фінальна
оцінка формується на основі проходження певної кількості автоматичних
перевірок, котрі можна розділити на певні ключові категорії:
2.1 Контрастність тексту на фоні
– перевіряється співвідношення контрастності між двома кольорами
фона та тексту;
– виявляє елементи з нижчою контрастністю ніж рекомендовано.
2.2 Семантична структура документа
– lighthouse аналізує сторінку на використання заголовків від <h1> –
<h6>;
12
ЧДТУ 262253.014 ПЗ
– перевіряє логіку ієрархії заголовків;
– перевіряє правильність та насамперед наявність використання тегів
<main>, <nav>, <aside>, <footer> тощо.
2.3 Мовні атрибути
– перевіряє на наявність такого атрибуту як lang у тегові <html>;
– виявляє сторінки, де не має вказаної мови документу.
2.4 Клавіатурна навігація та фокус
– перевіряє на можливість керування сторінки за допомогою
клавіатури;
– виявляє елементи, які не в змозі отримати фокус або отримують його
не в правильному порядку.
2.5 Доступність імен в інтерактивних елементах
– аналізує кнопки, посилання, чекбокси, поля, форми тощо;
– перевіряє на наявність в інтерактивних елементах зрозумілих та
доступних назв, які можуть бути прочитані скрінрідерами;
– виявляє елементи, які мають візуальний текст та не мають
доступного імені (наприклад, іконки без aria-label).
3 SEO (Пошукова оптимізація)
В розділі SEO розширення Lighthouse оцінює оптимізацію сторінки для
пошукових систем. Він перевіряє ряд технічних аспектів, які на пряму впливають
на індексацію сторінки та позиції сторінки у пошукових результатах.
Lighthouse аналізує сторінку за рядом певних автоматизованих правил та
формує фінальну оцінку по тієї ж 100 бальної шкалі на основі інших метрик. Аналіз
фокусується на технічній стороні SEO, а не контенті що знаходиться на ній.
Можна виділити ряд наступних перевірок які виконує Lighthouse у розділі
SEO:
3.1 Мета-теги та заголовки
– перевіряється наявність тегу <title> та його довжина;
– аналізує мета-тег як description – його наявність та довжину;
– перевіряє наявність ключових слів у description та заголовку.
3.2 Мобільна адаптація
13
ЧДТУ 262253.014 ПЗ
– перевіряє коректність відображення сторінки на мобільних
пристроях;
– аналізує viewport meta tag (<meta name="viewport">).
3.3 Структура даних
– перевіряє наявність розмітки schema.org та її правильність (json-ld,
microdata, rdfa);
– виявляє помилки у структурованих даних (наприклад, для article,
product, faq, organization тощо);
– перевіряє правильність розмітка згідно стандартам та рекомендаціям
від google.
3.4 SEO-фактори на технічній стороні
– перевіряється наявність та правильність атрибута robots, meta robots
та “robots.txt”;
– наявність канонічного посилання (<link rel="canonical">);
– перевірка наявність https;
– аналізує hreflang-атрибути для багатосторінкових сайтів;
– перевіряється наявності sitemap.xml.
Основними перевагами Google Lighthouse можна виділити:
– глибокий і детальний аналіз, особливо в розділах performance та
accessibility;
– використання офіційних метрик core web vitals;
– конкретні рекомендації щодо покращення;
– можливість генерувати звіти у форматі html, json та markdown;
– інтеграція з ci/cd.
В інструменті Google Lighthouse можна виділити наступні недоліки:
– слабко аналізує технологічний стек сайту;
– результати значною мірою залежать від умов тестування (мережа,
пристрій);
– обмежена робота в браузерах, відмінних від chrome;
– багато перевірок в accessible вимагають ручного підтвердження та
перевірок;
14
ЧДТУ 262253.014 ПЗ
– не аналізує складні віджети, наприклад, кастомні модальні вікна,
слайдери, dropdowns;
– ігнорує ряд перевірок в розділі SEO, що вимагає ручного
тестування.
В результаті, можна сказати, що Google Lighthouse добре справляється з
базовим SEO-аудитом та є корисний для швидкої перевірки швидкості та
структурованих даних.
1.2.3. Огляд сервісу технологічного тестування «BuiltWith»
BuiltWith – онлайн-сервіс для глибокого технологічного аналізу WEB-сайтів.
На відміну від браузерних розширень, BuiltWith працює на основі серверного
сканування і може аналізувати не тільки виділену сторінку, а й весь сайт загалом.
Сервіс виявляє широкий спектр технологій, таких як frontend, backend
рішення, CMS, фреймворки, інструменти аналітики, хостинг, CDN тощо. Однією з
унікальних сторін сервісу є можливість перегляду як технологічний стек WEB-
ресурсу змінювався з часом. [3]
Сервіс може аналізувати та виявляти наступну інформацію:
– frontend-технології (фреймворки, бібліотеки, UI-компоненти);
– backend-технології (мови програмування, фреймворки);
– системи керування контентом (CMS) – wordpress, shopify, drupal, joomla та
інші;
– платформи електронної комерції (woocommerce, magento, bigcommerce
тощо);
– інструменти веб-аналітики та маркетингу (google analytics, facebook pixel,
hotjar, google tag manager та ін.);
– хостинг-провайдерів і платформи (aws, cloudflare, heroku, vercel тощо);
– CDN (content delivery network);
– використання API сторонніх сервісів;
– SSL-сертифікати, технології безпеки та багато інших компонентів.
Можна виділити наступні переваги BuiltWith:
– дуже глибоке і детальне сканування технологій;
– можливість аналізувати весь сайт, а не тільки конкретно відкриту
15
ЧДТУ 262253.014 ПЗ
сторінку;
– можливість перегляду з часом зміни в технологічному стеку сторінки.
– зручний експорт результатів у різних форматах (csv, pdf тощо).
– BuiltWith має ряд наступних недоліків:
– працює виключно як онлайн-сервіс, а не як браузерне розширення;
– не надає інформацію в реальному часі під час перегляду сторінки
користувачем;
– більшість розширених функцій доступні тільки за платною підпискою;
– відсутні інтерактивні інструменти, такі як перегляд CSS-стилів елементів
або аналіз продуктивності в реальному часі.
В результаті, BuiltWith є потужним інструментів для детального дослідження
технологічного стеку та глибокого технологічного аналізу, проте через відсутність
інтеграції в браузер і платну модель, він є менш зручний для щоденної роботи та є
недоступним для ряду користувачів через платну модель.
1.3. Постановка задачі
Метою кваліфікаційної роботи є створення універсального інструменту для
надання можливості зручного та швидкого аналізу та тестуванню WEB-ресурсів
розробниками в наступних категоріях:
– SEO, де розробник швидко може проаналізувати зібрану розширенням
інформацію, таку як довжину «Title», кількість слів на сторінці, «Meta Description»,
наявність HTTPS та мобільного «viewport» та прочитати рекомендації по
покращенню SEO сторінки;
– детектор технологій, де розробник може проаналізувати всі
використовувані сторінкой технології, які зібрало розширення, такі як бібліотеки,
фреймворки, безпеку тощо;
– продуктивність, де у розробника є можливість отримати та проаналізувати
всі повільні ресурси, сторонні скрипти, великі JS-файли та відповідно переглянути
кожен з них. В розділі будуть доступні метрики таких показників як, час
завантаження сторінки, FCP – час від початку завантаження сторінки до появи
першого контенту (текст, зображення тощо), LCP – час до появи найбільшого
16
ЧДТУ 262253.014 ПЗ
видимого елемента на сторінці, сумарний зсув елементів під час завантаження, CLS
– сумарний зсув елементів під час завантаження та переглянути рекомендації щодо
покращення результатів;
– доступність, де у розробника є можливість переглянути кількість
зображень без тегу «alt», кількість інтерактивних елементів без імені, наявність
атрибуту lang в блоці «html» та отримати рекомендації згідно стандартам WCAG
2.2.
Для вирішення наступних цілей, потрібно виконати наступні кроки:
1 провести комплексний аналіз подібних розширень, яку мають подібний
функціонал, їх принципи роботи та особливості;
2 дослідити стек технологій, що використовуються в подібних аналогах, для
можливого використання їх особливостей в моєму розширенні;
3 реалізувати раніше поставлені задачі з урахуванням всіх знайдених
аналогів та їх особливостей;
4 провести тестування кожного елементу створеного програмного
забезпечення та оптимізувати його роботу;
1.4. Опис технологій для розробки розширення
Chrome Extension API (Manifest V3) виступає базовою технологією для
створення любих сучасних розширень для браузера Google Chrome. Manifest V3 є
актуальною версією маніфесту, що надає вищий рівень безпеки, кращу
продуктивність та нові можливості для роботи з розширеннями. Chrome Extension
API дасть доступ до ключових функцій управління вкладками, виконання скриптів
на сторінці користувача, обміну повідомленнями між різними модулями
розширення та доступ до local storage. Він є основою нашого розширення, без якого
неможливо створити додаток.
React + TypeScript обрано як основний фреймворк для розробки UI popup
вікна. Додатки на React [11] мають компонентну архітектуру, ефективну роботу зі
станами та велику екосистему. Він дозволить скласти складний, але
структурований та взаємопов’язаний інтерфейс з різними модулями розширення.
TypeScript додає статичну типізацію, якої дуже не хватає звичайному JavaScript, та
17
ЧДТУ 262253.014 ПЗ
є критичним при розробці розширення або будь якого великого додатку. Щоб
уникнути ряду помилок, наприклад під час обміну станів або даних, додаток
повинен мати строгу типізацію з чітким контролем типів. Використання TypeScript
в підвищить надійність коду, полегшить майбутній рефакторинг коду та значно
полегшить майбутню підтримку розширення.
Tailwind CSS [9], фреймворк, був обраний для стилізації інтерфейсу. Він
дозволить швидко створити простий, адаптивний та послідовний дизайн без
необхідності написання здоровенних CSS правил. Tailwind забезпечить повний
контроль над зовнішнім виглядом та значно прискорить процес верстки нашого UI.
Використання Tailwind виправдане в умовах обмеженого простору popup вікна, де
є важлива кожна деталь оформлення, та заощадить час на написанню стилів.
WXT фреймворк [7], спеціалізований на розробці браузерних розширень,
який значно спрощує процес створення, налаштування та білда розширення на
відміну від класичного підходу. Фреймворк WXT підтримує Manifest V3 [5] та
автоматично обробляє його конфігурацію, підтримує гаряче оновлення під час
розробки. З WXT зручно працювати з content scripts і background service workers.
Використання цього фреймворку дозволить суттєво заощадити час на рутинному
налаштуванні проекту та дозволить зосередитись на реалізації іншого функціоналу.
Для забезпечення зручної організації розробки використовувалися наступні
інструменти:
– Visual Studio Code (VS Code) – легке, але дуже потужне середовище
розробки з доступним широким спектром розширень, підтримкою підсвітки
синтаксису, автодоповненням та зручним терміналом.
– Git та GitHub – системи контролю версій (VCS), що дають змогу керувати
проектом, зберігати його версії в історію та керувати нею. Створювати в ній окремі
гілки для реалізацію певних функцій та поводити командну роботу
– UML-діаграми – для моделювання структури системи, включаючи
діаграми варіантів використання, класів і діяльності.
Обраний та вищеописаний стек технологій забезпечить оптимальний баланс
між продуктивністю, швидкістю як розробки так і додатку, зручний та
довготривалий супровід розширення. React [11] у поєднанні з Typescript надасть
18
ЧДТУ 262253.014 ПЗ
доступ до створення масштабованої та надійної кодової бази, що є особливо
важливим при роботі зі складною архітектурою коду. WXT прискорить процес
розробки а спростить роботу з Chrome Extension API [5]. Tailwind CSS дасть
можливість для швидкого створення сучасного інтерфейсу а Content Scripts є
обов’язковим для взаємодії з реальним DOM деревом сторінки.
Відмова від таких альтернатив як Vue або Svelte на користь React пояснюється
його широкою екосистемою, великою кількістю готовим рішень та довготривалою
підтримкою зі сторони Meta. Відмова від TypeScript є недоцільною через високу
ймовірність помилок, та перекриває великий недолік JavsScript – його типізацію.
19
ЧДТУ 262253.014 ПЗ
ВИСНОВОКИ ДО ПЕРШОГО РОЗДІЛУ
Був проведений комплексний аналіз сучасного стану ринку розширень для
розробки інструментів для аналізу та тестуванню WEB-ресурсів, в якому вдалося
виявити ключові проблеми та недоліки існуючих рішень, сформульована мета і
завдання дослідження, обґрунтований вибір усіх технологій сформованого стеку
для реалізації розширення.
Аналіз ринку показав, що в нинішніх реаліях не існує єдиного універсального
інструменту, який би поєднував комплексний аналіз WEB-сторінки в реальному
часі з рядом інструментів для її аналізу. Існуючі аналоги, такі як Wappalyzer, Google
Lighthouse, BuiltWith та Chrome DevTools добре вирішують окремі задачі, але мають
свої недоліки. Wappalyzer обмежується лише визначенням технологій, Lighthouse
проводить глибокий аудит лише після явного запуску, а DevTools вимагає значних
технічних знань і не має єдиного зручного інтерфейсу. Жоден із розглянутих
інструментів не пропонує інтерактивних інструментів для аналізу сторінки окрім
DevTools, та як описувалося раніше, потребує технічних знань та не має єдиного
Для реалізації постановленої задачі був обраний наступний стек технологій:
Chrome Extension API (Manifest V3), React + TypeScript, Tailwind CSS, WXT та
Content Scripts. Такий вибір обґрунтований необхідністю забезпечити високу
швидкість, надійність коду, зручність розробки та можливість подальшого
масштабування проекту.
20
ЧДТУ 262253.014 ПЗ
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ
Моделювання предметної області – це процес створення абстрактного
представлення спроектованої системи для кращого розуміння складних систем,
прийняття обґрунтованих рішень та покращення функціональності. Цей етап є
ключовим у створенні програмного продукту.
У цьому розділі розглядаються питання моделювання предметної області
розширення Page Analyzer, проектування його архітектури, розробки основних
компонентів та впровадження результатів у практику створення розширення.
2.1. Моделювання предметної області
Моделювання предметної області є дуже важливим етапом при розробці будь-
якого програмного продукту. Воно дозволяє глибше зрозуміти сферу, для якої
створюється продукт, визначити ключові об’єкти, процеси, взаємозв’язки між ними
та закласти основу для майбутнього проектування архітектури та реалізації
функціоналу.
Предметна область розробки розширення Page Analyzer пов’язана з аналізом
і тестуванням сучасних веб-ресурсів безпосередньо в браузерному середовищі.
Основне завдання цього етапу полягало в тому, щоб чітко описати, які елементи і
процеси беруть участь у роботі розширення, як вони взаємодіють між собою та яку
інформацію система повинна збирати, обробляти та відображати користувачеві.
Користувач відкриває будь-яку веб-сторінку в браузері і активує розширення.
Після цього система автоматично збирає технічну інформацію про сторінку.
Користувач може переглянути детальний список технологій, які використовуються
на сайті, отримати оцінку SEO з рекомендаціями щодо покращення, проаналізувати
швидкість завантаження сторінки, виявити проблеми доступності, а також у
реальному часі вивчати і копіювати CSS-стилі будь-якого елемента сторінки.
Ключові компоненти предметної області:
– користувач – WEB-розробник або SEO-спеціаліст, який використовує
21
ЧДТУ 262253.014 ПЗ
розширення для аналізу веб-сторінок;
– веб-сторінка – основний об’єкт аналізу, який містить DOM-структуру,
стилі, технології, мета-дані та інші технічні характеристики;
– технологічний стек – набір технологій, фреймворків, бібліотек і сервісів,
що застосовуються на сторінці;
– результати аналізу – вся інформація, отримана після сканування сторінки
(список технологій, SEO-метрики, показники продуктивності, проблеми
доступності тощо);
– CSS-елемент – окремий елемент веб-сторінки, стилі якого можна
детально вивчати, фіксувати та копіювати в реальному часі;
2.1.1. Предметна область моделювання. Модель предметної області. Словник
предметної області
Предметна область моделювання розширення Page Analyzer охоплює всі
процеси, пов’язані з аналізом і тестуванням веб-сторінок у браузерному
середовищі. Вона включає збір технічної інформації, способи її обробки,
візуалізації та інтерактивної взаємодії користувача з даними.
Основна увага приділяється тому, як користувач працює з веб-сторінкою:
відкриває її в браузері, отримує дані про технології, перевіряє SEO-параметри,
аналізує швидкість завантаження, оцінює доступність і детально вивчає стилі
окремих елементів. Уся забрана інформація повинна бути зібрана, оброблена і
представлена користувачеві зручно, щоб той міг її швидко проаналізувати.
Модель предметної області. Модель відображає логічну структуру
розширення. Центральним об’єктом є веб-сторінка, з якою безпосередньо взаємодіє
користувач. Розширення аналізує цю сторінку за кількома напрямками:
технологічний стек, SEO-параметри, показники продуктивності та доступність.
Окремим важливим елементом є можливість інтерактивної роботи з CSS-стилями
будь-якого елемента сторінки в реальному часі.
Усі зібрані дані можуть об’єднуватися в звіт, який користувач може
переглядати в інтерфейсі розширення. Така модель показує, як різні частини
системи пов’язані між собою.
22
ЧДТУ 262253.014 ПЗ
Для чіткого розуміння термінів, які використовуються в предметній області,
було складено словник предметної області (див. табл. 2.1), де описані доменні
об’єкти.
Словник предметної області розглянемо у вигляді таблиці 2.1
Таблиця 2.1
Словник предметної області
№ Назва (укр.) Назва (англ.) Опис
1 Користувач User Веб-розробник, SEO-спеціаліст або веб-
майстер, який використовує розширення
для аналізу веб-сторінок
2 Веб-сторінка Web Page Будь-яка відкрита в браузері сторінка, що
є основним об’єктом аналізу
3 Технологічний Technology Сукупність технологій, фреймворків,
стек Stack бібліотек та сервісів, що
використовуються на сторінці.
4 Результати Analysis Results Дані, отримані після сканування сторінки
аналізу (технології, SEO-показники, метрики
продуктивності, проблеми доступності)
5 CSS-елемент CSS Element Окремий елемент веб-сторінки, стилі
якого можна переглядати, фіксувати і
копіювати в реальному часі
6 Звіт Report Узагальнена інформація про стан веб-
ресурсу, яку формує і відображає
розширення
7 SEO- SEO Parameters Мета-теги, заголовки, viewport, robots та
параметри інші фактори пошукової оптимізації
8 Показники Performance Метрики швидкості завантаження
продуктивності Metrics сторінки (FCP, LCP, CLS, INP та інші)
23
ЧДТУ 262253.014 ПЗ
2.1.2. Елементи моделювання предметної області
Моделювання предметної області є важливим етапом розробки програмного
продукту. Воно дозволяє структурувати всі знання про систему, чітко визначити її
основні елементи та їх взаємодію.
На цьому етапі основна увага приділяється логіці системи та її функціоналу,
без глибокого занурення в технічні деталі реалізації. Це дає можливість створити
надійну концептуальну основу для подальшого проектування архітектури
розширення.
Після визначення ключових компонентів предметної області важливо
детальніше розглянути основні елементи, які беруть участь у роботі розширення
Page Analyzer, їхні властивості та взаємозв’язки. Це дозволяє краще зрозуміти, як
саме працює система, і підготувати ґрунт для подальшого проектування
архітектури та бази даних.
Рисунок 2.1 – Основні графічні символи UML
24
ЧДТУ 262253.014 ПЗ
Складовими моделі предметної області є сутності (об’єкти), їхні
характеристики (атрибути), взаємозв’язки між ними, а також правила та обмеження,
що описують роботу розширення (див. рисунок 2.1).
2.1.3. Робоча область моделювання
Робоча область моделювання визначає реальне середовище, в якому
працюватиме розширення Page Analyzer. На відміну від абстрактної моделі
предметної області, тут розглядається, як саме користувач взаємодіє з розширенням
під час щоденної роботи, які екрани і інструменти він бачить, і як відбувається весь
процес аналізу веб-сторінки від початку до кінця.
Робоча область розширення охоплює весь цикл роботи з веб-ресурсом у
браузері. Користувач відкриває будь-яку сторінку, активує розширення через іконку
в панелі браузера і відразу отримує доступ до всіх інструментів аналізу в зручному
popup-вікні.
Основний сценарій використання виглядає наступним чином: користувач
переглядає веб-сторінку і хоче швидко отримати технічну інформацію про неї. Він
відкриває розширення і бачить головне меню з розділами: «Технології», «SEO»,
«Продуктивність», «Доступність» та «CSS Viewer».
У розділі «Технології» відображається повний список виявлених технологій,
згрупованих за категоріями. У розділі «SEO» користувач бачить оцінку, ключові
мета-теги, рекомендації щодо покращення та можливі проблеми. У розділі
«Продуктивність» показуються основні метрики, список повільних ресурсів,
сторонніх скриптів і великих JS-файлів. Розділ «Доступність» інформує про
кількість зображень без alt-тексту, інтерактивних елементів без доступного імені та
інші проблеми.
Таким чином, робоча область моделювання охоплює повний цикл взаємодії
користувача з розширенням: від відкриття веб-сторінки до отримання детального
звіту та роботи з окремими елементами сторінки. Уся інформація подається в
зручному, структурованому вигляді, що дозволяє користувачеві швидко аналізувати
веб-ресурс без необхідності використовувати декілька різних інструментів.
2.2. Формування та аналіз вимог
25
ЧДТУ 262253.014 ПЗ
У цьому розділі описаний ряд вимог, які необхідно визначити для розробки
розширення Page Analyzer. Вимоги формуються на основі аналізу існуючих
аналогів, виявлених недоліків цих рішень, а також реальних потреб цільової
аудиторії – веб-розробників, фронтендерів та SEO-спеціалістів.
2.2.1. Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги.
Формування вимог до програмного забезпечення є важливим етапом, який
визначає всі необхідні функції та характеристики розширення Page Analyzer. Цей
процес включає первинне визначення основних можливостей системи, та
деталізацію кожної функції для її практичної реалізації.
Первинні вимоги описують загальні можливості розширення:
– комплексний аналіз веб-сторінки в реальному часі безпосередньо в
браузері;
– поєднання кількох видів аналізу (технології, SEO, продуктивність,
доступність) в одному інструменті;
– інтерактивний перегляд і робота зі стилями елементів сторінки;
– зручний і сучасний інтерфейс, який не заважає основній роботі
користувача;
– швидке отримання результатів без необхідності використовувати кілька
окремих сервісів.
Детальні вимоги уточнюють первинні та забезпечують конкретні інструкції
для розробки. Вони включають вимоги замовника і розробника, а також
функціональні та нефункціональні вимоги.
Вимоги замовника:
– сучасний і інтуїтивно зрозумілий інтерфейс popup-вікна;
– швидке отримання повної технічної інформації про будь-яку відкриту веб-
сторінку;
– аналіз SEO-параметрів з рекомендаціями щодо покращення;
– оцінку продуктивності сторінки з виявленням проблемних ресурсів;
26
ЧДТУ 262253.014 ПЗ
– перевірку базової доступності сторінки;
– інтерактивний інструмент для перегляду, фіксації та копіювання CSS-
стилів елементів;
– мінімальну кількість дій для отримання результату.
Вимоги розробника:
– стабільна робота з сучасними односторінковими додатками (SPA);
– швидке сканування сторінки без помітного уповільнення браузера;
– можливість роботи з динамічно генерованим контентом;
– збереження стану розширення між сесіями;
– можливість подальшого масштабування функціоналу;
– дотримання всіх вимог безпеки Chrome Extension (Manifest V3).
Функціональні вимоги визначають конкретні можливості, які повинна
надавати система:
1 Модуль аналізу технологій
– автоматичне виявлення та категоризація технологій веб-сторінки;
– групування технологій за категоріями (фреймворки, CMS, бібліотеки,
аналітика, хостинг тощо);
– відображення назви технології, категорії та версії (за можливості);
– зручне візуальне представлення результатів у вигляді списку з
іконками.
2 Модуль SEO-аналізу
– аналіз основних мета-тегів (title, meta description, robots, viewport);
– перевірка наявності та коректності канонічного посилання;
– аналіз структури заголовків (–);
– перевірка використання HTTPS;
– базовий аналіз наявності schema-розмітки;
– формування рекомендацій щодо покращення SEO.
3 Модуль аналізу продуктивності
– виявлення повільних ресурсів (зображення, JS-файли, CSS);
– підрахунок кількості сторонніх скриптів;
– виявлення великих JavaScript-файлів;
27
ЧДТУ 262253.014 ПЗ
– базова оцінка основних метрик Core Web Vitals;
– відображення загального часу завантаження сторінки.
4 Модуль перевірки доступності
– підрахунок зображень без атрибута alt;
– виявлення інтерактивних елементів без доступного імені;
– перевірка наявності атрибута lang у тегу <html>;
– формування рекомендацій згідно стандартів WCAG.
5 Модуль CSS Viewer
– миттєвий перегляд обчислених стилів елемента при наведенні
курсора;
– фіксація стилів конкретного елемента (Ctrl + ЛКМ);
– копіювання окремих CSS-властивостей;
– копіювання всіх стилів елемента одним кліком;
– завантаження стилів елемента у вигляді .css-файлу.
Нефункціональні вимоги описують якісні характеристики системи:
– висока швидкодія і мінімальне споживання ресурсів браузера;
– стабільна робота з динамічними веб-додатками (SPA);
– інтуїтивно зрозумілий і сучасний інтерфейс з підтримкою темної теми;
– можливість подальшого розширення функціоналу;
– дотримання всіх вимог безпеки браузерних розширень.
Таке розмежування вимог дозволяє чітко зрозуміти межі проекту, забезпечити
його відповідність реальним потребам користувачів і закласти правильну основу
для подальшого проектування архітектури розширення.
2.2.2. Формування вимог за діаграмою прецедентів
Опис прецедентів
Основні прецеденти, що відображають функціональні можливості
розширення Page Analyzer, можуть бути такими (рисунок 2.2).
1 Прецедент «Запустити аналіз сторінки»:
– призначення: запуск комплексного аналізу поточної веб-сторінки;
– основний потік подій: користувач відкриває popup-вікно розширення і
28
ЧДТУ 262253.014 ПЗ
натискає кнопку «Аналізувати сторінку» (або «Оновити аналіз»).
Розширення надсилає повідомлення content script, який виконує аналіз
і повертає результати. Після успішного завершення аналізу результати
відображаються у popup-вікні;
– альтернативний потік подій: якщо сторінка ще не повністю
завантажена, система виводить повідомлення «Зачекайте, сторінка
завантажується»;
– передумова: користувач знаходиться на будь-якій веб-сторінці в
браузері;
– виняткова ситуація 1: відсутній зв’язок з content script – система
виводить повідомлення про помилку.
2 Прецедент «Переглянути результати аналізу технологій»:
– призначення: перегляд списку всіх виявлених технологій на сторінці;
– основний потік подій: користувач у popup-вікні обирає розділ
«Технології». Система відображає згруповані за категоріями
технології з назвою, версією та іконкою;
– альтернативний потік подій: якщо технологій не виявлено,
відображається повідомлення «Технологій не знайдено»;
– передумова: попередньо виконано аналіз сторінки;
– виняткова ситуація 1: помилка під час отримання даних – система
пропонує оновити аналіз.
3 Прецедент «Виконати SEO-аналіз»:
– призначення: отримання оцінки SEO-параметрів сторінки та
рекомендацій;
– основний потік подій: користувач переходить у розділ «SEO». Система
відображає оцінку, деталі мета-тегів, заголовків, рекомендації щодо
покращення;
– альтернативний потік подій: якщо деякі параметри відсутні, вони
виділяються червоним кольором;
– передумова: попередньо виконано аналіз сторінки;
– виняткова ситуація 1: сторінка не містить жодних SEO-параметрів –
29
ЧДТУ 262253.014 ПЗ
система виводить відповідне повідомлення.
4 Прецедент «Проаналізувати продуктивність»:
– призначення: оцінка швидкості завантаження сторінки та виявлення
проблем;
– основний потік подій: користувач відкриває розділ «Продуктивність».
Система показує оцінку, Core Web Vitals, список повільних ресурсів і
рекомендації;
– передумова: попередньо виконано аналіз сторінки;
– виняткова ситуація 1: сторінка завантажується занадто довго – система
пропонує оновити аналіз.
5 Прецедент «Перевірити доступність»:
– призначення: перевірка базових параметрів доступності сторінки;
– основний потік подій: користувач переходить у розділ «Доступність».
Система відображає кількість проблем (зображення без alt, елементи
без назви тощо) та рекомендації;
– передумова: попередньо виконано аналіз сторінки.
6 Прецедент «Використовувати CSS Viewer»:
– призначення: інтерактивний перегляд і робота зі стилями елементів
сторінки;
– основний потік подій: користувач вмикає перемикач CSS Viewer. При
наведенні курсора на елемент праворуч з’являється панель зі стилями.
За допомогою Ctrl + ЛКМ стилі елемента фіксуються. Користувач
може копіювати окремі властивості або завантажити весь блок стилів
як .css-файл;
– альтернативний потік подій: якщо перемикач вимкнено, панель не
з’являється;
– передумова: розширення активне і користувач знаходиться на веб-
сторінці;
– виняткова ситуація 1: елемент не має обчислених стилів – система
виводить повідомлення.
30
ЧДТУ 262253.014 ПЗ
Рисунок 2.2 – Діаграма прецедентів
2.3. Проектування логічної структури програмного комплексу
У цьому підрозділі буде детально розглянуто проектування логічної
структури розширення Page Analyzer для аналізу та тестування веб-ресурсів.
Основна мета полягає в тому, щоб чітко визначити ключові об’єкти системи, їхні
атрибути, методи та взаємозв’язки між ними. Для візуалізації логічної структури
було побудовано діаграму класів, яка відображає основні сутності розширення та
їхні властивості. Це дозволяє краще зрозуміти внутрішню організацію даних і
логіку роботи окремих модулів аналізу.
Кожен клас відповідає за певну функціональність системи, таку як зберігання
результатів аналізу, опис технологій, SEO-параметрів, метрик продуктивності,
даних доступності та роботи з CSS-елементами. Далі ми розглянемо взаємозв’язки
між класами, що визначають, як різні компоненти системи працюють разом і
забезпечують комплексний аналіз веб-сторінки в реальному часі. Така структура
дає змогу створити чітке уявлення про поведінку об’єктів у системі, а також значно
31
ЧДТУ 262253.014 ПЗ
спрощує подальшу розробку, тестування та інтеграцію нових функціональних
можливостей.
У цій роботі ми розробляємо логічну структуру програмного пакету,
використовуючи діаграму класів та діаграму пакетів для візуалізації структури та
компонентів системи. Це допомагає забезпечити чіткість архітектури коду та
полегшує розуміння того, як окремі частини розширення взаємодіють між собою.
2.3.1. Діаграми класів
Діаграма класів допомагає візуалізувати структуру системи, показуючи
класи, їхні атрибути, методи і відносини між ними. Вона є основним інструментом
для розуміння того, як організовані дані в розширенні та як вони передаються між
popup-вікном і content script.
Для розширення Page Analyzer було розроблено діаграму класів, яка
відображає ключові сутності та їх взаємодію (див. рисунок 2.3).
Рисунок 2.3 – Діаграма класів без атрибутів
Основні класи системи:
– AnalysisResult – центральний клас, який агрегує результати всього аналізу
веб-сторінки.
– WebPage – клас, що представляє аналізованої веб-сторінку.
– Technology – описує одну виявлену технологію або сервіс.
32
ЧДТУ 262253.014 ПЗ
– SeoResult – зберігає результати SEO-аналізу сторінки.
– PerformanceResult – зберігає результати аналізу продуктивності.
– AccessibilityResult – зберігає результати перевірки доступності.
– CSSElement – використовується модулем CSS Viewer для роботи зі
стилями елементів.
– Report – клас, відповідальний за генерацію PDF-звіту.
Розглянемо детальніше логіку створення діаграми класів з атрибутами (див.
рисунок 2.4)
Рисунок 2.4 – Діаграма класів з атрибутами
Опис основних класів з атрибутами:
– AnalysisResult – головний клас-агрегатор. Містить усі результати аналізу
та передається між компонентами розширення;
– поля: url, title, timestamp, technologies, seo, performance, accessibility;
– WebPage – представляє саму веб-сторінку, яку аналізує розширення;
– поля: url, title, domStructure;
– Technology – описує виявлену технологію (фреймворк, бібліотеку, CMS
тощо);
33
ЧДТУ 262253.014 ПЗ
– поля: name, version, category, confidence;
– SeoResult – зберігає результати SEO-аудиту;
– поля: score, metaDescription, titleLength, metaDescLength, hasRobotsMeta,
isHttps;
– PerformanceResult – містить метрики продуктивності та Core Web Vitals;
– поля: score, fcp, lcp, cls, loadTime, slowResources тощо;
– AccessibilityResult – результати перевірки доступності;
– поля: score, imagesWithoutAlt, withoutAccessibleName;
– CSSElement – використовується в модулі CSS Viewer;
– поля: selector, computedStyles, методи: fixElement(), copyStyles(),
downloadCSS();
– report – відповідає за створення PDF-звіту;
– метод: generateReport();
– діаграма також відображає основні зв’язки між класами: композицію
(WebPage → AnalysisResult), агрегацію (AnalysisResult → Technology,
SeoResult тощо) та залежності;
– загальна структура системи побудована навколо класу AnalysisResult,
який є ключовим для передачі даних між content script та popup-
інтерфейсом.
2.3.2. Діаграми пакетів
Діаграма пакетів показує, як класи логічно організовані в окремі модулі
(пакети). Це допомагає зрозуміти архітектуру розширення та розподіл
відповідальності між його частинами.
Опис основних пакетів (див. рисунок 2.5):
– popup – відповідає за інтерфейс користувача розширення;
– містить усі react-компоненти, секції аналізу, меню та управління станом;
– content script – працює безпосередньо в контексті веб-сторінки;
– виконує реальний аналіз dom, обчислення стилів, виявлення технологій та
роботу css viewer;
– chrome extension api – пакет інтеграції з браузерними api;
34
ЧДТУ 262253.014 ПЗ
– забезпечує взаємодію з вкладками та повідомленнями.
Рисунок 2.5 – Діаграма пакетів
35
ЧДТУ 262253.014 ПЗ
Взаємодія між пакетами відбувається наступним чином: Popup надсилає
команди до Content Script, Content Script виконує аналіз і повертає результати. Пакет
Chrome Extension API забезпечує комунікацію та збереження налаштувань між
сесіями.
2.4. Архітектурне проектування
2.4.1. Діаграма компонентів
У цьому підрозділі розглядається архітектурне проектування розширення
Page Analyzer. Метою є показати, як система розділена на окремі компоненти та як
вони взаємодіють між собою. Для цього була побудована діаграма компонентів, яка
відображає логічний розподіл функціональності між частинами розширення
(рисунок 2.6).
Основні компоненти:
1 Клієнтський застосунок (Client / Popup)
Опис: Компонент, який забезпечує взаємодію з користувачем у popup-вікні
розширення. Його функції включають показ результатів аналізу, управління
перемикачем CSS Viewer, навігацію між розділами та відображення рекомендацій.
Підкомпоненти:
– UI (інтерфейс користувача);
– MenuView та FeatureButton;
– TechSection, SeoSection, PerfSection, AccessibilitySection,
OverallDashboard;
– CssViewerPanel.
2 Content Script
Опис: Компонент, який виконується безпосередньо в контексті відкритої веб-
сторінки. Він відповідає за реальний аналіз DOM, обчислення стилів, виявлення
технологій та роботу інтерактивного модуля CSS Viewer.
Підкомпоненти:
– Analyzers (TechnologyDetector, SeoAnalyzer, PerformanceAnalyzer,
AccessibilityAnalyzer);
– CssViewerManager;
36
ЧДТУ 262253.014 ПЗ
– Event listeners (mouseover, click, Ctrl + click).
Рисунок 2.6 – Діаграма компонентів
37
ЧДТУ 262253.014 ПЗ
2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма
розгортання.
Розгортання програмної системи на апаратних засобах для розширення Page
Analyzerмає суттєві особливості порівняно з традиційними веб-додатками.
Оскільки це браузерне розширення, вся система розгортається безпосередньо в
середовищі браузера користувача і не потребує окремого сервера чи бази даних.
Опис розгортання програмної системи на апаратних засобах (рисунок 2.7):
1 Клієнт (Browser)
Опис: основне середовище виконання розширення. Всі компоненти
працюють усередині браузера Chrome (або сумісного браузера).
Програмне забезпечення: Chrome Browser з встановленим розширенням Page
Analyzer.
2 Content Script
Опис: виконується в контексті кожної відкритої веб-сторінки. Інжектується
браузером автоматично при завантаженні сторінки.
Взаємодія: безпосередньо працює з DOM веб-сторінки.
3 Popup (Інтерфейс користувача)
Опис: відкривається як окреме вікно розширення при кліку на іконку в панелі
браузера.
Програмне забезпечення: React + TypeScript + Tailwind CSS.
Діаграма розгортання може включати такі вузли та зв’язки між ними:
– Браузер (Client) ↔ Content Script: інжекція скрипта на веб-сторінку;
– Popup ↔ Content Script: обмін повідомленнями через Chrome Extension
API;
– Content Script ↔ Web Page: доступ до DOM, обчислення стилів і
виконання аналізу;
– Popup ↔ Chrome Storage: збереження стану CSS Viewer між сесіями;
38
ЧДТУ 262253.014 ПЗ
Рисунок 2.7 – Діаграма розгортання
Така архітектура забезпечує високу швидкодію, мінімальне споживання
ресурсів і повну автономність розширення. Всі дані обробляються локально в
браузері користувача, що гарантує конфіденційність і роботу без підключення до
зовнішніх серверів.
2.5. Моделювання поведінки системи
2.5.1. Діаграма діяльності
Діаграма діяльності дозволяє візуалізувати алгоритм роботи розширення Page
Analyzerз точки зору основних бізнес-процесів. На рисунку 2.8 змодельований
загальний процес аналізу веб-сторінки користувачем.
39
ЧДТУ 262253.014 ПЗ
Рисунок 2.8 – Діаграма діяльності
1 Початок роботи з розширенням
– користувач відкриває будь-яку веб-сторінку в браузері;
– користувач натискає на іконку розширення в панелі браузера.
2 Запуск аналізу сторінки
– система перевіряє, чи завантажена сторінка повністю;
– якщо сторінка завантажена – виконується комплексний аналіз
(технології, SEO, продуктивність, доступність);
– якщо сторінка ще завантажується – система виводить повідомлення
«Зачекайте, сторінка завантажується» і чекає завершення
40
ЧДТУ 262253.014 ПЗ
завантаження.
3 Відображення результатів
– після успішного аналізу результати відображаються у popup-вікні
розширення;
– користувач може перемикатися між розділами: «Технології», «SEO»,
«Продуктивність», «Доступність».
4 Робота з CSS Viewer
– користувач вмикає перемикач CSS Viewer;
– при наведенні курсора на елемент сторінки з’являється панель зі
стилями;
– користувач може зафіксувати елемент (Ctrl + ЛКМ), скопіювати стилі
або завантажити їх у .css-файл.
5 Завершення роботи
– користувач закриває popup-вікно розширення;
– система зберігає поточний стан (увімкнений/вимкнений CSS Viewer)
у chrome.storage.local.
2.5.2. Діаграма послідовності
Для детального розуміння обміну повідомленнями між компонентами
розширення було розроблено діаграми послідовності (див. рисунок 2.9).
Рисунок 2.9 – Діаграма послідовності «Загальний аналіз сторінки»
41
ЧДТУ 262253.014 ПЗ
Основні етапи:
– користувач відкриває Popup → Popup надсилає команду analyze до Content
Script;
– Content Script виконує сканування DOM і повертає результати (технології,
SEO, продуктивність, доступність);
– Popup отримує дані і відображає їх у відповідних секціях.
Рисунок 2.10 – Діаграма послідовності «CSS Viewer»
Основні етапи:
– користувач вмикає CSS Viewer;
– при наведенні курсора Content Script отримує getComputedStyle елемента;
– Content Script надсилає стилі до Popup;
– користувач натискає Ctrl + ЛКМ → Content Script фіксує елемент;
– користувач натискає кнопку «Копіювати» або «Завантажити» → Popup
отримує стилі і виконує відповідну дію.
42
ЧДТУ 262253.014 ПЗ
2.5.3. Діаграма комунікації
Діаграма комунікації показує взаємодію між основними компонентами
розширення. На відміну від діаграми послідовності, тут акцент зроблено на тому,
які об’єкти обмінюються повідомленнями (див. рисунок 2.11).
Рисунок 2.11 – Діаграма комунікації
Основні комунікаційні потоки:
– користувач → Popup: відкриття розширення, ввімкнення CSS Viewer,
фіксація елемента;
– Popup → Content Script: команди analyze, getComputedStyle, fixElement;
– Content Script → Web Page: доступ до DOM і обчислення стилів;
43
ЧДТУ 262253.014 ПЗ
– Content Script → Popup: повернення результатів аналізу та даних про
стилі;
– Popup ↔ Chrome Extension API: збереження стану в chrome.storage.local.
2.5.4. Діаграма скінченного автомату
Для опису поведінки модуля CSS Viewer була побудована діаграма
скінченного автомату (див. рисунок 2.12).
Рисунок 2.12 – Діаграма скінченного автомату модуля CSS Viewer
Основні стани модуля:
– Idle – CSS Viewer вимкнений;
– Hovering – користувач навів курсор на елемент, панель зі стилями
відображається;
– Fixed – елемент зафіксований (Ctrl + ЛКМ), стилі «заморожені»;
– Copying – тимчасовий стан під час копіювання або завантаження стилів.
– Переходи між станами відбуваються за подіями: наведення курсора, Ctrl
+ ЛКМ, клік по кнопках копіювання тощо. Чітке визначення станів
допомагає уникнути помилок у логіці роботи модуля.
44
ЧДТУ 262253.014 ПЗ
ВИСНОВОКИ ДО ДРУГОГО РОЗДІЛУ
У другому розділі було здійснено моделювання предметної області та
проектування логічної структури розширення Page Analyzer для комплексного
аналізу та тестування веб-ресурсів.
В межах розділу проведено аналіз предметної області, що дозволило чітко
визначити ключові об’єкти системи, такі як Користувач, Веб-сторінка,
Технологічний стек, Результати аналізу, CSS-елемент та Звіт, а також описати їх
взаємозв’язки. Сформовано словник предметної області, який забезпечує
однозначне трактування термінів, що використовуються в моделі.
Розроблено модель предметної області, яка відображає логічну структуру
розширення. Для візуалізації взаємодії користувача з системою створено діаграму
прецедентів. Проектування об’єктної моделі реалізовано за допомогою діаграми
класів, що дозволило структурувати основні сутності та їхні характеристики.
Для організації класів у логічні групи було використано діаграму пакетів.
Діаграма компонентів відобразила архітектуру структури системи на рівні
програмних компонентів. Діаграма розгортання показала, як розширення
функціонує в середовищі браузера користувача.
Моделювання поведінки системи проведено за допомогою діаграми
діяльності, діаграми послідовності, діаграми комунікації та діаграми скінченного
автомату. Ці діаграми дозволили детально описати алгоритми роботи основних
процесів, зокрема загального аналізу сторінки та інтерактивної роботи модуля CSS
Viewer.
Таким чином, у другому розділі закладено чітку систему, логічну та
структуровану основу для розробки програмного забезпечення. Побудовані UML-
моделі, створені на цьому етапі, відіграють ключову роль у подальшій реалізації,
тестуванні та документуванні готового розширення Page Analyzer.
45
ЧДТУ 262253.014 ПЗ
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
3.1. Розробка програмного комплексу
Процес розробки програмного комплексу розширення Page Analyzer є
ключовим етапом та включає ряд заходів, спрямованих на створення ефективного
та зручного у використанні розширення. Основою метою на цьому етапі є
реалізація ключових модулів, створення архітектури, налаштуванні зв’язку між
модулями та забезпеченні працездатності та розробки MVP розширення.
У процесі розробки особлива увага приділялася модульності архітектури,
щоб кожен компонент міг працювати незалежно, легко тестуватися та в
майбутньому розширюватися. Також було реалізовано механізм добровільного
збору анонімної статистики: після завершення аналізу користувач може надіслати
звіт про протестований сайт. Ці дані накопичуються в базі даних і надалі дозволять
формувати загальну статистику якості веб-ресурсів, рейтинги технологій та тренди
використання різних фреймворків.
Розробка велася з дотриманням сучасних практик:
– чітке розділення відповідальності між компонентами, оптимізація
продуктивності;
– оптимізація продуктивності, щоб розширення мінімально впливало на
продуктивність системи
– забезпечення безпеки відповідно до вимог Manifest V3 та рекомендацій
Google;
– модульність архітектури, яка дозволяє легко додавати нові функції або
змінювати існуючі без масштабної переробки коду;
– зру’чність підтримки та читабельність коду завдяки використанню
TypeScript і сучасних практик написання;
О основі реалізації використовувався об’єктно-орієнтованого підхід, який
забезпечує зручну та масштабовану структуру, спрощує розробку розширення та
тестування. Сучасний стек технологій дозволив створити чисту, підтримувану та
масштабовану кодову базу.
46
ЧДТУ 262253.014 ПЗ
В результаті цього етапу було розроблено повнофункціональне браузерне
розширення, яке успішно реалізує всі поставлені задачі та готове до подальшого
тестування та впровадження.
3.1.1. Обґрунтування вибору засобів реалізації
Для реалізації розширення Page Analyzer було обрано наступний ряд
основних засобів та технологій:
1 Мова програмування TypeScript
TypeScript обрано як основну мову розробки. Він додає статичну типізацію
до JavaScript, що значно зменшує кількість помилок, покращує читабельність коду
та полегшує підтримку проекту, особливо при обміні даними між popup-вікном і
content script.
2 Chrome Extension API (Manifest V3)
Manifest виступає базовою технологією для створення браузерних
розширень. Він був обраний, оскільки він забезпечує вищий рівень безпеки, кращу
продуктивність та відповідає актуальним вимогам Google. Без нього неможливо
було б реалізувати повноцінну взаємодію з вкладками, content scripts і popup-
інтерфейсом.
3 Бібліотека React
React використовувався для побудови інтерфейсу popup-вікна. Його
компонентна архітектура, ефективна робота зі станом і велика екосистема дозволяє
створити сучасний, зручний і масштабований інтерфейс, що ідеально підходить до
поставлених задач.
4 Бібліотека Tailwind CSS
Для швидкої та зручної стилізації інтерфейсу було обрано Tailwind CSS. Він
дозволяє створювати сучасний, адаптивний і чистий дизайн без написання великої
кількості власних CSS-правил. Це особливо важливо для popup-вікна, де кожен
піксель має значення.
5 Фреймворк WXT (Web Extension Toolkit)
WXT – це сучасний фреймворк для розробки браузерних розширень. Він
значно спрощує конфігурацію Manifest V3, підтримує гаряче оновлення під час
47
ЧДТУ 262253.014 ПЗ
розробки, автоматично обробляє content scripts і background service worker. Його
використання дозволило зосередитися на логіці розширення, а не на рутинному
налаштуванні проекту.
6 Середовище розробки Visual Studio Code + Git
Як середовище розробки використовувався Visual Studio Code завдяки його
легкості, потужним розширенням і зручній інтеграції з Git. Система контролю
версій Git та GitHub забезпечувала збереження історії змін і можливість спокійного
експериментування з кодом.
Вибір вищеназваного стеку технологій обумовлений необхідністю створити
швидке, безпечне та зручне як в розробці, так і в підтримці розширення. Обрані
технології та інструменти повністю відповідають поставленим задачам та вимогам.
3.1.2. Опис структурної (функціональної) схеми
Функціональна схема розширення показує, з яких основних блоків
складається система і як вони взаємодіють між собою під час роботи.
Розширення побудоване за класичною архітектурою браузерних розширень
та складається з трьох головних функціональних частин:
1 Інтерфейс користувача (Popup Interface):
– забезпечує візуальну взаємодію користувача з розширенням;
– реалізовано за допомогою React + TypeScript та Tailwind CSS;
– містить головне меню, розділи аналізу (Технології, SEO,
Продуктивність, Доступність), панель CSS Viewer, кнопки керування
та відображення результатів.
2 Content Script (Скрипт аналізу):
– відповідає за безпосередній аналіз вмісту веб-сторінки;
– інжектується браузером у кожну відкриту вкладку;
– виконує сканування DOM, виявлення технологій, збір SEO-даних,
розрахунок метрик продуктивності, перевірку доступності та
витягування CSS-стилів елементів;
– є єдиним компонентом, який має прямий доступ до веб-сторінки.
3 Модуль виявлення технологій:
48
ЧДТУ 262253.014 ПЗ
– аналізує скрипти, мета-теги, HTTP-заголовки та інші ознаки;
– виявляє та категоризує технології (фреймворки, CMS, бібліотеки,
інструменти аналітики тощо);
– формує структурований список технологій для відображення
користувачеві.
4 Модуль SEO-аналізу:
– перевіряє технічні параметри пошукової оптимізації сторінки;
– аналізує мета-теги, заголовки, viewport, robots, canonical та інші
фактори;
– формує оцінку та рекомендації щодо покращення SEO.
5 Модуль аналізу продуктивності:
– оцінює швидкість завантаження та роботи сторінки;
– виявляє повільні ресурси, великі JS-файли, сторонні скрипти;
– збирає базові метрики Core Web Vitals (FCP, LCP, CLS, INP).
6 Модуль перевірки доступності:
– проводить базовий аудит сторінки відповідно до стандартів WCAG;
– виявляє зображення без alt, інтерактивні елементи без доступного
імені, відсутність атрибута lang тощо;
– формує рекомендації щодо виправлення проблем.
7 Модуль CSS Viewer:
– забезпечує інтерактивний перегляд обчислених стилів елементів
сторінки в реальному часі;
– підтримує фіксацію елементів (Ctrl + ЛКМ), копіювання стилів та їх
завантаження у вигляді .css-файлу.
Загальна логіка роботи:
Коли користувач відкриває popup, інтерфейс надсилає запит до Content
Script. Content Script аналізує поточну веб-сторінку і повертає результати. Popup
отримує дані і відображає їх у відповідних розділах. Якщо користувач вмикає CSS
Viewer, Content Script починає відстежувати події миші на сторінці і передає стилі
елементів у реальному часі до popup. (див. схему на рисунку 3.1)
49
ЧДТУ 262253.014 ПЗ
Рисунок 3.1 - Структурна (функціональна) схема
Така структура забезпечує чітке розділення обов’язків: Content Script
займається важкою роботою з DOM, Popup – лише відображенням даних, а
Chrome Extension API – комунікацією та безпекою.
3.1.3. Опис логічної схеми
Логічна схема розширення Page Analyzer розкриває, як саме працюють
ключові алгоритми та механізми всередині системи. Якщо структурна схема
показує «що» робить кожен блок, то логічна схема пояснює «як» це відбувається на
рівні конкретних операцій і взаємодій між компонентами.
Приклад 1: Логіка виявлення технологій
Модуль виявлення технологій є одним з основних компонентів розширення.
Він працює на основі аналізу кількох джерел даних: HTTP-заголовків, мета-тегів,
підключених скриптів, стилів та структури DOM.
Логіка роботи модуля побудована за таким принципом:
1 Content Script отримує доступ до DOM поточної веб-сторінки.
2 Виконується сканування основних індикаторів технологій:
– пошук специфічних скриптів і їхніх імен (наприклад, react, vue,
angular);
– аналіз мета-тегів та HTTP-заголовків;
50
ЧДТУ 262253.014 ПЗ
– перевірка наявності характерних класів, атрибутів та глобальних
об’єктів;
– виявлення популярних CMS за характерними шляхами файлів або
HTML-структурою.
3 Кожна знайдена технологія проходить перевірку на відповідність базі
відомих сигнатур.
4 Після виявлення технології додається до відповідної категорії (фронтенд-
фреймворки, CMS, інструменти аналітики, хостинг тощо).
5 Результат формується у вигляді структурованого списку з назвою,
категорією та версією (якщо вдалося визначити).
Приклад 2: Логіка роботи модуля CSS Viewer
Модуль CSS Viewer є найбільш інтерактивною частиною розширення. Його
логіка побудована навколо реального часу і включає такі етапи:
1 Після ввімкнення CSS Viewer Content Script починає прослуховувати події
миші (mouseover, mouseout, click).
2 При наведенні курсора на елемент сторінки відбувається виклик
window.getComputedStyle(element), який повертає всі обчислені стилі цього
елемента.
3 Отримані стилі передаються до Popup Interface для відображення в
спеціальній панелі.
4 Якщо користувач натискає Ctrl + ЛКМ на елементі, система фіксує цей
елемент і перестає оновлювати стилі при русі курсора.
5 Користувач може скопіювати окремі властивості або весь блок стилів, а
також завантажити його у вигляді готового .css файлу.
Приклад 3: Логіка формування результатів аналізу
Після завершення сканування всі дані (технології, SEO, продуктивність,
доступність) збираються в єдиний об’єкт AnalysisResult. Цей об’єкт передається з
Content Script до Popup Interface, де відбувається його обробка та відображення в
відповідних розділах інтерфейсу. Якщо користувач активував відправку анонімного
звіту, дані про сайт (без персональної інформації) зберігаються в базі даних для
подальшої статистики.
51
ЧДТУ 262253.014 ПЗ
Логічна схема показує, що всі модулі аналізу працюють незалежно, але їхні
результати об’єднуються в єдиний звіт, що забезпечує комплексний підхід до
оцінки якості веб-ресурсу.
3.1.4. Розробка бази даних
У рамках розробки браузерного розширення Page Analyzer не було
передбачено використання системи управління базами даних. Таке рішення
обумовлено специфікою архітектури та призначенням самого розширення.
По-перше, розширення працює повністю в середовищі браузера користувача
і не має власного серверного компонента. Весь аналіз веб-сторінки виконується
локально на стороні клієнта за допомогою Content Script. Отримані результати
зберігаються лише протягом одного сеансу роботи з popup-вікном.
По-друге, основне призначення розширення – швидкий та інтерактивний
аналіз поточної веб-сторінки «тут і зараз». Дані, отримані під час аналізу, не
потребують подальшого довгострокового зберігання на стороні користувача,
оскільки вони актуальні тільки для конкретної сторінки в конкретний момент часу.
Таким чином, вся необхідна інформація обробляється і зберігається
безпосередньо в оперативній пам’яті браузера з використанням вбудованих
механізмів (chrome.storage.local для збереження налаштувань і стану розширення).
Відсутність бази даних є цілком обґрунтованим і оптимальним рішенням для
даного типу програмного забезпечення.
3.1.5. Розробка інтерфейсу користувача
Інтерфейс користувача розширення Page Analyzer є одним із ключових
елементів системи, через нього користувач взаємодіє з результатами аналізу. При
розробці інтерфейсу основний акцент робився на зручності використання в умовах
обмеженого розміру popup-вікна.
Інтерфейс розроблено за допомогою бібліотеки React.js з використанням
TypeScript та стилізації через Tailwind CSS. Таке поєднання технологій дозволило
створити сучасний, швидкий та адаптивний інтерфейс (див. рисунок 3.2).
52
ЧДТУ 262253.014 ПЗ
Рисунок 3.2 – Загальний вигляд інтерфейсу розширення (Popup)
Інтерфейс складається з навігаційної панелі та основної області відображення
даних. Навігаційна панель містить чотири основних розділів:
1 Розділ «Загальний аналіз»
У цьому розділі користувач отримує загальну оцінку якості веб-сторінки у
вигляді числового показника на шкалі від 0 до 100 та кольорового індикатора. Тут
відображається підсумкова оцінка за всіма категоріями аналізу, ключові проблеми
сторінки та рекомендації щодо покращення (див. рисунок 3.3). В результаті маємо
наступне:
– загальну оцінку сторінки у балах (середнє значення з усіх модулів);
53
ЧДТУ 262253.014 ПЗ
– чотири кругові діаграми з оцінками за категоріями (SEO, Performance,
Accessibility, Technologies);
– кольорову індикацію (зелений – добре, жовтий – середньо, червоний –
погано);
– список найбільш критичних проблем, виявлених на сторінці.
Рисунок 3.3 - Вигляд розділу «Загальний аналіз»
54
ЧДТУ 262253.014 ПЗ
2 Розділ «Технології»
Розділ відображає повний технологічний стек сайту. Користувач може
побачити, які фреймворки, бібліотеки, CMS та сервіси використовуються на
сторінці (React, Vue, WordPress, Shopify, Google Analytics, Cloudflare тощо). Для
кожної технології вказується версія, якщо ту вдалося визначити, та категорія (див.
рисунок 3.4).
Рисунок 3.4 – Вигляд розділу «Технології»
3 Розділ «SEO»
У цьому розділі представлені результати SEO-аудиту сторінки (див. рисунок
3.5). Користувач отримує наступну інформацію:
– мета-теги (title, description);
– наявність заголовків H1–H6;
55
ЧДТУ 262253.014 ПЗ
– атрибутів alt у зображень;
– canonical-посилань;
– рекомендації щодо покращення пошукової оптимізації.
Рисунок 3.5 - Вигляд розділу «SEO»
4 Розділ «Продуктивність»
Один з найдетальніших розділів, призначений для глибокого аналізу
швидкості завантаження сторінки (див. рисунок 3.6). В розділі представлена
наступна інформація:
– загальну оцінку продуктивності (0–100);
– відображення Core Web Vitals (FCP, LCP, CLS) з кольоровою індикацією;
– іконки інформації біля кожного показника Core Web Vitals – при наведенні
з’являється тултип з розгорнутим поясненням терміну;
56
ЧДТУ 262253.014 ПЗ
– три розгорнуті блоки з анімацією:
1 повільні ресурси;
2 сторонні скрипти;
3 великі JavaScript-файли.
– у кожному блоці реалізовано обмеження висоти та вертикальний
скролбар;
– список рекомендацій з пріоритетом критичності;
Рисунок 3.6 - Вигляд розділу «Продуктивність»
5 Доступність.
У розділі проводиться перевірка сторінки відповідно до стандартів WCAG.
Відображається рівень доступності, кількість виявлених помилок та попереджень,
а також конкретні проблеми (відсутність alt-тексту, недостатній контраст кольорів,
проблеми з фокусом тощо) (див. рисунок 3.4).
Додатково в інтерфейсі реалізований інтерактивний модуль CSS Viewer, який
дозволяє в реальному часі переглядати CSS-властивості будь-якого елемента на
57
ЧДТУ 262253.014 ПЗ
сторінці.
Рисунок 3.7 – Вигляд розділу «Доступність»
3.1.6. Опис розробки програмних
компонентів 1 App.tsx:
– призначення: головний компонент розширення, який керує всім
інтерфейсом і станом додатку;
– зв’язки: використовує хук usePageAnalysis, імпортує всі секції та
компоненти навігації;
– особливості реалізації: реалізує логіку перемикання між розділами,
автоматичний запуск аналізу при відкритті розширення, плавні
анімації переходів між екранами та обробку стану завантаження.
58
ЧДТУ 262253.014 ПЗ
2 usePageAnalysis.ts:
– призначення: кастомний React-хук для управління станом аналізу
сторінки;
– зв’язки: взаємодіє з content-скриптом через chrome.tabs.sendMessage;
– особливості реалізації: зберігає поточну активну секцію, стан
завантаження, результат аналізу та помилки, забезпечує функцію
запуску аналізу.
3 MenuView.tsx:
– призначення: головне меню розширення, яке відображається при
відкритті popup;
– зв’язки: використовує компонент FeatureButton та приймає пропси для
запуску аналізу та навігації;
– особливості реалізації: містить велику кнопку «Загальний аналіз»,
сітку з чотирма основними розділами та окрему кнопку «Оновити
аналіз».
4 SeoSection.tsx:
– призначення: компонент для відображення результатів SEO-аналізу
сторінки;
– зв’язки: приймає пропс result типу AnalysisResult;
– особливості реалізації: показує загальну оцінку SEO, деталі (Title,
Meta Description, Robots meta, HTTPS тощо) та список виявлених
проблем. Meta Description реалізовано як розгорнутий блок з
анімацією.
5 PerfSection.tsx:
– призначення: компонент для відображення результатів аналізу
продуктивності;
– зв’язки: приймає пропс result типу AnalysisResult;
– особливості реалізації: відображає Core Web Vitals з інформативними
тултипами, три розгорнуті блоки (повільні ресурси, сторонні скрипти,
великі JS-файли) з анімацією відкриття, внутрішнім скролом та
функцією копіювання URL.
59
ЧДТУ 262253.014 ПЗ
6 AccessibilitySection.tsx:
– призначення: компонент для відображення результатів перевірки
доступності сторінки;
– зв’язки: приймає пропс result типу AnalysisResult;
– особливості реалізації: показує загальну оцінку доступності, ключові
метрики (зображення без alt, інтерактивні елементи без назви, атрибут
lang) та список проблем.
7 TechSection.tsx:
– призначення: компонент для відображення виявлених технологій
сторінки;
– зв’язки: приймає result та функцію getCategoryIcon;
– особливості реалізації: групує технології за категоріями, сортує їх
згідно з categoryOrder та відображає назву і версію кожної технології.
8 OverallDashboard.tsx:
– призначення: головний дашборд, який показує узагальнений аналіз
сторінки;
– зв’язки: використовує утиліти calculateOverallScore,
calculateTechScore та функцію генерації PDF;
– особливості реалізації: відображає загальну оцінку, оцінки по
розділах, Core Web Vitals, статистику сторінки, критичні проблеми та
список виявлених технологій. Підтримує експорт повного звіту у PDF.
9 detectPerformance.ts:
– призначення: функція аналізу продуктивності сторінки;
– зв’язки: використовує Web Performance API;
– особливості реалізації: розраховує Core Web Vitals (FCP, LCP, CLS),
час завантаження, збирає списки повільних ресурсів, сторонніх
скриптів та великих JS-файлів.
10 detectSEO.ts:
– призначення: функція SEO-аналізу сторінки;
– зв’язки: аналізує DOM елементи (title, meta-теги, h1 тощо);
– особливості реалізації: перевіряє наявність та якість title, meta
60
ЧДТУ 262253.014 ПЗ
description, robots meta, HTTPS, viewport та інших SEO-параметрів.
11 detectAccessibility.ts:
– призначення: функція перевірки доступності сторінки;
– зв’язки: аналізує DOM елементи;
– особливості реалізації: перевіряє наявність alt-текстів у зображеннях,
доступних назв у інтерактивних елементах, атрибут lang на <html> та
інші базові вимоги доступності.
12 content.ts:
– призначення: content script, який виконується безпосередньо на
сторінці користувача;
– зв’язки: взаємодіє з popup та background скриптом;
– особливості реалізації: виконує всі функції аналізу (detectTechnologies,
detectSEO, detectPerformance, detectAccessibility) та підтримує
інструмент CSS Viewer.
3.2. Тестування системи
Тестування є невід’ємною частиною розробки будь-якого програмного
продукту. Воно дозволяє перевірити коректність роботи системи, виявити помилки
на ранніх етапах та підтвердити відповідність розробленого розширення
поставленим вимогам. У рамках даного дипломного проєкту було проведено
модульне, інтеграційне, системне та приймальне тестування розширення Page
Analyzer.
3.2.1. Модульне тестування
Модульне тестування є ключовим етапом розробки програмного
забезпечення, спрямованим на перевірку правильності роботи окремих модулів і
функцій системи в ізольованому середовищі. Воно дозволяє виявляти помилки на
ранніх стадіях розробки, що значно спрощує подальшу інтеграцію компонентів.
Для модульного тестування розширення Page Analyzer було використано
тестовий фреймворк Jest разом із ts-jest та jest-chrome. Це дозволило емулювати
браузерне середовище за допомогою jsdom та мокати браузерні API (performance,
61
ЧДТУ 262253.014 ПЗ
document, chrome).
Основна увага була зосереджена на тестуванні ключових функцій аналізу
сторінки, оскільки вони становлять основу функціональності розширення. Було
створено тести для таких модулів:
– detectSEO.ts – функція SEO-аналізу;
– detectPerformance.ts – функція аналізу продуктивності;
– detectAccessibility.ts – функція перевірки доступності;
– scoreUtils.ts – утиліти розрахунку загальної оцінки.
Усього реалізовано 8 модульних тестів (див. рисунок 3.8), які охоплюють як
позитивні, так і негативні сценарії, а також граничні випадки.
Приклади модульних тестів:
test('detectSEO повинен знижувати score при відсутності title', () =>
{
Object.defineProperty(document, 'title', { value: '', writable:
true });
const result = detectSEO();
expect(result.score).toBeLessThan(100);
expect(result.issues.some((i: any) =>
i.message.includes('title'))).toBe(true);
});
test('detectPerformance повинен правильно розраховувати оцінку при
нормальних умовах', () => {
const result = detectPerformance();
expect(result.score).toBeGreaterThanOrEqual(60);
expect(typeof result.details.fcp).toBe('number');
});
Рисунок 3.8 – Проходження модульних тестів в середовищі розробки
62
ЧДТУ 262253.014 ПЗ
Таблиця 3.1
Проходження модульних тестів
Модуль / Очікуваний Результат
№ Опис тесту
Функція результат виконання
score < 100,
Перевірка зниження оцінки
1 detectSEO наявність Успішно
при відсутності title
помилки про title
Перевірка високої оцінки
2 detectSEO score ≥ 70 Успішно
при хороших SEO-умовах
score ≥ 60,
detectPerfor Перевірка розрахунку оцінки коректні
3 Успішно
mance при нормальних умовах значення FCP,
LCP, CLS
score < 85,
detectPerfor Перевірка зниження score наявність
4 Успішно
mance при високому CLS попередження
про CLS
score < 100,
detectAcces Перевірка зниження score наявність
5 Успішно
sibility при відсутності lang помилки про
lang
detectAcces Перевірка високої оцінки
6 score ≥ 80 Успішно
sibility при наявності lang та alt
calculateOv Перевірка розрахунку score між 0 та
7 Успішно
erallScore загальної оцінки 100
score залежить
calculateTe Перевірка розрахунку оцінки
8 від кількості Успішно
chScore технологій
технологій
Кожен модуль був ретельно протестований на відповідність функціональним
63
ЧДТУ 262253.014 ПЗ
вимогам. Для тестів використовувалися як позитивні сценарії, коректні дані, так і
негативні, відсутність необхідних елементів, граничні значення.
Після виконання модульного тестування всі тести пройшли успішно. Були
виявлені та виправлені декілька дрібних помилок, пов’язаних з обробкою
некоректних або відсутніх даних. Такий підхід дозволив підвищити стабільність і
надійність ключових функцій розширення ще на етапі розробки.
3.2.2. Інтеграційне тестування
Інтеграційне тестування є наступним етапом після модульного тестування і
спрямоване на перевірку коректної взаємодії між різними модулями та
компонентами системи. На цьому етапі перевіряється, чи працюють окремі частини
розширення разом правильно, як це передбачено загальною архітектурою.
Для інтеграційного тестування розширення перевірялася взаємодія між
основними частинами системи: popup-інтерфейсом, content-скриптом, background-
скриптом та браузерними API. Особлива увага приділялася передачі даних між
popup і content-скриптом, обробці результатів аналізу та коректному відображенню
інформації в інтерфейсі.
Під час тестування перевірялися такі ключові сценарії взаємодії:
– запуск аналізу зі спливаючого вікна (popup) та передача команди в content
script;
– отримання результатів аналізу від content script і їх обробка в App.tsx;
– перемикання між різними розділами інтерфейсу (SEO, Performance,
Доступність, Загальний аналіз);
– робота інструменту CSS Viewer (взаємодія popup + content script);
Було створено тестові набори для позитивних, негативних та граничних
сценаріїв взаємодії.
Таблиця 3.2
Проходження інтеграційних тестів
Компонент / Результат
№ Опис тесту Очікуваний результат
Модуль виконання
64
ЧДТУ 262253.014 ПЗ
Продовження таблиці 3.2
Content script отримує
Popup → Запуск аналізу
1 команду та виконує Успішно
Content Script сторінки з popup
аналіз
Дані коректно
Отримання
Content Script передаються та
2 результатів аналізу Успішно
→ Popup відображаються в
та їх відображення
інтерфейсі
Перехід між SEO,
Перемикання Коректне перемикання та
Performance,
3 між відображення Успішно
Доступність та
розділами відповідної секції
Загальним аналізом
Увімкнення/вимкнен
Інструмент активується
4 CSS Viewer ня інструменту CSS Успішно
та коректно працює
Viewer
PDF-файл успішно
Генерація Експорт повного
5 генерується та Успішно
PDF-звіту звіту в PDF
завантажується
Перевірка поведінки Відображається
Обробка
6 при відсутності зрозуміле повідомлення Успішно
помилок
активної вкладки про помилку
Перевірка
Загальна Всі позитивні сценарії
7 позитивних Успішно
інтеграція виконуються коректно
сценаріїв
Перевірка
Загальна Система стабільно
8 негативних та Успішно
інтеграція обробляє помилки
граничних сценаріїв
Після успішного проходження інтеграційного тестування було підтверджено,
що всі основні компоненти розширення (popup, content script, background script та
функції аналізу) коректно взаємодіють між собою. Дані успішно передаються,
обробляються та відображаються в інтерфейсі користувача. Цей етап дозволив
переконатися в стабільності та працездатності системи перед проведенням
системного та приймального тестування.
3.2.3. Системне тестування
65
ЧДТУ 262253.014 ПЗ
Системне тестування є одним з найважливіших етапів тестування, який
проводиться перед впровадженням розширення в реальні умови. Його основна мета
– перевірити, чи відповідає вся система в цілому функціональним та
нефункціональним вимогам, а також чи працює вона стабільно в умовах,
максимально наближених до реального використання. –
Під час системного тестування перевірялася робота розширення Page
Analyzer на різних типах веб-сайтів (новинні портали, соціальні мережі,
корпоративні сайти, інтернет-магазини тощо). Тестування включало функціональні
тести, тести продуктивності, перевірку стабільності та зручності використання.
Основні напрямки системного тестування:
– перевірка коректності виконання всіх основних функцій аналізу (SEO,
продуктивність, доступність, визначення технологій);
– тестування швидкості аналізу сторінки;
– перевірка стабільності роботи при великому обсязі даних і складних
сторінках;
– тестування зручності інтерфейсу та інтуїтивності навігації;
– перевірка коректності експорту звіту у PDF;
– тестування роботи на різних браузерах (Chrome, Edge, Firefox).
Таблиця 3.3
Проходження системних тестів
№ Компонент / Опис тесту Очікуваний Результат
Модуль результат виконання
1 Функціональність Перевірка Технології Успішно
аналізу коректності визначаються
визначення правильно
технологій
2 Функціональність Перевірка SEO- Всі SEO-параметри Успішно
аналізу аналізу (title, meta аналізуються
description, robots) коректно
3 Функціональність Перевірка Значення метрик Успішно
аналізу розрахунку Core обчислюються
Web Vitals (FCP, правильно
LCP, CLS)
66
ЧДТУ 262253.014 ПЗ
Продовження таблиці 3.3
4 Функціональність Перевірка Проблеми доступності Успішно
аналізу перевірки виявляються коректно
доступності (alt,
lang, контраст)
5 Продуктивність Тестування Середній час аналізу не Успішно
швидкості аналізу перевищує 4 секунди
сторінки
6 Продуктивність Тестування Розширення працює без Успішно
стабільності при зависань
аналізі складних
сторінок
7 Експорт звіту Генерація та PDF-файл успішно Успішно
завантаження PDF- генерується та
звіту завантажується
8 Користувацький Перевірка Перехід між розділами Успішно
інтерфейс зручності навігації відбувається швидко та
між розділами коректно
9 Сумісність Тестування на Розширення коректно Успішно
різних браузерах працює в основних
(Chrome, Edge, браузерах
Firefox)
10 Загальна Тестування на Розширення працює Успішно
стабільність різних типах сайтів стабільно на всіх типах
сайтів
Після успішного проходження системного тестування було підтверджено, що
розширення Page Analyzer відповідає поставленим вимогам, працює стабільно та
забезпечує очікуваний рівень функціональності. Виявлені незначні недоліки були
виправлені. Розширення готове до подальшого використання.
3.2.4. Приймальне тестування
Приймальне тестування (User Acceptance Testing, UAT) є заключним етапом
тестування системи та проводиться з метою перевірки відповідності розширення
реальним потребам і очікуванням кінцевих користувачів. На відміну від попередніх
етапів, приймальне тестування виконується не тільки розробником, а й
потенційними користувачами або їх представниками.
Метою даного тестування було підтвердити, що розширення Page Analyzer
Pro є зручним у використанні, надає корисну та зрозумілу інформацію, а також
67
ЧДТУ 262253.014 ПЗ
повністю задовольняє поставлені завдання – швидкий і якісний аналіз веб-сторінок.
Під час приймального тестування користувачі перевіряли такі аспекти:
– зручність і інтуїтивність інтерфейсу;
– швидкість отримання результатів аналізу;
– зрозумілість представленої інформації (оцінки, рекомендації, списки
проблем);
– роботу основних функцій (аналіз сторінки, перемикання розділів,
копіювання даних).
Приймальне тестування проводилося за такими етапами:
– планування тестування та визначення критеріїв успішності;
– підготовка тестових сценаріїв;
– виконання тестів реальними користувачами;
– збір відгуків та аналіз результатів;
– внесення фінальних правок.
Таблиця 3.4
Проходження приймальних тестів
Компонент / Очікуваний Результат
№ Опис тесту
Модуль результат виконання
Запуск аналізу Аналіз запускається та
1 Функціональність Успішно
поточної сторінки завершується успішно
Перегляд
результатів у Всі розділи
2 Функціональність розділах SEO, відображають Успішно
Performance, коректну інформацію
Accessibility
Копіювання URL URL успішно
3 Функціональність ресурсів у розділі копіюється у буфер Успішно
Performance обміну
Перехід між розділами
Перемикання між
4 Інтерфейс відбувається швидко Успішно
розділами меню
та коректно
68
ЧДТУ 262253.014 ПЗ
Продовження таблиці 3.4
Зручність
Блоки
розгортання
5 Інтерфейс розгортаються/згорта Успішно
блоків
ються без затримок
(Collapsible)
Швидкість Аналіз виконується за
6 Продуктивність виконання аналізу прийнятний час (до 4 Успішно
сторінки секунд)
Генерація та Звіт успішно
7 Експорт звіту завантаження генерується та Успішно
PDF-звіту зберігається
Інтуїтивність Користувач може
Загальна
8 інтерфейсу та легко знайти потрібну Успішно
зручність
навігації інформацію
Робота
Розширення стабільно
9 Сумісність розширення в Успішно
працює в Chrome
браузері Chrome
Загальна оцінка
Загальне Користувачі вважають
10 корисності Успішно
враження розширення корисним
розширення
За результатами приймального тестування користувачі позитивно оцінили
зручність інтерфейсу, швидкість роботи та інформативність представлених даних.
Приймальне тестування підтвердило, що розширення Page Analyzer
відповідає очікуванням користувачів і готове до практичного використання.
3.3. Приклади впровадженого програмного комплексу
Впровадження розробленого браузерного розширення Page Analyzer Pro є
завершальним етапом створення програмного продукту. Метою впровадження є
забезпечення комфортного та ефективного використання розширення веб-
розробниками, SEO-спеціалістами, тестувальниками та іншими користувачами, які
потребують швидкого аналізу веб-сторінок.
Процес впровадження розширення значно відрізняється від впровадження
повноцінних веб-додатків, оскільки воно встановлюється безпосередньо в браузер
69
ЧДТУ 262253.014 ПЗ
користувача. Основні етапи впровадження включають підготовку, розповсюдження,
встановлення та подальшу підтримку розширення.
1. Етапи впровадження
– підготовка до розповсюдження
– фінальна перевірка та оптимізація коду;
– підготовка manifest-файлу та іконок різних розмірів;
– створення детального опису розширення та скріншотів для Chrome
Web Store;
– тестування розширення в різних версіях браузера Google Chrome.
6 Упаковка та побудова
– збірка розширення за допомогою WXT у production-режимі;
– генерація файлу .zip для ручного встановлення;
– підготовка версії для публікації в Chrome Web Store.
7 Розповсюдження розширення
– публікація в Chrome Web Store (основний спосіб розповсюдження);
– надання можливості завантаження розширення у форматі .crx або .zip
для корпоративного використання;
– розміщення посилання на розширення на GitHub та особистому
сайті/портфоліо.
8 Встановлення та активація
– встановлення розширення користувачем через Chrome Web Store;
– ручне встановлення в режимі розробника (для тестерів та ранніх
користувачів);
– перший запуск та автоматичний аналіз поточної сторінки.
9 Навчання та підтримка користувачів
– створення інструкції з використання (User Guide);
– підготовка коротких відео-інструкцій;
– налаштування системи зворотного зв’язку (через GitHub Issues або
email);
– моніторинг відгуків та оперативне виправлення виявлених проблем.
Основні функціональні компоненти, що впроваджуються:
70
ЧДТУ 262253.014 ПЗ
1 Інтерфейс управління – спливаюче вікно з меню та розділами аналізу.
2 Модуль аналізу сторінки – автоматичний збір даних про технології, SEO,
продуктивність та доступність.
3 Візуалізація результатів – кольорові оцінки, прогрес-бари, розгортаючі
блоки та списки проблем.
4 Інструмент CSS Viewer – інтерактивний інструмент для перегляду стилів
елементів сторінки.
5 Система оновлення аналізу – можливість повторного аналізу поточної
сторінки в один клік.
Впровадження розширення Page Analyzer дозволяє користувачам швидко
отримувати комплексну інформацію про будь-яку веб-сторінку безпосередньо в
браузері. Завдяки простому процесу встановлення та інтуїтивному інтерфейсу,
розширення може бути ефективно використане як окремими спеціалістами, так і
командами веб-розробки.
Успішне впровадження забезпечується зручним процесом встановлення та
постійною технічною підтримкою користувачів після публікації розширення.
71
ЧДТУ 262253.014 ПЗ
ВИСНОВКИ ДО ТРЕТЬОГО РОЗДІЛУ
Третій розділ присвячено практичній реалізації, тестування та впровадженню
браузерного розширення Page Analyzer.
У розділі розглянуто процес створення основних програмних компонентів
системи. Було розроблено ключові модулі аналізу сторінки, утиліти розрахунку
оцінок, а також інтерфейс користувача.
Було розроблено архітектура розширення, яка базується на взаємодії popup-
інтерфейсу, content-скрипту та background-скрипту. Описано реалізацію React-
компонентів, анімацій, тултипів та інтерактивних блоків.
Тестування системи проводилося на кількох рівнях. Було виконано модульне
тестування основних функцій аналізу за допомогою Jest, інтеграційне тестування
взаємодії між компонентами розширення, системне тестування на реальних веб-
сторінках, а також приймальне тестування з метою перевірки зручності та
корисності для кінцевого користувача.
У підрозділі «Приклади впровадження програмного комплексу» описано
етапи підготовки, пакування, розповсюдження через Chrome Web Store та
встановлення розширення, а також заходи щодо подальшої підтримки користувачів.
У цілому, розділ надає весь обсяг інформації щодо процесу розробки,
тестування та впровадження браузерного розширення, що підтверджує його
технічну готовність та відповідність поставленим завданням.
72
ЧДТУ 262253.014 ПЗ
ВИСНОВКИ
У процесі виконання кваліфікаційної роботи бакалавра була успішно
досягнута поставлена мета – розроблено браузерне розширення Page Analyzer Pro,
призначене для комплексного аналізу веб-сторінок.
Розроблене розширення надає користувачам можливість швидко оцінювати
якість сайту за ключовими параметрами: SEO, продуктивністю (Core Web Vitals),
доступністю та використаними технологіями – безпосередньо в браузері, без
потреби у сторонніх сервісах.
У ході роботи були повністю виконані всі поставлені завдання, а саме:
1 Реалізовано модуль SEO-аналізу, де розробник швидко може
проаналізувати зібрану розширенням інформацію, таку як довжину «Title»,
кількість слів на сторінці, «Meta Description», наявність HTTPS та мобільного
«viewport» та отримати рекомендації щодо покращення SEO сторінки.
2 Розроблено детектор технологій, де розробник може проаналізувати всі
використовувані сторінкою технології, які зібрало розширення, такі як бібліотеки,
фреймворки, сервіси безпеки тощо.
3 Створено модуль аналізу продуктивності, де у розробника є можливість
отримати та проаналізувати всі повільні ресурси, сторонні скрипти, великі JS-
файли та відповідно переглянути кожен з них. У розділі доступні метрики таких
показників як час завантаження сторінки, FCP – час від початку завантаження
сторінки до появи першого контенту, LCP – час до появи найбільшого видимого
елемента на сторінці, CLS – сумарний зсув елементів під час завантаження та
переглянути рекомендації щодо покращення результатів.
4 Реалізовано модуль перевірки доступності, де у розробника є
можливість переглянути кількість зображень без тегу «alt», кількість інтерактивних
елементів без імені, наявність атрибуту lang у блоці «html» та отримати
рекомендації згідно зі стандартами WCAG 2.2.
5 Розроблено сучасний, зручний та інтерактивний інтерфейс користувача
з підтримкою розгортаючих блоків, тултипів, копіювання даних та інтерактивного
CSS Viewer.
73
ЧДТУ 262253.014 ПЗ
6 Проведено комплексне тестування розширення на модульному,
інтеграційному, системному та приймальному рівнях.
7 Підготовлено розширення до практичного використання шляхом
створення детальної інструкції користувача та опису процесу встановлення.
Розробка була виконана з використанням актуальних веб-технологій:
TypeScript, React, Tailwind CSS та фреймворку WXT. Для тестування застосовувався
фреймворк Jest.
За результатами тестування всі функції розширення працюють стабільно та
коректно. Розроблений продукт готовий до практичного застосування.
Page Analyzer може бути корисним інструментом для веб-розробників, SEO-
фахівців, тестувальників та студентів, що вивчають сучасні веб-технології,
сприяючи швидкому та якісному аналізу інтернет-ресурсів.
74
ЧДТУ 262253.014 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Розглянутий аналог Wappalyzer [Електронний ресурс]. – Режим доступу
https://www.wappalyzer.com/
2 Розглянутий аналог Google Lighthouse [Електронний ресурс]. – Режим
доступу: https://developer.chrome.com/docs/lighthouse/overview
3 Розглянутий аналог BuiltWith.com [Електронний ресурс]. – Режим
доступу: https://builtwith.com/
4 Сайт для розробки UML діаграм [Електронний ресурс]. – Режим доступу:
https://plantuml.com/
5 Chrome API Extention Documentation [Електронний ресурс]. – Режим
доступу: https://developer.chrome.com/docs/extensions/reference/api
6 TypeScript Documentation [Електронний ресурс]. – Режим доступу:
https://www.typescriptlang.org/docs/
7 WXT Documentation [Електронний ресурс]. – Режим доступу:
https://wxt.dev/guide/introduction.html
8 Google Web Vital [Електронний ресурс]. – Режим доступу:
https://web.dev/articles/vitals?hl=ru
9 TailWind css Documentation [Електронний ресурс]. – Режим доступу:
https://tailwindcss.com/docs/installation/using-vite
10 WCAG 2.2. Web Content Accessibility Guidelines [Електронний ресурс]. –
Режим доступу: https://www.w3.org/TR/WCAG22/
11 React Documentation [Електронний ресурс]. – Режим доступу:
https://ru.legacy.reactjs.org/docs/getting-started.html
12 Google SEO Documentation [Електронний ресурс]. – Режим доступу:
https://developers.google.com/search/docs
13 Accessibility Documentation [Електронний ресурс]. – Режим доступу:
https://web.dev/accessibility
14 eSparkBiz [Електронний ресурс].– Режим доступу:
https://www.esparkinfo.com/web-development/statistics
75
ЧДТУ 262253.014 ПЗ
15 JavaScript Documentation [Електронний ресурс]. – Режим доступу:
https://developer.mozilla.org/en-US/docs/Web/JavaScript
16 Jest framework Documentation [Електронний ресурс]. – Режим доступу:
https://jestjs.io/docs/getting-started
17 Engineering Fundamentals Playbook [Електронний ресурс]. – Режим
доступу: https://microsoft.github.io/code-with-engineering-playbook
18 HTML Documentation [Електронний ресурс]. – Режим доступу:
https://developer.mozilla.org/ru/docs/Web/HTML
76
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедрою ПЗАС, професор
_________________ Голуб С.В.
„____” ______________ 2026 р.
Система оцінювання якості WEB-ресурсів
Специфікація
482 ЧДТУ. 262253-014
Листів 2
Розробник _______________ Новак В.О.
Керівник _______________ Немов Р.Г.
Черкаси 2026
482 ЧДТУ 262259 14 2
123123123123123
Позначення Найменування Примітки
482 ЧДТУ. 262253 12 01 Текст програми
482 ЧДТУ. 262253 34 01 Інструкція користувачеві
482 ЧДТУ. 262253 90 01 Графічні матеріали
78
ДОДАТОК Б
Система оцінювання якості WEB-ресурсів
Текст програми
482 ЧДТУ. 262253 12 01
Листів 10
Розробник ________________ Новак В.О.
Черкаси 2026
482 ЧДТУ 262253 12 01 2
accessibility.ts
export function detectAccessibility() {
const issues: Array<{
priority: 'critical' | 'high' | 'medium' | 'low';
message: string;
recommendation: string;
value?: number | string;
}> = [];
let score = 100;
const images = document.querySelectorAll('img');
const imagesWithoutAlt = Array.from(images).filter(img => !img.alt ||
img.alt.trim() === '');
if (imagesWithoutAlt.length > 0) {
issues.push({
priority: imagesWithoutAlt.length > 5 ? 'critical' : 'high',
message: `${imagesWithoutAlt.length} зображень без alt-тексту`,
recommendation: 'Додайте осмислений alt для всіх <img>. Декоративні
– alt=""',
value: imagesWithoutAlt.length
});
score -= imagesWithoutAlt.length > 5 ? 20 : 10;
}
const interactiveElements = document.querySelectorAll('button, a,
input, select, textarea');
const withoutAccessibleName = Array.from(interactiveElements).filter(el
=> {
return !el.getAttribute('aria-label') &&
!el.getAttribute('aria-labelledby') &&
!el.textContent?.trim() &&
!el.getAttribute('title');
});
if (withoutAccessibleName.length > 0) {
issues.push({
priority: 'high',
message: `${withoutAccessibleName.length} інтерактивних елементів
без доступного імені`,
recommendation: 'Додайте aria-label або текст для кнопок/посилань
без видимого тексту',
value: withoutAccessibleName.length
});
score -= 15;
}
const lowContrastElements =
document.querySelectorAll('[style*="opacity"], [style*="color"],
[style*="background"]');
if (lowContrastElements.length > 20) {
issues.push({
priority: 'medium',
message: `Можливі проблеми з контрастністю
(${lowContrastElements.length} елементів зі стилем opacity/color)`,
recommendation: 'Перевірте контраст тексту/фону (WCAG 1.4.3),
використовуйте інструменти типу WebAIM Contrast Checker',
value: lowContrastElements.length
});
score -= 8;
80
482 ЧДТУ 262253 12 01 3
}
const htmlLang = document.documentElement.lang;
if (!htmlLang) {
issues.push({
priority: 'high',
message: 'Відсутній lang атрибут на <html>',
recommendation: 'Додайте <html lang="uk"> або відповідну мову',
});
score -= 10;
}
const headings = Array.from(document.querySelectorAll('h1, h2, h3, h4,
h5, h6'));
let prevLevel = 0;
for (const h of headings) {
const level = parseInt(h.tagName[1]);
if (level > prevLevel + 1) {
issues.push({
priority: 'medium',
message: 'Пропущені рівні заголовків (наприклад h1 → h3)',
recommendation: 'Використовуйте послідовну ієрархію: h1 → h2 →
h3',
});
score -= 5;
break;
}
prevLevel = level;
}
const priorityOrder: Record<'critical' | 'high' | 'medium' | 'low',
number> = {
critical: 0,
high: 1,
medium: 2,
low: 3,
};
issues.sort((a, b) => priorityOrder[a.priority] -
priorityOrder[b.priority]);
return {
score: Math.max(0, Math.round(score)),
issues,
details: {
imagesWithoutAlt: imagesWithoutAlt.length,
withoutAccessibleName: withoutAccessibleName.length,
hasLang: !!htmlLang,
}
};
}
performance.ts
interface LayoutShift {
value: number;
hadRecentInput: boolean;
lastInputTime: number;
entries: LayoutShiftAttribution[];
81
482 ЧДТУ 262253 12 01 4
}
interface LayoutShiftAttribution {
node?: Node;
previousRect: DOMRectReadOnly;
currentRect: DOMRectReadOnly;
}
export function detectPerformance() {
const issues: Array<{
priority: 'critical' | 'high' | 'medium' | 'low';
message: string;
recommendation: string;
value?: number | string;
}> = [];
let score = 100;
// Core Web Vitals
const fcpEntry = performance.getEntriesByName('first-contentful-
paint')[0] as PerformancePaintTiming | undefined;
const lcpEntry = performance.getEntriesByName('largest-contentful-
paint')[0] as LargestContentfulPaint | undefined;
const clsEntries = performance.getEntriesByType('layout-shift') as
unknown as LayoutShift[];
const fcp = fcpEntry?.startTime || 0;
const lcp = lcpEntry?.startTime || 0;
const cls = clsEntries.reduce((sum, entry) => sum + entry.value, 0);
// FCP
if (fcp > 1800) {
issues.push({
priority: fcp > 3000 ? 'high' : 'medium',
message: `FCP повільний: ${Math.round(fcp)} мс`,
recommendation: 'Оптимізуйте критичний CSS, використовуйте
preload/preconnect для шрифтів/скриптів',
value: Math.round(fcp)
});
score -= fcp > 3000 ? 20 : 10;
}
// LCP
if (lcp > 2500) {
issues.push({
priority: lcp > 4000 ? 'critical' : 'high',
message: `LCP повільний: ${Math.round(lcp)} мс`,
recommendation: 'Оптимізуйте найбільше зображення/текст (WebP/AVIF,
lazy, fetchpriority=high)',
value: Math.round(lcp)
});
score -= lcp > 4000 ? 25 : 15;
}
// CLS
if (cls > 0.1) {
issues.push({
priority: cls > 0.25 ? 'critical' : 'high',
message: `CLS високий: ${cls.toFixed(3)}`,
82
482 ЧДТУ 262253 12 01 5
recommendation: 'Усувайте зсуви макету: фіксуйте розміри
реклами/зображень, відкладіть завантаження шрифтів',
value: cls.toFixed(3)
});
score -= cls > 0.25 ? 20 : 12;
} else if (cls > 0.05) {
issues.push({
priority: 'medium',
message: `CLS помірний: ${cls.toFixed(3)}`,
recommendation: 'Зменшіть до <0.05 для ідеального користувацького
досвіду',
value: cls.toFixed(3)
});
score -= 6;
}
const loadTime = performance.timing?.loadEventEnd -
performance.timing?.navigationStart || 0;
if (loadTime > 5000) {
issues.push({
priority: 'medium',
message: `Повне завантаження сторінки: ${Math.round(loadTime)} мс`,
recommendation: 'Скоротіть до <3–4 с. Перевірте сторонні скрипти,
важкі ресурси',
value: Math.round(loadTime)
});
score -= 10;
}
const allResources = performance.getEntriesByType('resource') as
PerformanceResourceTiming[];
const slowResourcesList = allResources
.filter(r => r.duration > 1000)
.map(r => ({
name: r.name,
duration: r.duration
}));
const thirdPartyScriptsList = allResources
.filter(r => r.initiatorType === 'script' &&
!r.name.includes(location.hostname))
.map(r => ({
name: r.name
}));
const largeJSList = allResources
.filter(r => r.initiatorType === 'script' && r.transferSize > 100 *
1024)
.map(r => ({
name: r.name,
size: r.transferSize
}));
// Старі підрахунки (для сумісності)
const slowResources = slowResourcesList.length;
const thirdPartyScripts = thirdPartyScriptsList.length;
const largeJS = largeJSList.length;
83
482 ЧДТУ 262253 12 01 6
if (slowResources > 3) {
issues.push({
priority: 'high',
message: `Багато повільних ресурсів: ${slowResources} шт (>1 с)`,
recommendation: 'Оптимізуйте зображення, скрипти, CSS.
Використовуйте CDN, WebP, lazy loading',
value: slowResources
});
score -= 12;
}
if (thirdPartyScripts > 10) {
issues.push({
priority: 'medium',
message: `Багато сторонніх скриптів: ${thirdPartyScripts}`,
recommendation: 'Відкладіть завантаження (async/defer),
використовуйте self-hosted альтернативи',
value: thirdPartyScripts
});
score -= 8;
}
if (largeJS > 2) {
issues.push({
priority: 'medium',
message: `Великі JS-файли: ${largeJS} шт (>100 КБ)`,
recommendation: 'Розбийте бандл, використовуйте code splitting,
tree shaking',
value: largeJS
});
score -= 8;
}
const priorityOrder: Record<'critical' | 'high' | 'medium' | 'low',
number> = {
critical: 0,
high: 1,
medium: 2,
low: 3,
};
issues.sort((a, b) => priorityOrder[a.priority] -
priorityOrder[b.priority]);
return {
score: Math.max(0, Math.round(score)),
issues,
details: {
fcp: Math.round(fcp),
lcp: Math.round(lcp),
cls: cls.toFixed(3),
loadTime: Math.round(loadTime),
slowResources,
thirdPartyScripts,
largeJS,
slowResourcesList,
thirdPartyScriptsList,
largeJSList,
}
84
482 ЧДТУ 262253 12 01 7
};
}
seo-analyzer.ts
export function detectSEO() {
const issues: Array<{
priority: 'critical' | 'high' | 'medium' | 'low';
category: string;
message: string;
recommendation: string;
example?: string;
value?: number | string;
}> = [];
let score = 100;
const fcpEntry = performance.getEntriesByName('first-contentful-
paint')[0] as PerformancePaintTiming | undefined;
const lcpEntry = performance.getEntriesByName('largest-contentful-
paint')[0] as LargestContentfulPaint | undefined;
const fcp = fcpEntry?.startTime || 0;
const lcp = lcpEntry?.startTime || 0;
if (fcp > 1800) {
const penalty = fcp > 3000 ? 18 : 10;
issues.push({
priority: fcp > 3000 ? 'high' : 'medium',
category: 'Performance',
message: `FCP повільний: ${Math.round(fcp)} мс`,
recommendation: 'Оптимізуйте критичний CSS, використовуйте
preload/preconnect',
value: Math.round(fcp)
});
score -= penalty;
}
if (lcp > 2500) {
const penalty = lcp > 4000 ? 25 : 15;
issues.push({
priority: lcp > 4000 ? 'critical' : 'high',
category: 'Performance',
message: `LCP повільний: ${Math.round(lcp)} мс`,
recommendation: 'Оптимізуйте найбільше зображення/текст (WebP/AVIF,
lazy, fetchpriority=high)',
value: Math.round(lcp)
});
score -= penalty;
}
const title = document.title.trim();
if (!title) {
issues.push({ priority: 'critical', category: 'Title & Meta',
message: 'Відсутній title', recommendation: 'Додайте title 50–60
символів' });
score -= 12;
} else if (title.length < 30 || title.length > 70) {
issues.push({ priority: 'medium', category: 'Title & Meta', message:
`Title ${title.length} символів`, recommendation: 'Оптимально 50–60' });
score -= 6;
}
85
482 ЧДТУ 262253 12 01 8
const metaDescElement =
document.querySelector('meta[name="description"]');
const metaDesc = metaDescElement?.getAttribute('content')?.trim() ??
'';
const robotsElement = document.querySelector('meta[name="robots"]');
const robotsMeta =
robotsElement?.getAttribute('content')?.trim().toLowerCase() ?? '';
if (robotsMeta.includes('noindex')) {
issues.push({ priority: 'critical', category: 'Title & Meta',
message: 'noindex в robots meta', recommendation: 'Видаліть, якщо хочете
індексацію' });
score -= 20;
}
const h1Count = document.querySelectorAll('h1').length;
if (h1Count !== 1 && !location.hostname.includes('youtube.com')) {
issues.push({
priority: h1Count === 0 ? 'high' : 'medium',
category: 'Структура',
message: `${h1Count} тегів H1`,
recommendation: 'Рівно один H1'
});
score -= h1Count === 0 ? 10 : 5;
}
const isHttps = location.protocol === 'https:';
if (!isHttps) {
issues.push({
priority: 'critical',
category: 'Технічне SEO',
message: 'Сайт працює по HTTP',
recommendation: 'Перейдіть на HTTPS – це обов’язково для ранжування
Google',
});
score -= 15;
}
const viewportElement =
document.querySelector('meta[name="viewport"]');
const viewportContent = viewportElement?.getAttribute('content') ?? '';
const hasViewport = !!viewportElement &&
viewportContent.includes('width=device-width');
if (!hasViewport) {
issues.push({
priority: 'high',
category: 'Мобільність',
message: 'Відсутній або неправильний viewport meta tag',
recommendation: 'Додайте: <meta name="viewport"
content="width=device-width, initial-scale=1">',
});
score -= 10;
}
const wordCount = document.body.innerText.trim().split(/\s+/).filter(w
=> w.length > 0).length;
86
482 ЧДТУ 262253 12 01 9
const hasSchema =
!!document.querySelector('script[type="application/ld+json"]');
if (!hasSchema) {
issues.push({
priority: 'medium',
category: 'Розмітка',
message: 'Відсутня структурована розмітка schema.org',
recommendation: 'Додайте JSON-LD з типом Product, Article або
Organization',
});
score -= 5;
}
const priorityOrder: Record<'critical' | 'high' | 'medium' | 'low',
number> = {
critical: 0, high: 1, medium: 2, low: 3,
};
issues.sort((a, b) => priorityOrder[a.priority] -
priorityOrder[b.priority]);
return {
score: Math.max(0, Math.round(score)),
issues,
details: {
metaDescription: metaDesc, // ← додано
hasRobotsMeta: !!robotsElement, // ← додано
isHttps,
fcp: Math.round(fcp),
lcp: Math.round(lcp),
titleLength: title.length,
metaDescLength: metaDesc.length,
wordCount,
h1Count,
hasSchema,
hasViewport,
}
};
}
Scanner.ts for tech-detector
import { TechnologyResult } from './types';
import { technologies } from '@/lib/tech-detector/rules';
export async function detectTechnologies(): Promise<Record<string,
TechnologyResult[]>> {
const results: TechnologyResult[] = [];
const seen = new Set<string>();
const scan = () => {
for (const rule of technologies) {
if (seen.has(rule.name)) continue;
let confidence = 0;
let version: string | undefined = undefined;
for (const check of rule.strongChecks) {
const res = check();
if (res.match) {
87
482 ЧДТУ 262253 12 01 10
confidence += 60;
if (res.version) version = res.version;
}
}
for (const check of rule.weakChecks) {
if (check()) confidence += 35;
}
if (confidence >= 30) {
results.push({
name: rule.name,
version,
confidence: Math.min(100, confidence),
category: rule.category,
});
seen.add(rule.name);
}
}
};
await new Promise<void>(resolve => {
if (document.readyState === 'complete') {
resolve();
} else {
window.addEventListener('load', () => resolve(), { once: true });
}
});
scan();
const observer = new MutationObserver(() => scan());
observer.observe(document.documentElement, {
childList: true,
subtree: true,
attributes: true,
});
setTimeout(() => observer.disconnect(), 10000);
const grouped: Record<string, TechnologyResult[]> = {};
for (const res of results) {
if (!grouped[res.category]) grouped[res.category] = [];
grouped[res.category].push(res);
}
console.log('[DETECTOR] Знайдені технології:', JSON.stringify(grouped,
null, 2));
return grouped;
}
88
ДОДАТОК В
Система оцінювання якості WEB-ресурсів
Інструкція користувачеві
482 ЧДТУ. 262253 34 01
Листів 6
Розробник ________________ Новак В.О.
Черкаси 2026
482 ЧДТУ 262253 34 01 2
Після встановлення розширення Page Analyzer у браузер Google Chrome воно
автоматично з’явиться у панелі розширень.
При першому запуску розширення користувачу відкривається головне меню
(Рисунок В.1). У цьому меню відображаються основні можливості розширення та
кнопка для запуску аналізу.
Рисунок В.1 – Головне меню розширення Page Analyzer
Користувач може натиснути велику кнопку «Загальний аналіз», щоб
розпочати аналіз поточної веб-сторінки. Також є можливість оновити аналіз пізніше
за допомогою кнопки «Оновити аналіз».
90
482 ЧДТУ 262253 34 01 3
Після завершення аналізу користувач отримує доступ до чотирьох основних
розділів:
– Технології
– SEO
– Продуктивність
– Доступність
Рисунок В.2 – Загальний вигляд результатів аналізу
Перехід між розділами здійснюється за допомогою кнопок у головному меню.
Кожен розділ містить загальну оцінку у відсотках та детальну інформацію.
91
482 ЧДТУ 262253 34 01 4
У розділі SEO користувач може переглянути основні SEO-показники
сторінки, включаючи наявність title, meta description, robots meta та інше. При
натисканні на блок «Meta Description» відкривається повний текст опису (Рисунок
В.3).
Рисунок В.3 – Розгорнутий блок Meta Description
У розділі Продуктивність відображаються ключові метрики Core Web Vitals
(FCP, LCP, CLS), а також списки повільних ресурсів, сторонніх скриптів та великих
JS-файлів. Користувач може розгорнути кожен блок для перегляду детальної
інформації та скопіювати URL ресурсу одним кліком (Рисунок В.4).
92
482 ЧДТУ 262253 34 01 5
Рисунок В.4 – Розділ «Продуктивність» з розгорнутими списками
У розділі Доступність показується оцінка відповідності сторінки стандартам
доступності, кількість зображень без alt-атрибутів та інші проблеми.
У розділі Технології користувач може переглянути список усіх технологій, які
використовує поточний сайт, згрупованих за категоріями.
У будь-якому розділі користувач може натиснути кнопку «Оновити аналіз»,
щоб повторно проаналізувати поточну сторінку.
93
482 ЧДТУ 262253 34 01 6
Рисунок В.5 – Кнопка «Оновити аналіз»
Після завершення роботи з розширенням користувач може закрити
спливаюче вікно. Розширення залишається активним і готовим до використання на
будь-якій іншій веб-сторінці.
94
ДОДАТОК Г
Система оцінювання якості WEB-ресурсів
Графічні матеріали
482 ЧДТУ. 262253 90 01
Листів 12
Розробник ________________ Новак В.О.
Черкаси 2026
482 ЧДТУ 262253 90 01 2
Рисунок Г.1 – Слайд 1
Рисунок Г.2 – Слайд 2
96
482 ЧДТУ 262253 90 01 3
Рисунок Г.3 – Слайд 3
Рисунок Г.4 – Слайд 4
97
482 ЧДТУ 262253 90 01 4
Рисунок Г.5 – Слайд 5
Рисунок Г.6 – Слайд 6
98
482 ЧДТУ 262253 90 01 5
Рисунок Г.7 – Слайд 7
Рисунок Г.8 – Слайд 8
99
482 ЧДТУ 262253 90 01 6
Рисунок Г.9 – Слайд 9
Рисунок Г.10 – Слайд 10
100
482 ЧДТУ 262253 90 01 7
Рисунок Г.11 – Слайд 11
Рисунок Г.12 – Слайд 12
101
482 ЧДТУ 262253 90 01 8
Рисунок Г.13 – Слайд 13
Рисунок Г.14 – Слайд 14
102
482 ЧДТУ 262253 90 01 9
Рисунок Г.15 – Слайд 15
Рисунок Г.16 – Слайд 16
103
482 ЧДТУ 262253 90 01 10
Рисунок Г.17 – Слайд 17
Рисунок Г.18 – Слайд 18
104
482 ЧДТУ 262253 90 01 11
Рисунок Г.19 – Слайд 19
Рисунок Г.20 – Слайд 20
105
482 ЧДТУ 262253 90 01 12
Рисунок Г.21 – Слайд 21
Рисунок Г.22 – Слайд 22
106