Розробка онлайн-редактора: де ламається продуктивність
Редактор спокійно витримує сотню об'єктів, але варто додати растрові вставки, ефекти та маски — і відгук на перетягування виходить за пів секунди.
Справа не в каналі зв'язку і не в потужності сервера: під час кожного зсуву документ перезбирається повністю — перемальовування всіх шарів, повторний розрахунок ефектів, оновлення мініатюр панелі. Вузьке місце графічного редактора — не сама операція, а обсяг роботи, який вона за собою тягне.
Межі навантаження проявляються і в спільній роботі над макетом. П'ять-десять людей з незалежними історіями скасувань дають розбіжні стани: в одного зміщено маску шару, у другого зник ефект.
Поки правки не зведено до єдиного порядку, редактор показує кожному свою версію документа, і розбіжність виявляється вже під час вивантаження — коли макет пішов замовнику.
Третій клас відмов — втрата правок під час збереження макета. Повний перезапис документа обривається на середині, і на сервері залишається напівстан, який не відкривається ні в автора, ні в колег.
Незавершені сесії губляться ще й тому, що історія змін живе в пам'яті вкладки, а на боці зберігання лежить лише остання збережена версія.
За всіма трьома збоями стоїть одна архітектурна причина: документ обробляється повністю, а не частинами, і не має надійної точки відновлення. Розбираємо, як це закривається — на рівні моделі документа, зберігання версій і синхронізації учасників.
Що змінюється після переробки ядра редактора
Після переробки ядра редактор перестає «замислюватися» на великих макетах, а робота користувача переживає обрив зв'язку. Ефект ми вимірювали до і після за чотирма величинами: час відгуку інтерфейсу, частка успішних збережень, час відновлення після збою і клас відмов, які зникли.
Швидкість відгуку інтерфейсу на великих макетах
Раніше кожна дія перемальовувала все полотно: правка в макеті на сотні шарів давала помітну паузу, перетягування «наздоганяло» курсор, панель шарів підвисала.
Ядро перевели на інкрементальний рендеринг — оновлюється лише змінена область, важкі операції пішли у фоновий потік, список шарів віртуалізовано. Відгук скоротився із секунд до часток секунди і майже не залежить від кількості шарів: макет у рази важчий поводиться так само.
Збереженість роботи користувача під час обриву зв'язку
Раніше правки жили в пам'яті вкладки: обрив мережі або збій під час збереження означали втрату частини макета. Тепер кожна операція спочатку фіксується в локальному сховищі браузера, а потім іде на сервер із повторними спробами та захистом від дублювання.
Відновлення після збою займає секунди — користувач повертається рівно в той стан, у якому його застав обрив.
Спільна робота над макетом
Правки зливаються за об'єктами: зміна одного блоку не блокує макет повністю, текст зводиться посимвольно, конфлікт вирішується детерміновано, курсори колег видно в реальному часі.
Частка успішних збережень тримається вище 99 %, а клас відмов «правки втрачено під час обриву» зник повністю.
Способи організації графічного ядра: порівняння підходів
Ключова розвилка — де живе сцена і де рахуються пікселі: на сервері чи в браузері користувача. Від цього залежать і режими роботи редактора, і те, як поводитиметься спільна робота при зростанні кількості учасників.
Серверний і клієнтський шляхи рендерингу
Серверний рендеринг макетів передбачуваний: той самий файл дає однаковий результат незалежно від пристрою та набору шрифтів у системі. Клієнтський рендеринг у браузері дає миттєвий відгук на перетягування та зум, тому що кадр рахується локально, без звернення до сервера. Так влаштовані редактори рівня Canva, де полотно та історія правок живуть у користувача.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Серверний рендеринг макетів | Пакетні задачі: прев'ю, друковані шаблони, звітні документи, макети фіксованого формату | Правка запізнюється: кожен крок — запит і черга. При насиченні сцени об'єктами час відгуку зростає лінійно |
| Клієнтський рендеринг у браузері | Інтерактивне полотно, де важливі зум і перетягування без затримки; великі багатошарові макети | Обмежена пам'ять вкладки: важкі сцени дробимо на шари й підвантажуємо частинами. Поведінка залежить від браузера |
| Гібрид: сцена в браузері, важкі операції на сервері | Основний сценарій продукту: правки в користувача, експорт і друк на боці сервісу | Потрібна синхронізація сцени та стабільний формат обміну, інакше версії розходяться при конфлікті правок |
Як вибрати режим під профіль навантаження
Рахуємо профіль: скільки об'єктів у типовому макеті, скільки учасників правлять його одночасно, яка частка сесій закінчується експортом.
Якщо полотно невелике і важливіша точність друку — ведемо сцену на сервері; якщо макет зростає до тисяч шарів і його правлять у реальному часі — рахуємо в браузері, а експорт виносимо на сервер.
Формат зберігання при цьому один: векторне дерево шарів плюс зображення окремими об'єктами, без вбудовування у файл сцени. Так макет залишається компактним, а спільні правки зводяться швидко.
Вибір архітектури редактора ми фіксуємо до старту розробки — на прототипі з реальними макетами замовника, де видно граничне навантаження.
Етапи впровадження: від аудиту поточного коду до передачі
Етапи розробки онлайн-редактора йдуть від обстеження до передачі: на кожному кроці фіксуємо результат, який можна перевірити, а не абстрактну «готовність». Порядок робіт підбираємо під стан поточного коду — переписувати все одразу майже ніколи не потрібно.
Що відбувається на етапі обстеження
Аудит наявного редактора починаємо з моделі документа: шари, історія змін, права на файли, формати експорту та імпорту. Окремо дивимося, де зростає час відгуку — перемальовування полотна, завантаження зображень і шрифтів, синхронізація учасників. Результат етапу — карта вузьких місць і черговість робіт з оцінкою трудомісткості.
- Обстеження. Код, дані, заміри часу відгуку на реальних сценаріях.
- Схема даних і прав. Формат документа, версіонування, ролі, спільні папки.
- Ядро редактора. Полотно, шари, інструменти, експорт із збереженням сумісності форматів.
- Спільна робота. Історія правок, автозбереження, відкат до попередньої версії.
- Навантажувальна перевірка редактора. Пікова одночасна робота та пакетний експорт великих макетів.
- Приймання та передача. Перевірка за списком сценаріїв, код, схеми, документація.
Як проходить приймання результату
Приймання редактора проходить на стенді, що повторює робочу конфігурацію: створення макета, співавторство, експорт, відновлення після обриву зв'язку. Дивимося не лише «працює», а й як поводиться система під навантаженням і після відкату.
Разом із кодом передаємо схему даних, опис прав і порядок розгортання — щоб команда могла розвивати редактор далі без нас.
Схеми, політики доступу та регламенти випуску версій
Редактор передаємо не «чорною скринькою»: разом із документацією на редактор, за якою новий інженер піднімає середовище та розбирається в моделі даних. Нижче — перелік артефактів, які залишаються в команди замовника після запуску.
Схеми зберігання та спільної роботи над макетом
- Схема зберігання макетів: структура проєкту та шарів, версії об'єктів, зв'язки з асетами, правила каскадного видалення.
- Матриця прав: ролі від власника до переглядача і те, що кожна може робити з макетом, шаблоном і брендбуком.
- Політики доступу редактора: видача та відкликання доступів, гостьові посилання, термін їхнього життя, журнал дій користувачів.
- Описи інтерфейсів: контракти між клієнтською частиною, сервісом рендерингу та сховищем при зміні формату.
Регламенти випуску версій і відкату
- Регламент випуску версій: порядок збирання, перевірки перед викаткою, склад відповідальних за реліз.
- Інструкція з відкату: до якої версії відкатуватися, як повернути попередню збірку й не втратити вже створені макети.
- Регламент міграцій: як змінювати формат макета, щоб відкриті роботи не ламалися у користувачів.
Кожен артефакт перевіряємо на повноту: колега замовника за інструкцією відтворює випуск і відкат без нашої підтримки.
Кейс: як редактор перестав втрачати правки при піковому навантаженні
Редактор шаблонів зі спільною роботою: десятки шарів, текстові блоки, зображення, експорт. Перший замір показав, що вузьке місце — не інтерфейс, а синхронізація стану між учасниками та вирішення конфлікту правок у макеті. Нижче — що переробили й як це підтвердили навантажувальним тестуванням.
Що було до переробки
На макетах від двохсот шарів відгук на дію сягав 2,5 секунди: кожне переміщення блоку перезбирало стан усього документа. На піку — близько трьохсот одночасних сесій — частка втрачених правок сягала 7%, а збої сесій траплялися в 4–6% підключень на годину.
Конфлікт вирішувався за принципом «перемагає останнє збереження»: двоє рухали один блок — версія одного мовчки зникала.
Що змінилося після
Стан перевели на операції за шарами: правка застосовується атомарно до конкретного об'єкта, а не до документа повністю. При одночасній зміні одного блоку обидві версії зберігаються й показуються автору як варіанти — клас «тихої» втрати правок зник.
Орієнтиром за плавністю був рівень, заданий Canva, але втримати його потрібно було на важких макетах.
Метрики після: відгук на макеті від двохсот шарів — 250–300 мс замість 2,5 с, втрачених правок — нуль, збої сесій на піку — десяті частки відсотка. Групування операцій у пачки знизило кількість звернень до сервера в пікові хвилини приблизно в шість разів.
Що робити, якщо редактор уже запущено і він потребує розвитку?
Живий редактор — не завершений проєкт, а потік змін: сцени, шари, історія дій, експорт.
Доопрацювання готового редактора починається не з коду, а зі зняття замірів: де відвалюється рендеринг при великій кількості об'єктів, на яких операціях зростає час відповіді, які помилки користувачі обходять вручну. Без цих цифр перебудова перетворюється на спір про смаки.
Технічний борг редактора лежить у передбачуваних місцях: модель документа розмазана по шарах інтерфейсу, стан полотна дублюється, експорт і збереження реалізовані окремо й розходяться в поведінці. Поки це не розділено, кожна нова можливість тягне правки в п'яти місцях і ламає сусідні сценарії.
Далі — пріоритизація вузьких місць за частотою звернень і ціною відмови, а не за гучністю прохань. Зазвичай першими виносять рендеринг і історію змін, потім розв'язують зберігання й експорт: прискорення отримують усі сценарії одразу, а не один.
Заміна ядра без простою йде через паралельний контур. Нова версія піднімається поруч, на неї направляють частину трафіку, результати звіряють із поточними — і лише потім перемикають решту.
Перемикання робиться флагом на боці сервісу, відкат — поверненням флагу; дані мігрують поступово, а не одним вікном.
Розвиток наявного продукту далі йде короткими релізами із загальним набором перевірок: сервіс залишається робочим на кожному кроці, а зміни доходять до користувачів частинами.
Технічні сумніви: продуктивність, безпека, строки
Інженерні сумніви зазвичай стосуються не самого редактора, а того, що відбувається при зростанні навантаження та під час передачі проєкту іншій команді. Нижче — відповіді на запитання, які найчастіше виникають на етапі оцінки.
Кілька авторів правлять один макет — що буде з конфліктами?
Правки йдуть окремими операціями над об'єктами, а не перезаписом усього документа, тому двоє авторів на сусідніх шарах не блокують одне одного.
Зміни доїжджають до решти учасників майже миттєво, конфлікт за одним об'єктом вирішується за фіксованим правилом, а кожна версія макета залишається в історії — відкат до будь-якої точки доступний.
У нас є свої шаблони — їх доведеться збирати заново?
Ні. Конвертер розбирає вихідні файли: текстові та векторні шари переносяться як редаговані об'єкти, растрові — як зображення зі збереженням пропорцій. Результат звіряється пакетним порівнянням з оригіналом, тому бібліотека переїжджає без ручного перезбирання.
Чи витримає редактор пікове навантаження?
Рендер і експорт винесено в окремі сервіси та масштабуються незалежно від інтерфейсу, а важкі операції йдуть у чергу й не гальмують роботу решти користувачів. Відзивчивість залишається рівною при зростанні кількості одночасних сесій у рази.
Як у редакторі розмежовуються права?
Ролі налаштовуються на рівні акаунта, папки та окремого макета: перегляд, коментування, правка, публікація. Перевірка прав виконується на сервері при кожному запиті, а не приховуванням кнопок в інтерфейсі, тому обійти обмеження через запит не можна.
Як випускаються оновлення, якщо редактором уже користуються?
Міграції схеми даних робимо зворотно сумісними, викатка йде поступово й супроводжується автоматичним відкатом при зростанні помилок. Активна сесія автора при цьому не рветься: незбережений макет дозаписується у фоні.
Обговоримо задачу: надішлемо оцінку та план робіт
Перша розмова триває 30–40 хвилин і проходить без презентацій: розбираємо користувацькі сценарії майбутнього редактора, хто в ньому працює, які формати на вході та виході, як зберігаються файли і як влаштовано доступ. Цього достатньо, щоб зрозуміти клас задачі, її обсяг і де розташовані основні ризики.
Від замовника потрібен мінімум: приклади того, що редактор зобов'язаний уміти, список форматів імпорту та експорту, вимоги до спільної роботи й ролей, точки інтеграції — вхід, зберігання, оплата, аналітика.
Якщо частину вимог ще не визначено, фіксуємо припущення й перевіряємо їх на першому етапі, а не закладаємо в оцінку навмання.
З оцінкою та планом етапів повертаємося за 2–3 робочі дні. До плану входить:
- сценарії роботи: полотно, шари, інструменти, скасування дій, історія версій;
- розділення обчислень: що виконується в браузері, що на сервері, як влаштовано експорт;
- схема даних і зберігання: звідки надходять файли, де лежать, як віддаються користувачу;
- перелік інтеграцій: вхід, оплата, зберігання, аналітика, зовнішні сервіси;
- ролі та доступи: хто що бачить і править, обмеження за одночасним навантаженням;
- етапи розробки з порядком, складом кожного та точками приймання результату;
- оцінка трудовитрат за етапами та список ризиків із планом їх зняття.
Опишіть задачу у вільній формі: що за редактор, для кого він і що вже є на руках. Повернемося з оцінкою, планом робіт і зрозумілим першим кроком.
