Разработка 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. Свяжитесь с нами для консультации — мы бесплатно оценим ваш проект и предложим оптимальную стратегию внедрения.
Ссылки для углублённого изучения
