Кнопка «Видалити» в адмінці Shopify скасовує підписку і від'єднує застосунок від магазину. Вона не видаляє те, що застосунок завантажив у вашу тему. Зображення, сніпети, правки layout і посилання на чужі сервери лишаються там, доки хтось не знайде їх руками.
В одному магазині, який ми давно ведемо, ми так знайшли 6,9 МБ із 8,8 МБ папки assets/ - зображення застосунку лояльності, видаленого ще раніше. На них посилалися три сніпети, і жоден не відмальовувався (власний розбір локальної копії теми, 27.08.2026).
За застосунки ви платите щомісяця, але рахунок складається з трьох частин
Перша частина - підписка, і її ви бачите у виписці. Друга і третя в грошах не виставляються, але оплачуються так само.
| Частина рахунку | Де проявляється | Коли закінчується |
|---|---|---|
| Підписка | виписка з рахунку | при видаленні |
| Уповільнення сторінки | LCP, кількість запитів | лише при прибиранні теми |
| Час розробника | кожна наступна правка | лише при прибиранні теми |
Витрати на підписки розбираємо у статті про місячні витрати магазину. Цей текст - про дві решту.
Застосунок чіпає не лише свої файли
Щоб працювати у списку товарів або в кошику, застосунок має потрапити в тему. Робить він це шістьма способами, і кожен із них переживає видалення по-своєму довго:
- Файли в папці assets/ - зображення, скрипти, стилі.
- Сніпети, які він вставляє в секції або в layout.
- Правки layout/theme.liquid - ініціалізація, коди аналітики.
- Script tags, що їх вставляє платформа поза темою.
- App proxy - власні адреси під доменом вашого магазину.
- Власний layout, зазвичай у конструкторів сторінок.
Під час видалення платформа надійно прибирає лише script tags і app blocks. Решта - ваш файл у вашій темі, і ніхто чужий його видаляти не буде.
Мертві зображення не гальмують сторінку, але здорожчують будь-яку роботу з темою
Ті 6,9 МБ зображень зі вступу не завантажуються, бо сніпети, які їх викликають, ніде не відмальовуються. Відвідувач їх ніколи не завантажить, і в замірі швидкості ви їх не знайдете.
Зате вони здорожчують усе інше: завантаження теми, її дублювання, викладку через theme push, порівняння двох магазинів. Тобто саме ті операції, які розробник робить у кожному замовленні. Виміряйте папку assets/ раніше, ніж візьметеся за розмір теми - інакше ви оптимізуєте код, частка якого менша за частку мертвих зображень.
У тій самій темі до цього було 31 невикористаний сніпет зі 102, 34 невикористані секції зі 149 і 15 мертвих файлів у assets/ обсягом 312 КБ.
Власний код теми важив 635 КБ, на живій сторінці було три мегабайти
Це найясніше число всього розбору. Власних скриптів тема мала 32 файли загальним обсягом 635 КБ, і всі вони були підключені з атрибутом defer. При цьому на живій сторінці інструмент заміру нарахував близько 3 МБ JavaScript у 236 файлах (WebPageTest, мобільний профіль, холодний кеш, 24.06.2026).
Різницю принесли застосунки та сторонні сервіси. Хто в такій ситуації платить за рефакторинг теми і не робить інвентаризацію застосунків, купує приблизно п'яту частину проблеми. Як швидкість ділиться між платформою і сторінкою, розбираємо у статті про те, чому швидкий Shopify гальмує.
Дванадцять чужих скриптів без defer - це дванадцять чужих відмов
У тій самій темі ми нарахували 12 зовнішніх скриптів без атрибута defer або async із семи чужих хостів. Два з них були синхронними прямо в <head>, тобто в місці, де браузер зупиняє обробку документа, доки файл не завантажиться з чужого сервера.
Якщо той сервер не відповість, не відмалюється нічого. Це не теоретичне побоювання: один із хостів у тій темі, polyfill.io, під час нашої перевірки 27.08.2026 повертав помилку HTTP 520.
polyfill.io не повільний, це чужий код із чужим власником
У цьому пункті йдеться не про швидкість. Домен polyfill.io у 2024 році змінив власника і почав із частини візитів розсилати шкідливі перенаправлення; сьогодні він мертвий. У тему він потрапив у сніпеті одного застосунку, як запасний варіант для старих браузерів.
Важливо, як це виправляється. Той сніпет вендорський і має позначку «не правити вручну» - будь-яка правка зникне при першому оновленні застосунку. Тому питання адресується розробнику застосунку, а не вашому програмісту. Якщо застосунок уже не встановлений, сніпет видаляється повністю.
Практично це означає одне: кожна тема, яку ви приймаєте після когось іншого, прочісується на чужі домени у <script src> раніше, ніж іде в продакшн.
Застосунки друкують e-mail покупця в HTML, а записувачі сесій його збирають
Типовий ініціалізаційний сніпет застосунку лояльності або реферальної програми виводить у сторінку customer.email, first_name, last_name, orders_count і total_spent. Частина застосунків додатково дублює e-mail у data-атрибути.
Окремо кожен із цих кроків законний. Проблема виникає на перетині: на тій самій сторінці працював запис користувацьких сесій. Персональні дані, надруковані в HTML, тим самим потрапляють у запис сесії в третьої сторони, а це вже передавання, яке має бути обґрунтоване.
Це знахідка не для розробника, а для того, хто у вас відповідає за обробку персональних даних. Наша роль закінчується фразою «ось так це має вигляд на сторінці, і ось ці три сервіси це бачать».
Після конструкторів сторінок лишається другий layout, про який ніхто не знає
Конструктори сторінок на кшталт GemPages, PageFly чи Shogun додають собі власний layout/theme.<назва>.liquid. Після видалення файл лишається і містить копію шапки з усіма тодішніми правками.
У розібраній темі він мав 583 рядки, і його не викликав жоден {% layout %}. Від живого layout він відрізнявся на 165 рядків - і містив єдиний виклик сніпета з hreflang у всій темі.
Перш ніж такий файл видаляти, порівняйте його з живим. Відмінності показують, які правки шапки за ці роки робилися наосліп і що при них загубилося.
Аудит застосунків ви зробите самі за півдня
Завантажте тему через Shopify CLI і запустіть на папці п'ять перевірок. Жодна з них не потребує доступу в адмінку.
du -sh assets/ # скільки важать статичні файли
rg -o 'src="https?://[^/"]+' --no-filename | sort -u # чужі домени у скриптах
rg -l 'polyfill\.io|cdn\.jsdelivr|unpkg\.com' # відомі чужі CDN
ls layout/ # очікуємо один theme.liquid
rg -c 'customer\.email|customer\.total_spent' # персональні дані в HTMLДо кожної знахідки потім іде одне питання: цей файл ще хтось викликає? Ім'я сніпета шукається в render та include, ім'я ассета - по всій темі. Якщо не знаходиться ніде, це кандидат на видалення - не саме видалення, бо рішення належить тому, хто знає, скільки ця функція заробляла.
Чим платять за прибирання
Скажімо прямо, бо пропозиції з прискорення цю фразу зазвичай оминають. Видаливши застосунок, ви втратите функцію, за яку платили - програму лояльності, відгуки про товари, апсел у кошику.
Тому рішення належить не розробнику, а тому, хто знає виторг цієї функції. Ми даємо другу половину рівняння: скільки цей застосунок коштує в мегабайтах, у секундах, у ризику відмови й у часі розробника.
Друга річ, яку чесно сказати: прибирання теми не видно. Воно не додасть функції й не зсуне дизайн. Воно окупиться на наступній правці, яка зробиться вдвічі швидше, бо зрозуміло, що живе.
Надішліть нам список застосунків і адресу магазину
Повернемо, які з них реально працюють, що після видалених лишилося в темі і які чужі скрипти вантажаться на кожній сторінці. У кожного пункту буде вказано, що станеться після видалення.
Обсяг аудиту та прискорення сайту описано на сторінці послуги; якщо ви розбираєтеся з усією темою, а не лише із застосунками, подивіться, як шаблони виходять з-під контролю. Магазини на Shopify ми теж будуємо - включно з прийманням магазину після іншого підрядника.
Напишіть на info@lamapixel.com або зателефонуйте +420 775 599 009.
