Факап вебпроєкту, або Як втратити $45 000 через розробку сайту на Flutter

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

Вітаю, я — Борис Барський, Co-founder сервісної компанії Lampa Software. Уже понад вісім років ми займаємося розробкою IT-рішень для бізнесів. Зокрема, зосереджені на створенні мобільних продуктів, а також застосунків для SmartTV (Android, Apple, Samsung та LG).

Одним з важливих каналів лідогенерації для нас є корпоративний вебсайт. Останній раз ми робили його редизайн ще понад п’ять років тому, і в середині 2022-го постало нагальне питання про модернізацію — як візуальної, так і технічної частини.

Ми вирішили відійти від традиційних JS-фреймворків і спробували зробити корпоративний вебсайт на Flutter.

Нижче розповім історію про те, як ми намагалися побудувати середнього розміру вебсайт на Flutter. А також як потенційно витратили на нього не менше $45 000, на які труднощі натрапили та до якого висновку дійшли.

Сподіваюсь, цей досвід збереже час, нерви та гроші як розробникам, так і компаніям загалом.

Чому саме Flutter

Наше знайомство з фреймворком від Google почалося ще у далекому 2018 році. Тоді фреймворк ще навіть не доріс до stable-версії, а перебував у beta.

Відразу зазначу, що перші спроби були досить вдалими. Розробка на платформі мала низку суттєвих переваг (і мовиться не лише про економію бюджету).

Водночас неприємних компромісів (про них — далі), традиційних для кросплатформових рішень, виявилось не так багато.

А порівнювати нам є з чим: свого часу ми перепробували більшість мейнстримних «вбивць» нативної розробки: Phonegapp, Cordova, Xamarin, React Native.

Слід сказати, що тоді Google позиціював Flutter насамперед як платформу для мобільної розробки. Але згодом було заявлено і про підтримку web- та desktop-застосунків.

Саме цей факт, помножений на наш вдалий попередній досвід та традиційну схильність до експериментів і новаторства, переконав нас у доцільності такого підходу.

Крім того, ми планували використати наш сайт як свого роду «вітрину» Flutter для потенційних замовників, які все ще з острахом ставились до нової технології.

Отже, за результатами брейнштормів була сформована команда, і все закрутилося.

Коротко про фреймворк Flutter. Переваги та недоліки

Перед тим, як перейти безпосередньо до історії розробки сайту, кілька слів про сам Flutter і його технічні специфікації — для тих, хто не зовсім орієнтується, про що йдеться.

Фреймворк Flutter — це мультиплатформове технічне рішення від корпорації Google, основане на мові Dart.

Його особливість полягає в гарній оптимізації коду, архітектури та інтерфейсу для всіх типів систем, форматів і розмірів екрана. До того ж мова програмування Dart вважається досить зручною.

Застосунки, створені на базі Flutter, підтримують як ARM, так і x86-64 архітектуру та можуть працювати водночас на багатьох ключових операційних системах. Серед них: Android, iOS, macOS, Linux та навіть Windows.

Ці програмні рішення мають хороші показники продуктивності, співставні з нативними застосунками.

Серед інших переваг:

• Потокове редагування коду. Під час емуляції ПЗ можна корегувати функції та стежити за змінами в режимі реального часу.
• Дизайн. Штатного функціонала фреймворку достатньо для створення сучасного та елегантного стилю застосунка, віджетів.
• Швидкість розгортання. Розробляється лише тіло програми, яке контейнеризується для встановлення на цільових платформах.
• Універсальність. Весь дизайн, функціонал та екрани створюються для базової платформи, з подальшою адаптацією під інші.

На нашу думку, перелічені особливості Flutter й роблять його одним з найперспективніших рішень для кросплатформової розробки. Проте окрім переваг, фреймворк має й низку очевидних недоліків.

Типові проблеми фреймворку:

• Мультиплатформова розробка. Так, це є і плюсом, і мінусом. Зокрема, під час застосування низки IT-рішень потрібно орієнтуватись на особливості всіх цільових операційних систем одночасно, що в деяких випадках створює незручності та нагромадження в коді.
• Погані механіки для SEO. Неможливість підключення SSR (Server side rendering) для оптимізації швидкості роботи та налаштувань індексації контенту сайту.
• Слабка маршрутизація. Навіть у випадку веброзробки сайт на Flutter залишається за своєю суттю мобільним застосунком. Тому під час переходу на нього весь статичний контент завантажується повністю, навіть якщо наразі не використовується.
• Занадто довга перша компіляція новоствореного проєкту та наступний білдінг release-версій для iOS та Android. У великих проєктах на підготовку релізної версії може витрачатися 15-40 хвилин.
• Інколи болючі переходи між major-версіями. Мова та фреймворк активно змінюються, тому постійно виникають особливості, що потребують від розробника додаткової роботи (наприклад, як у випадку з появою null safety).

