Розробка favicon та touch-іконок
Часто сайт чудово виглядає на десктопі, але на мобільних пристроях іконка в закладках або на робочому столі виявляється розмитою або обрізається. Усе тому, що для кожної платформи потрібен свій розмір і формат. Нерідко розробники забувають про іконки для PWA, і застосунок не проходить перевірку Lighthouse. Або використовують один favicon.ico для всього, а на Retina він мильний. Ми вирішуємо ці проблеми за вас. Наші інженери мають 10+ років досвіду у веб-розробці та підготували понад 500 наборів іконок для сайтів та PWA.
Які розміри та формати потрібні для сучасних браузерів?
Сучасний набір favicon — це не один файл, а цілий артефакт для різних сценаріїв. Ось мінімальний перелік файлів, які мають бути на сайті:
| Файл |
Розмір |
Призначення |
| favicon.ico |
16×16, 32×32 (multi-size) |
Браузери, зворотна сумісність |
| favicon-16x16.png |
16×16 |
Chrome, адресний рядок |
| favicon-32x32.png |
32×32 |
Safari, Retina |
| apple-touch-icon.png |
180×180 |
iOS "додати на екран" |
| android-chrome-192x192.png |
192×192 |
Android Chrome |
| android-chrome-512x512.png |
512×512 |
PWA splash screen |
| mstile-150x150.png |
150×150 |
Windows плитка |
| safari-pinned-tab.svg |
SVG |
Safari Pinned Tab |
Якщо ви використовуєте PWA, обов'язково додайте маніфест із правильними посиланнями. Детальніше про маніфест на developer.mozilla.org.
Автоматична генерація набору в 3 рази швидша, ніж ручна підготовка кожного файлу.
Чому важлива підтримка maskable-іконок для Android?
Android адаптує іконки під різні форми — коло, округлений квадрат. Без атрибута "purpose": "maskable" система може обрізати іконку непередбачувано. Щоб цього уникнути, вихідник повинен мати безпечну зону: відступ у 40 пікселів від країв для розміру 512×512. У маніфесті це виглядає так:
{
"icons": [
{ "src": "/android-chrome-192x192.png", "sizes": "192x192", "type": "image/png" },
{ "src": "/android-chrome-512x512.png", "sizes": "512x512", "type": "image/png", "purpose": "any maskable" }
]
}
Що входить у роботу?
Ми готуємо повний комплект для вашого сайту:
- Вихідний SVG-файл із правильними пропорціями та безпечною зоною для maskable.
- Усі необхідні растрові файли (від 16×16 до 512×512) у PNG та ICO.
- Коректний маніфест
manifest.json із зазначенням усіх іконок та їх purpose.
- Мета-теги для
<head>: apple-touch-icon, icon, msapplication-Tile, safari-pinned-tab.
- Перевірка на реальних пристроях iOS, Android, Windows та в різних браузерах.
- Консультація щодо інтеграції та підтримка після впровадження.
Як ми готуємо набір: покроковий процес
- Аналіз вихідного логотипу. Перевіряємо, чи підходить він для маленьких розмірів. Якщо ні — спрощуємо контури.
- Створення SVG-джерела. Малюємо або адаптуємо логотип у векторі з запасом для maskable.
- Автоматична генерація всього набору. Використовуємо RealFaviconGenerator та кастомні скрипти для консистентності.
- Налаштування manifest.json. Прописуємо шляхи, purpose, maskable, sizes.
- Вставка мета-тегів у
<head>. Усі 8 варіантів, включаючи msapplication-Tile та apple-touch-icon.
- Перевірка на реальних пристроях. Тестуємо на iOS, Android, Windows та в браузерах.
Типові помилки та як їх уникнути
| Помилка |
Наслідок |
Рішення |
| Пропуск apple-touch-icon 180×180 |
Іконка на iOS не відображається |
Обов'язково включити 180×180 PNG з мета-тегом apple-touch-icon |
| Неправильний шлях у маніфесті |
PWA не завантажує іконки |
Переконатися, що шляхи відносні від кореня та файли доступні |
| Відсутність maskable purpose |
Android обрізає іконку неправильно |
Додати purpose: "any maskable" для іконок 192 та 512 |
| SVG для Safari Pinned Tab не монохромний |
Не фарбується в колір теми |
Використовувати лише чорний fill, без градієнтів |
| Занадто складний логотип для 16×16 |
Губиться читаність |
Зробити окрему спрощену версію для 16×16 |
Гарантуємо, що після нашої роботи всі іконки будуть коректно відображатися на всіх пристроях.
Терміни та вартість
Підготовка повного набору займає від 0,5 до 1 робочого дня. Вартість розраховується індивідуально залежно від складності логотипу.
Замовте підготовку іконок
Зв'яжіться з нами, щоб обговорити ваш проєкт. Ми підготуємо іконки, які працюватимуть усюди — на iOS, Android, Windows та в браузерах.
Коли додаток не відкривається без інтернету, користувач іде до конкурентів
PWA перетворює сайт на надійний додаток, який працює навіть в офлайні, надсилає push-повідомлення та встановлюється на головний екран. Розробка PWA додатків — це впровадження Service Worker, налаштування кеш-стратегій та інтеграція Web Push. На відміну від нативних додатків, вам не потрібні дві команди під iOS та Android — один код працює у всіх сучасних браузерах. Замовте аудит вашого проекту на PWA-сумісність — ми безкоштовно оцінимо потенціал та терміни.
Як Service Worker керує мережевими запитами?
Service Worker — це JavaScript-проксі між браузером та мережею. Працює в окремому потоці, перехоплює запити та вирішує, звідки їх віддавати: з кешу, з мережі або комбінацією. Розглянемо три базові стратегії на реальних сценаріях.
| Стратегія кешування |
Використання |
Поведінка при офлайн |
| Cache First |
статика (CSS/JS з content hash) |
віддається з кешу, миттєво |
| Network First |
API, замовлення, новини |
спочатку мережа, при помилці — кеш |
| Stale While Revalidate |
контент соцмереж, стрічка сторінок |
одразу кеш, потім оновлення |
Cache First застосовується для активів з хешем в імені — файл ніколи не зміниться, можна кешувати назавжди. Stale While Revalidate оптимальна для контенту, де допустима невелика затримка актуалізації. Workbox від Google автоматизує версіонування кешу та інвалідацію — без нього коректний Service Worker вимагатиме 300+ рядків коду з нетривіальними edge cases. Vite + vite-plugin-pwa генерує Service Worker з конфігу, включаючи precaching статики.
import { VitePWA } from 'vite-plugin-pwa';
export default {
plugins: [
VitePWA({
registerType: 'autoUpdate',
includeAssets: ['favicon.ico'],
manifest: { /* name, icons, start_url, display */ },
workbox: {
globPatterns: ['**/*.{js,css,html,ico,png,svg}'],
runtimeCaching: [
{ urlPattern: /^https?:\/\/api\./,
handler: 'NetworkFirst',
options: { cacheName: 'api-cache' }
}
]
}
})
]
};
Як офлайн-режим реалізується на практиці?
«Працює офлайн» для різних продуктів означає різне. Ось три типові сценарії.
-
Офлайн-читання (новинні сайти, документація): Service Worker кешує сторінки при першому візиті, стратегія Stale While Revalidate + Background Sync для синхронізації після відновлення з'єднання.
-
Офлайн-редагування (нотатки, завдання): IndexedDB зберігає локальні дані, Background Sync API ставить операції в чергу — браузер синхронізує сам, навіть якщо вкладка закрита. Обмеження: Background Sync підтримується тільки в Chromium.
-
Офлайн-форма: користувач натиснув «Надіслати» без інтернету — дані не втрачаються, а ставляться в чергу та надсилаються автоматично. Для медичних та страхових форм це критично.
Проблема, про яку часто забувають: конфлікти при синхронізації. Якщо користувач А редагував запис офлайн, а користувач Б змінив його онлайн — потрібна стратегія вирішення (last-write-wins, three-way merge або показ конфлікту користувачеві). Ми опрацьовуємо ці сценарії на етапі проектування.
Як працюють Web Push-повідомлення?
Web Push доставляє повідомлення через браузер + Push Service (FCM для Chrome/Edge, APNs для Safari). Користувач надає дозвіл → браузер підписується на Push Service → ви отримуєте endpoint та ключі → надсилаєте повідомлення → Push Service доставляє в браузер. Реалізація через бібліотеку web-push (Node.js) або аналог для вашого бекенду. VAPID-ключі генеруються один раз, підписка зберігається в базі даних.
На поточний момент iOS (починаючи з версії 16.4) підтримує Web Push тільки для встановлених PWA, Chrome/Firefox/Edge — повна підтримка без встановлення. Частота та релевантність повідомлень безпосередньо впливають на відтік підписників — A/B тестування часу надсилання та формулювань стандартна практика.
Чому варто обрати PWA замість нативних додатків?
Економія на розробці під дві платформи — до 60% бюджету. Один код, єдина бізнес-логіка, автоматичне оновлення без магазинів. Ми виконали понад 30 PWA-проектів для e-commerce, фінтеху та корпоративних систем — гарантуємо сумісність з останніми версіями браузерів та відмінні показники Core Web Vitals (LCP, CLS, INP). PWA збільшує конверсію в середньому на 36% (дані Google). Сертифіковані спеціалісти з досвідом 7+ років у веб-розробці.
Що входить у розробку PWA під ключ?
| Етап |
Результат |
Термін |
| Аудит поточного додатку |
Звіт PWA‑score, рекомендації |
1–2 дні |
| Проектування офлайн‑сценаріїв |
Документація, прототип |
2–3 дні |
| Розробка Service Worker + маніфест |
Код, автоматичне тестування |
5–10 днів |
| Інтеграція Web Push (опціонально) |
Бекенд‑ендпоінт, підписка |
3–5 днів |
| Тестування на реальних пристроях |
Звіт, правки |
3–5 днів |
| Деплой та документація |
Доступи, інструкція, гарантія 1 місяць |
1–2 дні |
App Shell архітектура та precaching критичних ресурсів при першому встановленні дають миттєве завантаження оболонки додатку навіть при повільному з'єднанні.
Процес роботи та терміни
- Аудит поточного додатку (Lighthouse PWA score, аналіз сценаріїв).
- Визначення цінних офлайн-сценаріїв.
- Налаштування Service Worker через Workbox та реалізація маніфесту.
- Інтеграція Web Push (якщо потрібно).
- Тестування на реальних пристроях — Chrome DevTools, Safari Web Inspector.
- Деплой, документація, навчання команди.
Орієнтовні терміни: базова PWA (маніфест + Service Worker + кеш статики) — 1–2 тижні поверх готового додатку; Web Push — 1–2 тижні; офлайн-редагування з IndexedDB та Background Sync — 3–6 тижнів залежно від складності даних.
Вартість розраховується індивідуально після аудиту. PWA-проект зазвичай обходиться в 2–3 рази дешевше нативного додатку під обидві платформи. Додаткову економію дає відсутність витрат на публікацію в App Store та Google Play. Зв'яжіться з нами для консультації — ми безкоштовно оцінимо ваш проект та запропонуємо оптимальну стратегію впровадження.
Посилання для поглибленого вивчення
