Уявіть: ви запустили інтернет-магазин на Wix, але стандартні форми не дозволяють додати власну логіку знижок або інтеграцію з 1С. Замовлення обробляються вручну, а клієнти скаржаться на затримки. Без програмування не обійтися. Velo (раніше Wix Code) — це вбудована JavaScript-платформа, що дає повний контроль над backend та frontend без придбання VPS. Вона надає доступ до Wix Data API та HTTP Functions, а також до Web Methods для створення кастомної бізнес-логіки. Ми спеціалізуємося на розробці Velo-рішень під ключ: від простих форм з валідацією до складних динамічних каталогів. Наш досвід — 5+ років та 30+ реалізованих проєктів. Наприклад, для інтернет-магазину косметики ми реалізували автоматичну синхронізацію з CRM та Telegram-сповіщення, що скоротило час обробки замовлення на 40% і знизило навантаження на менеджерів на 30%, а також зменшило витрати на підтримку на 20%. Отримайте безкоштовну консультацію по вашому проєкту.
Velo — це вбудоване середовище розробки Wix для створення кастомної бізнес-логіки. На відміну від чистого Wix Editor, Velo дозволяє працювати з базами даних, створювати HTTP-ендпоінти та виконувати код за розкладом. Це не просто «додати трохи скриптів», а повноцінне середовище з обмеженнями, які потрібно враховувати. Наприклад, серверні функції виконуються не довше 500 ms, а пам'ять обмежена 100 MB. Ми знаємо ці нюанси та вміємо обходити їх через асинхронні паттерни та пагінацію. При розробці каталогу для мережі салонів краси ми скоротили час завантаження сторінок на 55% за рахунок лінивого завантаження та кешування.
Які завдання вирішують Velo-рішення?
- Кастомна обробка замовлень з валідацією та сповіщеннями (Telegram, email)
- Динамічні сторінки з фільтрацією, пагінацією, SEO-урлами
- Особистий кабінет з реєстрацією, історією замовлень
- Інтеграція з зовнішніми API (CRM, платіжні шлюзи, маркетплейси)
- Scheduled tasks (cron) для автоматичного очищення даних або розсилок
Як Velo вирішує інтеграцію з зовнішніми сервісами?
Всі зовнішні виклики виконуються тільки з backend-коду — секрети (токени, ключі) зберігаються в Wix Secrets Manager. Наприклад, відправка лідів у Telegram через Web Method:
// backend/integrations.web.js
import { webMethod, Permissions } from 'wix-web-module';
import { getSecret } from 'wix-secrets-backend';
export const sendToTelegram = webMethod(
Permissions.Anyone,
async (message) => {
const botToken = await getSecret('TELEGRAM_BOT_TOKEN');
const chatId = await getSecret('TELEGRAM_CHAT_ID');
await fetch(`https://api.telegram.org/bot${botToken}/sendMessage`, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
chat_id: chatId,
text: message,
parse_mode: 'HTML',
})
});
}
);
Цей підхід гарантує безпеку та перевикористання коду. Клієнтський виклик — через import з backend/integrations.web — типобезпечний і не розкриває секрети.
Порівняння Velo та звичайного Wix
| Можливість |
Wix Editor |
Velo (Wix Code) |
| Кастомна валідація форм |
Тільки вбудована |
Повний контроль через JS |
| Робота з БД |
Ні |
Wix Data API, колекції |
| Зовнішні API |
Ні |
HTTP Functions, Web Methods |
| Динамічні URL |
Тільки Wix Pages |
Кастомні роутери |
| Scheduled tasks |
Ні |
Jobs (cron) |
Velo дає гнучкість, але вимагає досвіду. Ми допоможемо уникнути типових помилок: перевищення лімітів за часом виконання, неправильна обробка асинхронних запитів, ігнорування кешування.
Типові обмеження Velo, які ми враховуємо:
- Серверні функції виконуються не довше 500 мс
- Доступна пам'ять — 100 MB
- Розмір даних, що передаються, — до 10 MB
Ми використовуємо асинхронні паттерни, пагінацію та кешування, щоб обходити ці ліміти.
Типові завдання та терміни
| Завдання |
Складність |
Терміни |
| Кастомна форма з backend-обробкою |
Низька |
2–3 дні |
| Динамічний каталог з фільтрацією |
Середня |
7–12 днів |
| Особистий кабінет з реєстрацією та замовленнями |
Висока |
2–3 тижні |
| Інтеграція з CRM та платіжними системами |
Середня |
5–10 днів |
Точні терміни визначаються на безкоштовному аудиті. Замовте оцінку проєкту прямо зараз.
Що входить у роботу
- Повний код Velo (frontend + backend) з коментарями
- Документація по колекціях, API та роутах
- Доступи для редакторів та інструкція
- Навчання команди замовника
- Підтримка 1 місяць після здачі безкоштовно
Ви отримуєте повністю кастомне рішення — wix custom solutions, готове до використання.
Процес роботи
- Аналіз: уточнюємо вимоги, дивимося доступні Wix-елементи
- Проектування: схема колекцій, маршрути, точки інтеграції
- Розробка: пишемо код на Velo, деплоїмо в тестове середовище
- Тестування: сценарії (успіх, помилки, граничні випадки)
- Деплой та підтримка: перенос на продакшен, навчання редакторів
Замовте Wix Code під ключ — і забудьте про ручну обробку. Наші інженери сертифіковані Wix і гарантують результат.
Додаткову інформацію можна знайти в офіційній документації Velo.
Отримайте безкоштовну консультацію — зв'яжіться з нами.
Типи сайтів: технічне завдання, а не маркетинг
Ми бачимо, як команди витрачають бюджет на невідповідний стек. Лендинг на Next.js зі статичною генерацією та корпоративний сайт з CMS — принципово різні інфраструктури, навіть якщо зовні схожі. Помилка на старті веде до переплати за хостинг у 5–10 разів і низької швидкості завантаження. Core Web Vitals (LCP, INP, TTFB) для кожного типу сайту мають свої пріоритети: для лендингу критичний LCP, для корпоративного — TTFB через динамічний контент.
За нашими даними, до 40% проєктів переплачують на хостингу через неправильний вибір технології. Статичний сайт на CDN обходиться в 5 разів дешевше за WordPress на VPS за тих самих навантажень. Нижче розберемо чотири типи сайтів, їхні типові технічні помилки та рішення, які ми застосовуємо на практиці. Маємо 8 років досвіду та понад 120 успішних проєктів у різних нішах.
Як обрати правильний тип сайту?
Вибір визначає стек, інфраструктуру та бюджет на підтримку. Покрокова інструкція:
- Визначте мету: продаж (лендинг), інформування (корпоративний) чи швидкий контакт (візитка).
- Оцініть частоту оновлення контенту: щодня — потрібна CMS, раз на місяць — вистачить Markdown у Git.
- Виберіть стек за продуктивністю: статика для візиток, Next.js з ISR для корпоративних, GSAP для промо.
Як не помилитися з вибором CMS?
Якщо редактори нетехнічні — WordPress з Gutenberg або ACF Pro закриває потреби. Для складних структур — headless CMS (Strapi, Directus) з фронтендом на Next.js. Якщо оновлення рідкі — Markdown в Git з Astro або Next.js, деплой по push в main. Ми використовуємо Repository pattern для уникнення N+1 запитів при роботі з ORM.
Сайт-візитка
Найкомпактніший формат: 1–5 сторінок, мінімум динаміки. Основне завдання — контактна інформація та перше враження. Технічно просто, але є типові помилки.
Занадто важкий стек. WordPress з 15 плагінами для 5 сторінок дає TTFB 800ms на shared хостингу. Ми пропонуємо статику: HTML/CSS/JS або Next.js з output: 'export', задеплоєне на Vercel або Cloudflare Pages. Жодного PHP, жодної бази даних — тільки CDN. TTFB < 50ms гарантовано. Економія на хостингу — до 70% на місяць.
Немає контактної форми з backend-валідацією. Форма лише з JS-валідацією — це декорація. Ми додаємо серверлесс endpoint (Netlify Functions або AWS Lambda) з rate-limiter та сповіщеннями.
Відсутність Schema.org розмітки. Google Knowledge Panel будується на LocalBusiness або Organization. Ми вбудовуємо розмітку в шаблон: адреса, телефон, години роботи.
Термін розробки: 2–3 тижні з дизайном.
Чому швидкість лендингу безпосередньо впливає на конверсію?
Лендинг — сторінка з однією метою: конверсія. Core Web Vitals критичні, оскільки платний трафік і Google використовує CWV у Quality Score.
Конкретний кейс: лендинг з hero-відео 8MB autoplay без preload="none" і три сторонні скрипти аналітики синхронно в <head>. LCP 9.4s, INP 780ms. Ми замінили відео на poster image з відкладеним завантаженням, скрипти перевели на async/defer і частково в Web Workers через Partytown. LCP став 1.8s, INP 140ms. Конверсія зросла на 23% тільки за рахунок швидкості.
A/B тестування — стандартна практика. Після закриття Google Optimize використовуємо open-source Growthbook або PostHog. Для Next.js застосовуємо edge middleware для розподілу трафіку на CDN без додаткового JS.
Термін: 2–4 тижні.
Корпоративний сайт
Корпоративний — CMS, багато сторінок, мультимовність, інтеграція з CRM. Ключове питання: хто редагує контент і як часто.
Якщо редактори нетехнічні — WordPress з Gutenberg або ACF Pro. Для складних структур — headless CMS (Strapi, Directus) з фронтендом на Next.js. Якщо оновлення рідкі — Markdown в Git з Astro або Next.js, деплой по push в main.
Продуктивність: сторінка "Про компанію" з 40 фото в оригіналі — LCP 12 секунд на мобільному. <Image> компонент Next.js з WebP і srcset вирішує без ручної роботи, знижуючи LCP до 2 секунд.
Багатомовність: Astrotomic Translatable на Laravel або next-intl. Структура URL — /uk/about, /en/about з hreflang.
Термін: 6–12 тижнів залежно від обсягу.
Промо-сайт
Промо — тимчасовий або постійний сайт під кампанію. Нестандартний дизайн, анімації. Стек: GSAP, Framer Motion, Three.js, Lottie.
Головна пастка — гальмівні анімації на мобільних. GPU-анімації через transform і opacity — нормально. box-shadow в анімації, filter: blur() на кожному кадрі, анімація width/height — 20fps на iPhone 12. will-change: transform допомагає точково.
prefers-reduced-motion — обов’язковий для accessibility.
Термін: 3–6 тижнів.
Як ми оптимізуємо продуктивність?
Для кожного проєкту проводимо аудит початкового стеку: аналізуємо TTFB, LCP, CLS, INP через Lighthouse та WebPageTest. Використовуємо tree-shake та bundle splitting для зменшення JS-бандла, для Next.js — React Server Components і Suspense для стрімінгу. Серверлесс функції дозволяють уникнути постійної вартості сервера — платите тільки за запити. Наприклад, корпоративний сайт на Next.js + Strapi дає TTFB <200ms, що у 5 разів менше ніж аналог на WordPress.
Автоматично конвертуємо зображення в WebP/AVIF, генеруємо srcset для всіх роздільних здатностей, використовуємо lazy loading з Intersection Observer. Для фонових зображень — техніка progressive loading.
Порівняльна таблиця
| Параметр |
Візитка |
Корпоративний |
Лендинг |
Промо |
| Сторінок |
1–5 |
10–50+ |
1–3 |
1–10 |
| CMS |
Не потрібна |
Потрібна |
Не потрібна |
Рідко |
| SEO-пріоритет |
Середній |
Високий |
Високий |
Низький |
| Анімації |
Мінімум |
Помірно |
Помірно |
Інтенсивно |
| Термін (з дизайном) |
2–3 тиж |
6–12 тиж |
2–4 тиж |
3–6 тиж |
Вартість у кожному випадку розраховується індивідуально після вивчення технічного завдання. — Google рекомендує TTFB під 0.8s, у нас <0.2s.
Що входить в роботу
- Аналітика та прототипування (структура, користувацькі сценарії)
- Дизайн-концепція (адаптивний, mobile-first)
- Верстка з оптимізацією LCP, CLS, INP
- Вибір та налаштування CMS (якщо потрібна)
- Інтеграція з CRM/маркетинговими інструментами
- Тестування (кросбраузерне, load-testing)
- Документація та передача доступів
- Навчання редакторів (відео + письмово)
-
гарантія 3 місяці (безкоштовні правки)
Друга таблиця: порівняння підходів за продуктивністю
| Підхід |
TTFB (мс) |
Складність підтримки |
Вартість розробки |
| Static HTML/CSS |
<50 |
Низька |
Низька |
| Next.js + headless CMS |
<200 |
Середня |
Середня |
| WordPress + плагіни |
500–1500 |
Висока |
Висока |
Статичний сайт швидший за WordPress у 10 разів за TTFB. Для консультації щодо вибору типу сайту та стеку зв'яжіться з нашими інженерами. Замовте розробку під ключ — ми оцінимо терміни та бюджет за 1 день. Напишіть нам, щоб отримати безкоштовний технічний аудит вашого проекту. Отримайте індивідуальну пропозицію з гарантією якості.