Утім повертаємось до історії розробки.

Початок роботи над вебсайтом

У нашій компанії існує така практика, що перед стартом будь-якого проєкту ми завжди маємо сформулювати чітке розуміння, навіщо ми його робимо і яких цілей прагнемо досягти.

Тому й цього разу поставили собі низку конкретних вимог до результату:

• проактуалізувати дизайн сайту;
• повністю оновити застарілий технічний стек;
• підготувати та наповнити вебсайт додатковими розділами та даними для більш потужного SEO;
• реорганізувати навігацію та форму зворотного зв’язку;
• покращити швидкість роботи та продуктивність сайту;
• відключити російськомовну версію 🙂.

Для реалізації задуманого була сформована команда в такому складі:

• два дизайнери (основний та арткерівник);
• два Flutter-розробники;
• backend-розробник;
• QA-спеціаліст;
• project-менеджер.

Сумарно розробка першої версії корпоративного сайту на Flutter, а також API та власної CMS зайняла орієнтовно 3-4 календарних місяці.

За цей час ми відмалювали приблизно 90% сторінок (десктоп, планшет та мобільну версію) й реалізували близько 75% всього майбутнього функціоналу сайту.

Закінчивши основну частину роботи, ми перейшли до етапу фіналізації проєкту. Він містив виправлення багів, додавання різноманітних «плюшок» у вигляді симпатичних анімацій, а також оптимізацію продуктивності та серйозну роботу з інструментами для SEO.

Зазначу, що в напрямі SEO та Digital marketing ми співпрацюємо з досвідченим агенством, яке одразу поставило нам жорсткі вимоги до структури сайту та підготовки до його просування.

Саме на цьому етапі ми зрозуміли, що історія розробки на Flutter пішла не зовсім у правильному напрямі.

Проблеми, проблеми й ще раз проблеми

Ще у розпал роботи над проєктом ми почали помічати проблеми зі швидкодією та завантаженням сайту, особливо в деяких сценаріях. Проте на початку вони проявлялися доволі м’яко.

Тому ми сприймали їх як тимчасові труднощі, які бувають у будь-яких експериментах і які з часом за умови докладання певних зусиль можна буде подолати.

Але що глибше ми в це занурювались, то більше нюансів з’являлось.

Проблема #1. SEO

По суті, у проєкті на базі цього фреймворку завжди існує статична сторінка, яка змінюється тільки тоді, коли повністю завантажиться рушій Flutter. І вже після цього починають прописуватися всі метатеги, розмітка та інші інструменти для індексації, а сайт стає видимим для пошукових ботів.

Проблема в тому, що зазвичай боти не дочікуються повного завантаження контенту, тому сайт не може нормально індексуватися у пошукових системах. Тобто фактично можливості SEO «з коробки» просто відсутні.

Для розв’язання аналогічної проблеми в типових JS-фреймворках був придуманий SSR, але у Flutter він не підтримується. Натомість все грунтується на CSR (client side rendering).

Цей нюанс впливає також і на відображення превʼю посилань на сайт, поширених у соцмережах, месенджерах тощо. Будь-яке посилання на певну сторінку сайта завжди відображатиме один і той самий статичний контент, який був прописаний для першої сторінки.

Порівняння відображення превʼю сторінок на Flutter та React.js відповідно

Проблема #2. Недостатня продуктивність сайту

Оскільки Flutter побудований навколо CSR, весь інтерфейс завжди промальовується на потужностях самого пристрою. Тому фреймворк надмірно навантажує пристрої, на яких запускається програма.

І якщо в браузері ПК це ще не так помітно, то під час завантаження на мобільних девайсах справи зовсім кепські.

Зокрема наш сайт «гальмував» настільки помітно, що нам не потрібні були навіть спеціальні інструменти для визначення рівня продуктивності.

Порівняння продуктивності сайту на Flutter та React.js відповідно

Фреймворк Flutter завжди завантажує весь вміст сайту замість необхідної сторінки.

Це викликає затримки та значний розхід трафіку на відкриття сайту. До того ж не найкращим чином впливає на оцінку продуктивності такими інструментами, як-от Google Performance Tools. У нашому випадку за 100-бальною шкалою сайт отримав гордий знак питання.

Цікавий нюанс: швидкість завантаження була різною для різних роздільних здатностей екрана. Найкращий результат зафіксували на розширенні 1080×1920.

Пізніше ми встановили, що рушій щоразу також завантажує Failing Font, який збільшувався в розмірах пропорційно до кількості статичного тексту. У нашому випадку в діапазоні від 10 до 300 мегабайтів.

