Використовувати Lighthouse можна в різних робочих середовищах залежно від потреб.

Спосіб А. Через Chrome DevTools (Найпопулярніший)

Цей спосіб ідеально підходить для локального тестування під час розробки сайту.

1. Відкрити сайт в Chrome.
2. Натиснути F12 (або Ctrl + Shift + I) та перейти на вкладку Lighthouse.
3. Обрати тип пристрою (Mobile або Desktop).
4. Натиснути Analyze page load.

Спосіб Б. Через PageSpeed Insights (Хмарна версія)

Якщо сайт вже задеплоєний (наприклад, на Vercel чи GitHub Pages), найкраще протестувати його через онлайн-сервіс від Google.

1. Перейти на сайт pagespeed.web.dev.
2. Вставити публічну URL-адресу вашого сайту.
3. Натиснути "Аналізувати". PageSpeed Insights використовує двигун Lighthouse на віддалених серверах Google.

Спосіб В. Через термінал командного рядка (Для автоматизації)

Професійні розробники інтегрують Lighthouse в свої консольні скрипти перед деплоєм проєкту.

1. Переконатися, що на комп'ютері встановлено Node.js.
2. Встановити Lighthouse глобально: npm install -g lighthouse
3. Запустити аудит сайту прямо з терміналу: lighthouse [https://example.com](https://example.com) --view
4. Після завершення аналізу в браузері автоматично відкриється локальний HTML-звіт.

Після запуску аналізу сайту, інструмент генерує звіт, що складається з п'яти основних розділів:

1. Performance (Продуктивність/Швидкість)

Це найважливіша категорія для UX (User Experience). Вона оцінює, наскільки швидко завантажується сторінка, як скоро користувач може почати взаємодіяти з нею та чи не «скачуть» елементи інтерфейсу під час завантаження.

Швидкість завантаження безпосередньо корелює з показником конверсії. Якщо сайт вантажиться довше 3 секунд, понад 50% користувачів просто закривають вкладку.

2. Accessibility (Доступність)

Цей аудит перевіряє, наскільки сайт є зручним для людей з обмеженими можливостями (наприклад, з вадами зору чи моторики).

Перевіряється наявність контрастності між текстом і тлом, наявність атрибутів alt для зображень, правильна ієрархія заголовків (h1-h6), а також можливість навігації сайтом за допомогою однієї лише клавіатури.

3. Best Practices (Найкращі практики)

Оцінює технічну відповідність коду сучасним стандартам вебсервісів та безпеки.

Перевіряється використання безпечного протоколу HTTPS, відсутність застарілих API або бібліотек (наприклад, старих вразливих версій jQuery), безпека зовнішніх посилань (наприклад, rel="noopener").

4. SEO (Search Engine Optimization/Пошукова оптимізація)

Перевіряє, чи сторінка є оптимізованою для пошукових роботів (Google, Bing тощо), щоб сайт міг займати вищі позиції в пошуковій видачі.

Перевіряється наявність тегу <meta name="description">, метатегу viewport для мобільних пристроїв, коректність файлу robots.txt та індексованість посилань.

5. PWA (Progressive Web App)

Перевіряє, чи відповідає сайт стандартам прогресивних вебдодатків, тобто чи може користувач встановити його на екран смартфона як звичайний додаток і працювати з ним офлайн.

В категорії Performance оцінка сторінки утворюється на основі кількох складних метрик. Google об'єднує найважливіші з них в групу Core Web Vitals.

• FCP First Contentful Paint. Час, за який на екрані з'являється перший візуальний елемент (текст чи логотип). Ідеальний показник <1.8 сек.
• LCP Largest Contentful Paint. Час, за який завантажується найбільший видимий блок (наприклад, велике фонове зображення в Hero-секції). Ідеальний показник <2.5 сек.
• TBT Total Blocking Time. Час між першим рендером (FCP) та повною інтерактивністю сторінки, коли головний потік браузера заблокований важкими JS-скриптами. Ідеальний показник <150 мс.
• CLS Cumulative Layout Shift. Показник візуальної стабільності. Вимірює, чи не зміщуються кнопки або блоки тексту в процесі завантаження (наприклад, коли завантажується реклама чи картинка без вказаних розмірів). Ідеальний показник <0.1.

Якщо після тестування оцінки сайту опинилися в «червоній» (0-49) або «жовтій» (50-89) зонах, потрібно виконати наступні кроки для оптимізації.

Крок 1. Оптимізувати зображення (Найчастіша проблема)

Важкі картинки в форматі .jpg чи .png розміром понад 1 МБ блокують завантаження.

1. Конвертувати зображення в сучасні формати WebP або AVIF (вони важать на 70% менше без втрати якості).
2. Використовувати відкладене завантаження: <img src="photo.jpg" loading="lazy">.

Крок 2. Скоротити блокування головного потоку (TBT)

Сторінка завантажилася, але інтерфейс зависає, а кнопки не клікаються через виконання важких JS-файлів.

1. Завантажувати сторонні скрипти (метрики, аналітику, чати) асинхронно за допомогою атрибутів defer або async: <script src="analytics.js" defer></script>
2. Якщо підключати бібліотеки через CDN (як в ЛР №10), переконатися, що підключаються мініфіковані версії файлів (вони мають суфікс .min.js).

Крок 3. Налаштувати відображення шрифтів

Поки завантажується кастомний шрифт з Google Fonts, текст на сторінці взагалі не відображається (ефект невидимого тексту).

1. Додавати параметри відображення шрифтів в стилі CSS або при підключенні шрифтів через тег <link>

@font-face {
	font-family: 'MyFont';
	src: url('myfont.woff2') format('woff2');
	font-display: swap; /* Браузер покаже стандартний шрифт, поки завантажується кастомний */
}

Міжнародний стандарт WCAG (Web Content Accessibility Guidelines) базується на чотирьох фундаментальних принципах (POUR).

1. Perceivable (Сприйнятливість). Інформація та інтерфейс мають бути представлені в такому вигляді, щоб користувачі могли їх легко помітити (наприклад, альтернативний текст для аудіо та зображень).
2. Operable (Керованість). Користувачі повинні мати можливість керувати інтерфейсом (всі інтерактивні елементи мають бути доступні з клавіатури).
3. Understandable (Зрозумілість). Вміст сайту та робота інтерфейсу мають бути легкими для розуміння.
4. Robust (Надійність). Код має бути сумісним з різноманітними допоміжними технологіями (наприклад, різними скрінрідерами) тепер і в майбутньому.

Оцінювання доступності в Google Lighthouse фокусується на кількох критичних моментах автоматичної перевірки коду.

1. Колірний контраст (Color Contrast)

Текст повинен мати достатній контраст з фоном, щоб його могли прочитати люди зі зниженою гостротою зору.

• Стандарт WCAG AA. Контрастність має бути не менше 4.5:1 для звичайного тексту та 3:1 для великого тексту.
  • Уникати світло-сірого тексту на білому тлі. Використовувати інструмент піпетки в Chrome DevTools для перевірки відповідності коефіцієнта контрастності.

2. Семантичний HTML проти "div-мішанини"

Скрінрідери орієнтуються за тегами. Якщо сайт побудовано виключно на <div> та <span>, незрячий користувач ніколи не зрозуміє структуру сторінки.

Неправильно (Наївно)

<!-- Скрінрідер прочитає це просто як звичайний текст і не надасть можливості клікнути з клавіатури -->
<div class="btn-submit" onclick="submitForm()">Надіслати</div>

Правильно (Семантично)

<!-- Браузер автоматично додає фокус та можливість натискання через Enter/Space -->
<button type="submit" class="bg-indigo-600 hover:bg-indigo-700 text-white font-bold py-2 px-4 rounded">
	Надіслати
</button>

Використовувати структурні теги: <header>, <nav>, <main>, <section>, &lt;article&gt;, <footer>. Вони створюють орієнтири для швидкої навігації.

3. Альтернативний текст для медіафайлів (alt атрибути)

Зображення без опису для скрінрідера є невидимою пусткою. Програма просто озвучить назву файлу (наприклад, "IMG_49201_final.jpg").

Погано: <img src="coffee-cup.png">

Добре: <img src="coffee-cup.png" alt="Біла чашка гарячого капучино з малюнком серця на пінці">

Якщо картинка суто декоративна (наприклад, фоновий візерунок), залишити атрибут порожнім, щоб скрінрідер його проігнорував: alt="".

4. Керування фокусом клавіатури та :focus стилі

Багато користувачів переміщуються сайтом за допомогою клавіші Tab. При цьому вони повинні чітко бачити, на якому елементі зараз знаходяться.

Велика помилка дизайну

/* Ніколи не видаляйте контур фокусу без заміни на кастомний! */
*:focus {
	outline: none;
}

Правильний підхід (Кастомізація)

/* Видаляємо дефолтний контур і робимо свій, красивий та помітний */
a:focus-visible, button:focus-visible {
	outline: 3px solid #d57843;
	outline-offset: 2px;
}

5. Використання ARIA-атрибутів (Accessible Rich Internet Applications)

Якщо стандартних тегів HTML недостатньо для опису складної динамічної логіки, використовуються спеціальні aria-* атрибути.

• aria-label. Надає текстовий опис елементу, якщо він не має видимого тексту (наприклад, іконка закривання модального вікна).
  • <button aria-label="Закрити модальне вікно" onclick="closeModal()">×</button>
• aria-expanded. Показує скрінрідеру, чи розгорнуте зараз випадне меню або акордеон.
  • <button aria-expanded="false" onclick="toggleMenu()">Меню</button>
• aria-hidden="true". Ховає іконки або декоративні елементи від скрінрідера, щоб не засмічувати аудіопотік користувача.

Процес CI/CD зазвичай розділяють на три логічні фази:

 [ Написання коду ] 
         │
         ▼
 ┌─────────────────────────────────────────┐
 │       CI (Continuous Integration)       │  <-- Автоматична збірка та тестування
 └────────────────────┬────────────────────┘
                      │
                      ▼
 ┌─────────────────────────────────────────┐
 │        CD (Continuous Delivery)         │  <-- Готовність до релізу (ручне підтвердження)
 └────────────────────┬────────────────────┘
                      │
                      ▼
 ┌─────────────────────────────────────────┐
 │       CD (Continuous Deployment)        │  <-- Повністю автоматичний реліз на продакшн
 └─────────────────────────────────────────┘

CI — Continuous Integration (Безперервна інтеграція)

Це практика автоматичного злиття робочих копій коду розробників в загальну головну гілку (наприклад, main на GitHub) кілька разів на день.

• Щойно розробник робить git push, спеціальний хмарний сервер автоматично завантажує цей код, запускає процес збирання (build) та виконує автоматичні тести (unit-тести, лінтери* для перевірки стилю коду).
• Головною метою є миттєво виявити конфлікти або помилки (баги) в коді до того, як вони потраплять до загального проєкту.

*Лінтер (Linter, lint) — інструмент для дослідження програмного коду з метою виявлення помилок програмування, вад, порушень стилю, а також сумнівних чи підозрілих виразів.

CD — Continuous Delivery (Безперервна доставка)

Цей етап є продовженням інтеграції. Він гарантує, що після успішного проходження всіх тестів код автоматично збирається в готовий до релізу артефакт (наприклад, скомпільовану папку сайту).

Розгортання (деплой) на живий сервер здійснюється вручну — шляхом натискання кнопки менеджером або лідом проєкту після фінальної перевірки.

CD — Continuous Deployment (Безперервне розгортання)

Це найвищий рівень автоматизації. Кожна зміна, яка успішно пройшла всі етапи тестування та інтеграції (CI), автоматично публікується в реальному часі на боці кінцевого користувача (production) без будь-якого втручання людини.

Саме за таким принципом працюють хмарні платформи Vercel та Netlify, які використано в лабораторних роботах.

Пайплайн (Pipeline) — це послідовність кроків, які має пройти код від моменту написання до публікації. Для прикладу розглянемо життєвий цикл оновлення кавового віджета з ЛР №11:

1. Код (Code). Ви локально в VS Code змінили ціну еспресо в файлі widget.js.
2. Фіксація (Commit). Ви зафіксували зміни через Git: git commit -m "fix: оновлено ціну еспресо".
3. Пуш (Push). Ви відправили комміт в хмару: git push origin main.
4. Тригер (Trigger). GitHub отримує push і через механізм Webhooks миттєво сповіщає провайдера деплою (наприклад, Vercel).
5. Збірка (Build). Хмарний контейнер Vercel завантажує код, встановлює залежності, оптимізує картинки та перевіряє код на помилки.
6. Тест (Test). (Якщо налаштовано) Запускаються автоматичні перевірки швидкості (Lighthouse CI) та доступності.
7. Розгортання (Deploy). Зібрані статичні файли роздаються на мережу CDN-серверів. Сайт оновлено.

В індустрії використовується величезна кількість інструментів автоматизації.

• Vercel & Netlify. Найкращі хмарні платформи для швидкого та безкоштовного розгортання статичних фронтенд-сайтів (HTML/CSS/JS/React). Вони мають вбудований, повністю автоматизований "Zero-Config" CI/CD конвеєр.
• GitHub Actions. Вбудований безпосередньо в GitHub інструмент автоматизації. Можна описати власний пайплайн в файлі .github/workflows/deploy.yml за допомогою мови YAML (наприклад, автоматично деплоїти сайт на GitHub Pages).
• Jenkins. Класичний інструмент автоматизації з відкритим вихідним кодом. Використовується у великих enterprise-проєктах, де потрібне дуже складне та гнучке налаштування інфраструктури.
• GitLab CI/CD. Потужна вбудована система автоматизації від платформи GitLab.

Переваги CI/CD (Зв'язок з ЛР №8, 10, 11)

1. Швидкість і відсутність рутини. Замість того, щоб копіювати файли вручну, можна просто зробити один git push, і за хвилину сайт оновлюється сам.
2. Контроль якості (QA). Завдяки автоматичній інтеграції, якщо допущено критичну синтаксичну помилку в JavaScript, збірка на Vercel завершиться помилкою (Build Failed), захищаючи "живий" сайт від падіння.
3. Версійність та відкат релізів. Якщо після деплою виявився баг, хмарні сервіси надають можливість миттєво (в один клік) зробити відкат (Rollback) до попереднього успішного коміту.

QR-код (Quick Response Code) — це двовимірний матричний штрих-код. На відміну від класичного лінійного штрих-коду, QR-код кодує інформацію як по горизонталі, так й по вертикалі, що надає можливість зберігати в сотні разів більше даних (до 7089 цифрових символів або до 4296 альфа-нумеричних знаків).

QR Code Generator (Генератор QR-кодів) — це програмний інструмент або бібліотека, яка приймає вхідні дані (текст, URL-адресу, контакти) і за певним математичним алгоритмом перетворює їх на матрицю з чорних та білих квадратів (пікселів), додаючи службові маркери для розпізнавання камерою.

Що можна закодувати в QR-код:

• Посилання (URL). Автоматичний перехід на сайт (найпопулярніший сценарій).
• Текст. Нотатки, промокоди, вірші.
• Дані Wi-Fi. Назва мережі та пароль для автоматичного підключення смартфона.
• Контакти (vCard). Ім'я, телефон та емейл, які миттєво зберігаються в телефонну книгу.
• Геолокація. Координати на картах Google Maps.

Створити власний генератор на вебсторінці дуже просто. Для цього не потрібно самостійно вимальовувати квадрати через математичні формули — в індустрії використовують готові та перевірені JS-бібліотеки. Найпопулярніша з них — qrcode.js або її сучасний аналог QRCode.js.

Нижче описано процес створення робочої сторінки з генератором.

HTML структура (index.html)

HTML
<!DOCTYPE html>
<html lang="uk">
	<head>
		<meta charset="UTF-8">
		<meta name="viewport" content="width=device-width, initial-scale=1.0">
		<title>Мій Генератор QR-кодів</title>
		<script src="https://cdn.jsdelivr.net/npm/@tailwindcss/browser@4"></script>
	</head>
	<body class="bg-gray-100 flex flex-col items-center justify-center min-h-screen p-6">
		<div class="bg-white p-8 rounded-xl shadow-md max-w-md w-full text-center">
			<h1 class="text-2xl font-bold text-gray-800 mb-6">Генератор QR-кодів</h1>

			<input type="text" id="qr-text" placeholder="Введіть посилання або текст" 
			class="w-full px-4 py-2 border border-gray-300 rounded-lg mb-4 focus:outline-none focus:ring-2 focus:ring-indigo-500">

			<button id="generate-btn" class="w-full bg-indigo-600 text-white font-semibold py-2 rounded-lg hover:bg-indigo-700 transition">
				Згенерувати код
			</button><
			div id="qrcode" class="mt-6 flex justify-center min-h-[256px] items-center bg-gray-50 border border-dashed border-gray-200 rounded-lg p-4">
				<p class="text-gray-400 text-sm">Тут з'явиться ваш QR-код</p>
			</div>
		</div><script src="https://cdnjs.cloudflare.com/ajax/libs/qrcodejs/1.0.0/qrcode.min.js"></script>
	<script src="app.js"></script>
	</body>
</html>

JavaScript логіка (app.js)

JavaScript
const qrTextInput = document.getElementById('qr-text');
const generateBtn = document.getElementById('generate-btn');
const qrContainer = document.getElementById('qrcode');

// Ініціалізуємо змінну для збереження екземпляра QR-коду
let qrCodeInstance = null;

generateBtn.addEventListener('click', () => {
    const textValue = qrTextInput.value.trim();

    if (!textValue) {
        alert('Будь ласка, введіть якийсь текст або URL-адресу!');
        return;
    }

    // Очищаємо початковий текстовий заглушку перед першою генерацією
    qrContainer.innerHTML = '';

    if (qrCodeInstance === null) {
        // Створюємо новий об'єкт QR-коду всередині контейнера
        qrCodeInstance = new QRCode(qrContainer, {
            text: textValue,
            width: 256,
            height: 256,
            colorDark : "#000000",   // Колір точок
            colorLight : "#ffffff",  // Колір фону
            correctLevel : QRCode.CorrectLevel.H // Високий рівень корекції помилок (дозволяє коду зчитуватися навіть при пошкодженні)
        });
    } else {
        // Якщо об'єкт уже створено, просто оновлюємо його дані (це швидше для браузера)
        qrCodeInstance.clear();
        qrCodeInstance.makeCode(textValue);
    }
});

Працювати з готовим додатком дуже просто завдяки інтуїтивному UX.

1. Введення даних. Користувач копіює потрібне посилання (наприклад, лінк на задеплоєний проєкт на Vercel https://my-project.vercel.app) та вставляє його в текстове поле.
2. Генерація. Після натискання кнопки "Згенерувати код", бібліотека миттєво обчислює матрицю та рендерить її на екрані у вигляді тегу <canvas> або картинки <img>.
3. Зчитування. Будь-яка інша людина наводить камеру свого смартфона на екран. Алгоритми розпізнавання в iOS або Android фокусуються на трьох великих квадратах в кутах (вони потрібні для визначення орієнтації та кута нахилу) і миттєво відкривають посилання в браузері.

Реалізований приклад (відкрити в новому вікні)

Основні покращення та особливості створеної сторінки:

• Сучасна UI/UX архітектура. Створено адаптивну двоколонкову панель. Зліва користувач налаштовує параметри (введення тексту, вибір темного кольору, вибір світлого фону, розміри QR та рівні корекції помилок). Справа в реальному часі відображається результат.
• Видалено всі системні вікна alert(), замість них створено плаваючі кастомні спливаючі повідомлення (toasts). Всі кнопки й елементи керування мають виразні фокусні стилі.
• Додано можливість вибору кольору QR-коду (темних та світлих точок), вибору рівня корекції помилок (L, M, Q, H) та зміни розміру в реальному часі.
• Додано робочу логіку для копіювання вихідних даних або безпосереднього завантаження готового QR-коду в форматі .png на пристрій користувача.
• Збереження останніх трьох створених QR-кодів (в пам'яті сесії) для швидкого повторного перегляду. Студенти можуть знайти їх в історії, щоб швидко завантажити або змінити.

• Google Lighthouse — автоматизований інструмент, що призначений для комплексного технічного аудиту вебсторінок за показниками продуктивності, доступності, відповідності найкращим практикам розробки та пошукової оптимізації (SEO).
• Core Web Vitals — набір ключових метрик веб-ефективності, які відображають реальний досвід користувача (швидкість завантаження, візуальну стабільність та інтерактивність сторінки).
• FCP (First Contentful Paint) — час, за який на екрані користувача з'являється перший візуальний елемент інтерфейсу (наприклад, текст, логотип або графічний блок). Ідеальним вважається показник менше 1.8 секунди.
• LCP (Largest Contentful Paint) — час, необхідний для повного завантаження найбільшого видимого елемента в полі зору користувача (найчастіше це головне фонове зображення або великий заголовок Hero-секції). Еталонне значення — менше 2.5 секунди.
• TBT (Total Blocking Time) — сумарний час між початком рендерингу вмісту (FCP) та повною інтерактивністю сторінки, протягом якого головний потік браузера заблокований тривалим виконанням скриптів. Показник становити менше 150 мілісекунд.
• CLS (Cumulative Layout Shift) — метрика візуальної стабільності, яка вимірює суму всіх раптових зсувів макета сторінки під час завантаження (наприклад, коли блоки тексту чи кнопки «скачуть» через динамічне підвантаження картинок або реклами без вказаних розмірів). Ідеальний показник — менше 0.1.
• SEO (Search Engine Optimization) — комплекс заходів та технічних налаштувань вебсторінки (метатеги опису, оптимізація під мобільні пристрої, файли інструкцій для роботів), спрямований на покращення видимості сайту в пошукових системах.
• PageSpeed Insights — офіційний хмарний онлайн-сервіс від Google, який використовує двигун Lighthouse на віддалених серверах для аналізу продуктивності сайтів за публічними URL-адресами.

• Accessibility/a11y — практика проєктування та розробки цифрових продуктів, яка гарантує, що вебсайтом можуть повноцінно користуватися абсолютно всі люди, включно з користувачами з постійними чи тимчасовими обмеженнями здоров'я (вади зору, слуху, моторики або когнітивні розлади). Число 11 в абревіатурі означає кількість літер між «A» та «Y» в англійському слові Accessibility.
• WCAG (Web Content Accessibility Guidelines) — міжнародний стандарт та збірка рекомендацій щодо забезпечення доступності вебконтенту, що базується на чотирьох принципах POUR: сприйнятливість, керованість, зрозумілість та надійність.
• Скрінрідер (Screen Reader) — спеціалізоване програмне забезпечення (екранний диктор), яке зчитує та вголос озвучує текстовий вміст та інтерфейсні елементи на екрані пристрою для незрячих користувачів.
• Семантичний HTML — підхід до верстки, за якого використовуються теги відповідно до їх змістовного призначення (<header>, <nav>, <main>, <button>), а не універсальні контейнери-заглушки (<div>, <span>). Створює чітку логічну карту сторінки для пошукових роботів та скрінрідерів.
• Коефіцієнт контрастності (Color Contrast) — співвідношення яскравості кольору тексту та кольору його фону. За стандартом WCAG AA для звичайного тексту цей коефіцієнт має становити не менше 4.5:1, щоб інформація залишалася читабельною для людей зі слабким зором.
• ARIA (Accessible Rich Internet Applications) — набір спеціальних атрибутів (наприклад, aria-label, aria-expanded, aria-hidden), що додаються до HTML-тегів для надання допоміжним технологіям розширеної інформації про стан та логіку динамічних елементів, які неможливо описати стандартними тегами.
• Фокус клавіатури (:focus-visible) — стан інтерактивного елемента (посилання, кнопки, поля вводу), коли він виділяється візуальним контуром під час навігації по сайту виключно за допомогою клавіатури (клавіша Tab).

• DevOps — набір практик, інструментів і принципів, який об'єднує процеси розробки (Development) та експлуатації (Operations) для швидкого, надійного й автоматизованого створення, тестування, розгортання та супроводу програмних продуктів.
• CI/CD — сучасна інженерна методологія та набір практик, спрямованих на повну автоматизацію процесів інтеграції нового коду, його тестування, збирання та розгортання на серверах.
• CI (Continuous Integration/Безперервна інтеграція) — практика регулярного автоматичного злиття робочого коду всіх розробників в головну гілку репозиторію, під час якого на хмарному сервері запускаються лінтери, автоматичні тести та тестова збірка (build) для миттєвого виявлення багів.
• Continuous Delivery (Безперервна доставка) — етап автоматизації, який гарантує, що після успішного проходження CI-тестів код автоматично компилюється в готовий до релізу артефакт, але саме розгортання (деплой) на «живий» сервер запускається вручну відповідальною особою.
• Continuous Deployment (Безперервне розгортання) — найвищий рівень автоматизації конвеєра, за якого будь-яка зміна в коді, що пройшла всі етапи перевірок, автоматично і в реальному часі оновлюється на серверах для кінцевих користувачів без ручного втручання людини.
• Пайплайн (Pipeline/Конвеєр) — чітко налаштована послідовність автоматичних кроків (Code --> Commit --> Push --> Trigger --> Build --> Test --> Deploy), яку проходить програмний код від моменту його фіксації в Git до публікації на хостингу.
• GitHub Actions — вбудований безпосередньо в платформу GitHub інструмент автоматизації робочих процесів (workflows), що налаштовується за допомогою файлів конфігурації в форматі YAML.
• Деплой (Deployment/Розгортання) — процес перенесення скомпільованих та перевірених файлів проєкту з локального комп'ютера розробника або хмарного середовища на віддалений публічний сервер (хостинг), роблячи вебсайт доступним в Інтернеті.
• Відкат релізів (Rollback) — операція миттєвого повернення стану працюючого вебсайту до попереднього успішного коміту/версії в разі виявлення критичної помилки після автоматичного деплою.
• Лінтер (Linter) — це автоматичний "перевіряльник" коду, який автоматично аналізує вихідний код і знаходить помилки, потенційні проблеми, порушення правил оформлення та невідповідність стандартам програмування без виконання програми.
• QR Code (Quick Response Code) — двовимірний матричний штрих-код, який кодує інформацію (найчастіше URL-посилання) як по горизонталі, так і по вертикалі, що надає можливість зберігати великі обсяги даних і швидко розпізнавати їх камерою смартфона.