Як я 4 місяці робив конвертери картинок, а трафік прийшов з JSX to HTML

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

gsc-stat

Зовсім недавно працював над черговим сайтом на фрілансі...

І як завжди:

  • клієнт скидує багато фото по 2-3 мб
  • немає ні логотипу ні фавіконів нічого
  • іноді навпаки фото в поганій якості
  • з гпт треба генерити json+ld та sitemap (а потім ще правити їх згідно google docs)

Та інші маленькі проблеми які зїдають по 10-15 хвилин якщо немає швидкого рішення

Ну я не розгубився! В мене вже збережено 100500 сайтів-сервісів по конвертації, генерації, оптимізації та інших інструментів які якимось чином полегшують роботу

І тут починається: на одному генеруєш фавікони, на іншому оптимізовуєш картинки ще десь конвертуєш у webp, десь 2 млн реклами казино і тд

І мене осінило: а чому б не створити свій власний ресурс на якому буде все це і без реклами, всеодно після роботи є 1-2 години які можна потратити на щось корисне, а ще додатково зануритись у СЕО і спробувати більше розібратись в цьому напрямку

Так у квітні почався devtools.abect.com

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

Помилка перша. Ставка на картинки

Я був впевнений на всі 100% що витягнуть конвертери зображень; png to jpg, стиснення, webp — це ж те що гуглять всі, тут навіть думати не треба. Зробив 22 пари конвертацій форматів, три компресори, генератор фавіконок

Це більше половини сайту

Спойлер: не витягнули)))

Що зробив правильно

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

Тобто не /images/convert/png-to-jpg, а просто /png-to-jpg, /webp-to-png, /avif-to-webp. Проста структура, менше зайвої абстракції, окрема сторінка під окремий інструмент. Ось це спрацювало, але зрозумів я це тільки через три місяці

Помилка друга. Не рефакторив вчасно

Сідаю додавати нову тулзу, відкриваю проект і бачу. DropZone вже є в WebP Converter, в Image Converter, в Compress Image і в Favicon Generator. Чотири копії одного компонента, кожна в своїй папці

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

Зупинився))) Виніс усе що дублювалось у спільний UI Kit

Підсумок: мінус 4500 рядків коду. Не тому що щось видалив, а тому що виявилось що половина проекту це була одна і та ж річ написана кілька разів

Класика пет-проекту

Про те як це писалось

Увесь сайт я вайбкодив, тобто не писав код руками, але виявилось що «не писати код» і «не розбиратись в коді» це дві різні речі. Найдовше сидів над генератором фавіконок, там .ico збирається вручну через DataView — заголовок, directory entries, кадри 16, 32 і 48 пікселів

Довелось читати ICO binary spec і перевіряти кожен offset руками, бо AI впевнено генерував робочий на вигляд бінарник який не відкривався. Тобто AI пришвидшує написання і не пришвидшує розуміння

Перше розчарування

Через місяць після старту додав JSON-LD розмітку на всі сторінки і пішов дивитись Search Console

За 28 днів +1600 показів у Google І цілих 3 кліки

Три, Карл

Середня позиція 61.3, тобто Google показує мій сайт десь на 6-й сторінці пошуку, це як повісити картину на виставці у підвалі і самому нею милуватись

Тоді я вирішив зупинитись і замість нових тулзів піти перероблювати те що вже є

Що зараз

Сьогодні відкрив Search Console за 28 днів:

![Search Console за 28 днів: 664 кліки, 21,4 тис показів, середня позиція 23]()

  • 664 кліки
  • 21,4 тис показів
  • Середня позиція 23

З шостої сторінки пошуку на другу, але найцікавіше не цифри

Топова сторінка: JSX to HTML конвертер, 491 клік Друга: TSX to HTML, зростання 813% Топ запит: «jsx to html», 185 кліків

А конвертери картинок, заради яких все починалось і на які пішло чотири тижні?

4 кліки — 27 сторінок. Половина сайту. Чотири кліки

Тобто вистрілила ніша в яку я зайшов між іншим, а не та в яку цілився))

Чому так

Загугліть «png to jpg» — на першій сторінці iLoveIMG, CloudConvert, Adobe, Canva. Домени по 10-15 років і бюджети яких у мене не буде ніколи і справа не в контенті

На тих сторінках у мене є все що вважається правильним: таблиці порівнянь форматів, пояснення як працює Canvas, по 10-12 FAQ, структуровані дані, пререндер, сторінки нормальні — вони просто невидимі

