SVG-іконки на сайті: де починаються проблеми з версткою
Іконка, намальована під конкретний блок у макеті, живе до першої переверстки.
Варто додати новий розділ або змінити ширину сітки — і SVG-іконки починають поводитися непередбачувано: одні тягнуться разом із контейнером і втрачають пропорції, інші обрізаються по краю, треті перестають збігатися за оптичним розміром із сусідніми.
Формально це проблеми верстки, але стоять за ними не властивості стилів, а спосіб підготовки графіки.
Розсинхрон стилів найчастіше приходить із паралельної роботи. Один виконавець намалював контурні значки з однією товщиною лінії, другий — заливкою, третій підтягнув готовий набір із чужої бібліотеки.
Усередині розділу все виглядає охайно, а на стику блоків видно різні заокруглення, різні поля навколо значка й стан наведення, який спрацьовує лише в половини іконок для сайту. Вирівняти це тільки стилями не вдається — правки зачіпають самі файли.
Вага сторінки зростає тихо. Зазвичай у проєкті лежать растрові копії одного й того самого значка в кількох розмірах, повний спрайт, де задіяна десята частина, й іконковий шрифт заради двох стрілок.
Кожен набір завантажується на всіх сторінках, включно з тими, де графіка не потрібна, а кеш не рятує: файли оновлюються разом із релізом.
Окрема історія — підміни під час оновлення контенту. Редактор бере файл із загальної папки за схожим ім’ям, і замість потрібного значка в блоці з’являється чужий, з іншим сенсом і кольором. Помилка випливає вже на опублікованій сторінці. Розбираємо, як це закривається на рівні підготовки графіки та правил її підключення.
Що дає єдиний набір векторної графіки: швидкість і консистентність
Єдиний набір векторної графіки починається з того, що кожна іконка живе в одному джерелі й одному форматі. Поки асети лежать розрізненими картинками, сторінка тягне десятки окремих запитів, а вага й стиль кожної іконки залежать від того, хто й коли її готував. Що змінюється, коли графіка зібрана в систему:
- Швидкість завантаження. Іконки переходять у загальний набір і віддаються одним запитом замість десятків — вага графіки на типовій сторінці падає в рази, час до першого відображення скорочується на сотні мілісекунд.
- Консистентність інтерфейсу. Спільна сітка, єдина товщина обведення й заокруглення: іконки в шапці, кнопках і таблицях не розходяться за стилем, навіть якщо їх малювали різні дизайнери.
- Оптимізація зображень. З файлів прибираються приховані шари, зайві групи й метадані — окрема іконка втрачає 40-60% ваги без видимої різниці.
- Перефарбовування без другої версії файлу. Колір успадковується від тексту, тому темна тема, наведення й неактивний стан працюють без окремої картинки під кожен стан.
- Дизайн-система. Макети в Figma і код ідуть з одного джерела: нові сторінки збираються з готових елементів, і додавання розділу займає години, а не дні.
- Передбачувана поведінка. Розміри 16, 24 і 32 масштабуються без втрати різкості, інтерфейс не «пливе» на екранах із високою щільністю, а нові іконки додаються за готовим шаблоном.
Способи підключення графіки: порівняння підходів і обмежень
Спосіб підключення графіки впливає на час відображення, обсяг розмітки й те, наскільки трудомістко замінити одну іконку в наступному релізі.
Вибір майже завжди компроміс: один варіант економніший на слабких пристроях, другий зручніший у підтримці, третій трапляється лише в успадкованих шаблонах. Нижче — реальні варіанти підключення іконок і те, де кожен починає заважати.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Інлайнова графіка | Іконка змінює колір і стан через стилі | Розмітка розростається, повтори дублюються, окремо не кешується |
| Спрайт-лист одним файлом | Багато однотипних іконок, потрібне єдине джерело | Оновлення скидає кеш повністю, не працює під час локального відкриття сторінки |
| Іконковий шрифт | Потрібне масштабування як у тексту й успадкування типографіки | Ламається при вимкнених або підмінених шрифтах, символи не читаються засобами доступності |
| Окремі файли векторного набору | Точкові заміни, різна стилістика | Колір задається всередині файлу, зростає кількість звернень до сервера |
| Растрові асети | Складна графіка з деталізацією | Не масштабується без втрати якості, вага множиться на кожну роздільну здатність |
Як обираємо
Векторний набір збирається один раз і перевикористовується, тому важливіша стабільність результату, ніж сам спосіб вставки.
Підтримка браузерів перестала бути блокуючим фактором, але не зникла: вбудовані браузери мобільних оболонок і старі рушії по-різному працюють із зовнішніми спрайтами й масками.
Тому набір перевіряємо на пристроях з аудиторії замовника, а не лише в інструментах розробника: IcoMoon і подібні збирачі прискорюють підготовку, але не скасовують цю перевірку.
Як ми готуємо та впроваджуємо графічні асети: етапи роботи
Графіку на сайті зазвичай правлять по факту: іконки приходять із різних наборів, у частини немає вихідників, а новий екран ламає вже узгоджений стиль. Ми ведемо підготовку асетів як інженерний процес із перевірюваним результатом на кожному кроці.
- Аудит графіки. Збираємо перелік усіх SVG-іконок і зображень за сторінками й шаблонами: джерело, дублі, невикористане, биті посилання. На виході — таблиця, де видно, що видаляємо, що перемальовуємо, а що переносимо як є.
- Схема набору. Ділимо графіку на категорії — інтерфейсні іконки, ілюстрації, логотипи, — задаємо єдиний стиль обведень і заокруглень та правила іменування файлів. Нова іконка стає в набір без суперечок про назву.
- Єдина сітка. Приводимо все до спільної модульної сітки, однакових полів і опорних ліній. Іконки перестають «стрибати» в кнопках і списках при зміні розміру.
- Підготовка асетів. Чистимо розмітку від зайвих вузлів, прихованих шарів і метаданих редактора, об’єднуємо повторювані фігури, колір робимо успадковуваним від тексту — темна тема працює без другого файлу.
- Впровадження. Підключаємо набір через компоненти інтерфейсу, замінюємо старі картинки, прописуємо стани: звичайний, активний, вимкнений.
- Перевірка на пристроях. Реальні екрани й браузери, темна тема, підвищена щільність пікселів, масштабування тексту й друк; збірка перевіряється на биті посилання в графіці.
- Передача документації. Вихідники, схема набору, регламент «як додати нову іконку» й чек-лист приймання, щоб правки не руйнували систему.
На виході — не папка з картинками, а набір, схема й правила: новий екран збирається з готових елементів.
Що передаємо на руки: вихідники, набори й правила роботи
Передача — це не архів із картинками, а робочий комплект, за яким ваша команда додає нові знаки без нас. Нижче — склад того, що залишається у вас після здачі: структура вихідників, зібрані набори під різні сценарії та правила, за якими графіка живе далі.
- Структура вихідників: каталоги за розділами сайту, всередині — окремо монохромні та кольорові знаки, вектор в єдиній розмірній сітці й робочі шари для правок.
- Зібрані набори: спрайт для інтерфейсу, окремі файли під відкладене завантаження, версії під світлу й темну тему, стани звичайний і активний.
- Правила іменування: префікс призначення, єдиний регістр, розмірність в імені — за назвою відразу видно, де знак застосовується і якого він розміру.
- Інструкція для команди: покроковий порядок додавання нового знака, вимоги до кривих і заливок, чек-лист перевірки перед публікацією.
- Карта використання: таблиця «знак — розділ — сценарій», щоб під час переробки макета було видно, що можна змінювати вільно, а що зав’язано на інших.
- Оптимізація та перевірка: скрипт, який прибирає зайві вузли й метадані, і контроль, що після правки жоден знак не втратив розмір.
- Джерела й права: перелік вихідних бібліотек із ліцензіями, щоб у наборі не залишилося знаків із неясним походженням.
Кейс: набір SVG-іконок прибрав розсинхрон між розділами
До нас прийшов сервіс з особистим кабінетом: шість розділів і понад сорок сторінок, які в різний час збирали різні команди.
Іконки приходили з трьох джерел — частину малював дизайнер під конкретну сторінку, частина залишилася від старого макета, частину приносив підрядник готовими растровими картинками.
Аудит показав масштаб: у наборі було 47 файлів, із них 12 — дублі однієї й тієї самої дії з різною товщиною обведення й заокругленням кутів. Іконка пошуку зустрічалася в трьох варіантах, кошик — у двох.
Правка однієї іконки займала в дизайнера до пів години: потрібно було знайти всі копії, оновити кожну й передати розробнику список файлів, що змінилися.
Що зробили
Зібрали спільну бібліотеку в Figma з єдиним джерелом: одна сітка, однакова товщина обведення, колір задається успадковуваним значенням, а не зашитий у файл. Розробники підключили набір як інлайнові SVG і спрайт — замість растрових копій під кожну тему.
Правила зафіксували в короткому документі: як додати нову іконку, які розміри допустимі, що робити зі старою під час заміни.
Результат
Набір скоротився до 38 файлів без втрати сенсу — дублі прибрали, спірні іконки перемалювали один раз. Правка займає хвилини: змінюється одне джерело, інші розділи підтягують зміну, розсинхрон між ними зник.
Термін випуску нової сторінки скоротився приблизно вдвічі — графіка перестала бути окремим етапом узгодження. Вага графіки на сторінках упала в рази, бо замість десятка растрових файлів підвантажується один набір. Зміна кольору інтерфейсу тепер коштує правки в одному місці, а не перемальовування кожної іконки.
Чим відрізняється шрифтова графіка від векторного набору?
Шрифтовий набір тримає всі знаки в одному файлі: кожен значок — окремий символ у службовій області кодування, а розмір, колір і вирівнювання задаються як у тексту.
Це вигідно за кількістю запитів — браузер забирає файл один раз і далі віддає знаки з кешу, тому на сторінках із десятками однотипних піктограм такий варіант виглядає ощадливо.
Обмеження проявляються на етапі підтримки.
Знак у шрифті одноколірний за визначенням: багатоколірні логотипи й градієнти в нього не вкласти, додавання одного значка потребує перезбирання всього файлу, а зіставлення символів легко ламається під час злиття гілок — два розробники призначають один код двом різним іконкам і отримують підміну на сторінці.
Скринрідери читають такий символ як безглузду літеру, тому до кожного виведення доводиться вручну дописувати прихований підпис.
Векторний набір складається із самостійних файлів або загального спрайта: знак вставляється в розмітку елементом і стилізується як звичайна графіка — приймає колір тексту, стан наведення, анімацію, багатоколірну заливку.
Один значок можна замінити, не перезбираючи решту, а невикористовувані знаки не потрапляють у збірку, і набір залишається рівно таким, який потрібен сторінці.
Вибір рішення зводиться до трьох питань: скільки знаків потрібно, чи бувають вони кольоровими й як часто додаються нові.
Шрифтові знаки виправдані у вузькій ніші — однотонні піктограми в листах, де зовнішні файли не підвантажуються, або в успадкованих збірках, які не планують розвивати.
Для інтерфейсу, який живе й змінюється, векторний набір дає передбачувану підтримку графіки: правка однієї іконки не перетворюється на перезбирання шрифту, а тема, стани й доступність залишаються під контролем команди.
Технічні сумніви щодо графіки: впровадження й супровід
Сумніви щодо графіки повторюються від проєкту до проєкту: чи не попливе відображення на різних екранах, що робити з уже зверстаними сторінками, хто оновлює набір після здачі й чи не зламають правки інтерфейс. Відповідаємо на п’ять питань, які найчастіше ставлять до старту.
Чому іконка виглядає розмитою на частині екранів?
Найчастіше річ не у форматі, а в дробових координатах і тонких обведеннях, які розмазує масштабування. Вирівнюємо контури за цілочисельною сіткою й підключаємо вектор напряму — на екранах із високою щільністю контур залишається різким.
Що буде з наявною версткою?
Спочатку інвентаризація: де іконки підключені, які дублюють одна одну. Заміна йде посторінково, старі файли живуть до перевірки — відкат зводиться до зняття одного підключення.
Хто оновлює графіку після запуску?
Передаємо вихідники й правила: як додати іконку, які перевірки запускаються автоматично. Прості елементи ваша команда додає сама, ми підключаємося на складні випадки.
Як вирішується доступність інтерфейсу?
Декоративні іконки ховаємо від допоміжних технологій, смислові отримують текстовий опис. Контраст звіряємо у світлій і темній темі, стан фокуса залишається видимим.
Як оновлювати набір без регресій?
Тримаємо еталонні сторінки й порівнюємо відображення до та після правки на ключових роздільних здатностях. Зміни йдуть окремою гілкою — розходження видно до викладення, а не на робочому сайті.
Обговоримо ваше завдання щодо графічних асетів для сайту
Щоб повернутися з оцінкою проєкту, а не із загальними словами, нам потрібен короткий вхід: посилання на сайт або репозиторій, вихідники макетів і два-три приклади іконок, які зараз викликають питання.
Цього достатньо, щоб зрозуміти обсяг набору, стан вихідників і те, які блоки доведеться переверстати.
- Розбір поточного стану. Дивимося, як графіка підключена зараз: окремі файли, спрайт, іконковий шрифт або растрові копії. Знаходимо дублі, різнокольорові версії одного й того самого символу та місця, де іконка ламає сітку.
- Звірка з макетами. Зіставляємо те, що намальовано, з тим, що реально у верстці, і фіксуємо розходження: інша товщина обведення, збиті пропорції, втрачені стани при наведенні.
- Формат зберігання й постачання. Пропонуємо схему: єдиний спрайт або окремі файли, керування кольором через успадкування, окремий шар для дрібних розмірів.
- План робіт. Розкладаємо завдання на етапи зі зрозумілим результатом кожного: підготовка набору, чистка, збірка, вбудовування, перевірка на адаптивності.
- Оцінка проєкту. Називаємо трудовитрати за етапами й межі: що входить у набір, а що оформлюємо окремим завданням.
- Порядок дій. Узгоджуємо черговість — спочатку те, що бачить користувач на першому екрані, потім другорядні розділи й стани.
- Старт робіт і передача. Після узгодження починаємо з найбільш навантаженого розділу, щоб результат було видно рано, а не в кінці.
Якщо хочете звірити очікування до старту — обговоримо завдання: покажемо, як зазвичай виглядає набір після чистки, і що змінюється в підтримці. Опишіть ситуацію, повернемося з оцінкою та планом робіт.