Проблема #3. Низька швидкість завантаження

Під час блекаутів в жовтні 2022-го ми тестували сайт за допомогою 3G-модему. Його завантаження займало 30-40 секунд для кожного циклу. І це за умови, що корпоративний сайт тоді складався з відносно простих та «легких» елементів.

Підсумки. Прагнули SEO, а отримали лише проблеми

Як ви вже зрозуміли, з SEO виникло найбільше питань. Усе через специфіку рушія фреймворку та його роботу з таблицями стилів, контентом, а також одночасним завантаженням всіх елементів.

Проте саме оптимізація була одним з найголовніших тригерів для редизайну. Тому так легко відступити ми не могли.

Стикнувшись з проблемами розробки вебсайту на Flutter, ми полізли до інтернету. Передивились десятки статей та навіть зв’язались з розробниками фреймворку.

Але і вони не надали нам відповіді на всі запитання, а просто фіксували проблеми й відправляли їх у беклог.

До того ж в один момент у своїх пошуках ми натрапили на твіт одного з топменеджерів Flutter (тепер уже колишніх). У ньому йшлося про те, що, попри офіційну підтримку, фреймворк не варто застосовувати для розробки вебсайтів.

Сказати, що ми були здивовані, це не сказати нічого. Проте і після цього ми не полишили спроб довести проєкт до розуму.

Зокрема, знайшли частковий компроміс щодо SEO. Ми додали ще один плагін, що генерував HTML-розмітку для пошукових ботів, щоб вони хоч якось могли індексувати JavaScript/Dart-контент. Однак однаково до ідеалу було далеко.

Крім цього, ще майже місяць експериментів з продуктивністю не дав бажаних результатів. Через особливості фреймворку ми так і не змогли оптимізувати швидкість завантаження та промальовки UI до рівня, за який було б не соромно.

Отже всіх наших практичних навичок та солідного досвіду роботи з Flutter не вистачило для успішного закінчення проєкту.

Тому, врахувавши за та проти, ми вирішили відмовитися від подальших експериментів з Flutter. Адже результат був негарантований, а сумарно проєкт уже затягнувся майже на пів року. І подальша втрата на нього часу просто не мала б економічної доцільності.

Було ухвалене дещо неприємне, але справді необхідне рішення про кардинальну зміну стека і розробку вебсайту з нуля.

Ми вирішили повернутись до JavaScript, класичного для веброзробки, а саме — до Next.js. І вже за 2,5 місяці (від першої стрічки коду) сайт було повністю завершено, і він став доступний онлайн. Без жодних нюансів та проблем.

Резюме

Оскільки це був наш власний проєкт, та ще й в напівтестовому режимі — формально можна вважати, що експеримент пройшов вдало.

Зокрема, ми отримали експертний досвід використання Flutter з метою веброзробки, перевірили його плюси та мінуси на практиці, дійшли певних логічних висновків.

Проте з комерційної точки зору таку розробку назвати вдалою аж ніяк не можна. Це, скоріше, провал. Ми втратили купу часу, зусиль, грошей, а фактично не отримали жодного результату.

Зокрема ми підрахували, що сумарно на розробку версії Flutter було витрачено понад 1,700 робочих годин інженерів та менеджерів:

• Design — 370 годин.
• Flutter — 500 годин
• Back-end — 350 годин.
• Project-менеджмент — 380 годин.
• QA — 160 годин.

Якщо припустити, що ми б замовили розробку такого сайту в невеликій сервісній компанії, а команда складалася б навіть не з найбільш дорогих мідлів з середніми рейтами $25-30, сумарна вартість проєкту для нас як для замовника становила б не менше $45,000.

Звісно слід враховувати, що ту ж Back-end частину ми використали повторно і під час розробки сайту на Next.js.

То що ж у підсумку: обирати чи не обирати Flutter для реалізації вебпроєкту? Вважаємо, що це рішення дуже індивідуальне.

Ваша відповідь — так, якщо ви пишете, наприклад, адмінпанель для вже наявного застосунку на Flutter. Ви можете залучити тих самих розробників чи навіть перенести певну частину коду, і це є великим плюсом.

Але перед тим, як взятися за будь-який вебпроєкт на Flutter, радимо відразу сформулювати ваші кінцеві цілі та задачі у середньостроковій перспективі. А саме: його майбутній маштаб, аудиторію, необхідність пошукової оптимізації й т. д.

Наша рекомендація із цього приводу така: якщо ваш вебсайт — це щось більше, ніж MVP чи адмінпанель, якщо він містить велику кількість графіки, статичних зображень й тексту або потребує SEO — відмовтесь від розробки на Flutter.

Натомість виберіть щось з перевіреного часом стека JS — це буде найкращим рішенням. Принаймні станом на зараз.