А «jsx to html» це запит в який ніхто з бюджетом не заходив. Там у видачі документація і відповіді зі стековерфлоу, а не оптимізовані лендінги. Одна нормально зроблена сторінка заходить в топ-5 за кілька тижнів

Різниця не в зусиллях і не в якості Різниця в тому чи там уже хтось сидить

Що реально спрацювало

Нічого магічного:

  • окрема сторінка під кожен інструмент замість однієї універсальної
  • пререндер у статичний HTML: Google отримує готову сторінку і не мусить виконувати JS
  • 5-10к символів реального контенту на сторінку, таблиці порівнянь, гайди під React/Next/WordPress, 10+ FAQ
  • JSON-LD на кожній сторінці: WebApplication + HowTo + FAQPage
  • title і description під конкретний біль користувача, а не «конвертуй X в Y безкоштовно»

Нудно? Дуже

Але коли в тебе немає ні бюджету, ні беклінків, ні бренду — працює саме це. Просто повільно

Головний висновок

Я дивився на частотність запитів і не дивився хто вже стоїть у видачі Запит у сто разів менший, але без серйозного конкурента, вартий більше ніж усі мої 27 сторінок разом І ще одне: 49 інструментів це не 49 шансів. Це один шанс і 48 способів не знати який саме спрацює Нічого не видаляю, сторінки нічого не коштують і комусь інколи допомагають Але 28-го конвертера картинок не буде, все наступне в бік коду: Vue, Svelte, CSS в Tailwind

Про сам сайт

devtools.abect.com — 49 безкоштовних інструментів: конвертери зображень, компресори, генератори фавіконок, OG-зображень, мета-тегів, JSON-LD схем і конвертери коду

Все працює в браузері через Canvas API, File API і Blob URL. Нічого не завантажується на сервер, бо бекенду для цих інструментів просто немає. Без реєстрації, без лімітів, без вотермарків, без реклами

Відкрийте DevTools -> Network під час конвертації, там порожньо

Вихідники відкриті під MIT

Той самий конвертер який все це витягнув: devtools.abect.com/jsx-to-html

А у вас було таке що трафік прийшов зовсім не туди куди ви цілились?

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

А не можна було ffmpeg загорнути та не витрачати час на вивчення усіх цих форматів?

він дозволяє конвертувати прямо на клієнті без відправки на сервер?

Так, в мене він обробляє зображення на моєму клієнті, якщо його встановити.

А звідки взялось архітектурне обмеження, що не можна відправляти на сервер?

Мені, як користувачу, байдуже де воно обробляється.

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

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

З точки зору користувачів важливо те, що їх інформація не покидає їх комп’ютер

Це не так. Якщо би це дійсно було важливе, то хмари як бізнес не злетіли би. А так: пошта в хмарі, файли в хмарі, фотки в хмарі, слак в хмарі, код в хмарі, штучний інтелект в хмарі.

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

Думаю є сенс розрізняти хмари як бізнес типу iCloud, Google Drive, AWS і щойностворені сайти які зроблені для SEO, якщо у першому випадку все більш-менш прогнозовано і безризиково, то у випадку сайтів (особливо тих, які просять реєстрацію для конвертації) бувають випадки коли все виглядає і працює досить підозріло.

у першому випадку все більш-менш прогнозовано і безризиково

Ось заходжу я на haveibeenpwned.com (сайт, який показує де були витоки моїх персональних даних та паролів), перевіряю власний імейл, та бачу такі прогназовані та безризиковані бренди як: Twitter, Gravatar, Canva, Apollo, LiveJournal, bit[.]ly, tumblr, Dropbox, LinkedIn.

Тому «хранити в хмарі поважної компанії» це не дорівнює «безризиково».

По-друге: коли я лого пережимаю на favicon — який взагалі ризик? Що вкрадуть мій favicon? Так він і так на сайті вказаний. Усі ці конвертори створені для того, щоб як раз і викладати в паблік зображення.

який взагалі ризик?

Ось такий був випадок, не про фавіконки, правда, але все одно варто таке враховувати:
casparwre.de/blog/seo-scam
news.ycombinator.com/...​30&utm_source=chatgpt.com

Це типова supply-chain атака. І «прогнозовані та безризикові» компанії теж можуть бути середою для розповсюдження шкідливого коду.

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

Зараз такий час, що часто простіше і швидше навайбкодити таку утиліту, ніж знайти в інтернеті, я недавно в 1 промпт навайбкодив:

Підписатись на коментарі