База даних чи Статичний

Довгий час ми жили у світі, де використовуємо стандартні підходи, не замислюючись над їхньою метою. Візьмемо, наприклад, WordPress: це потужний застосунок, але він потребує MySQL як базу даних, а щоб зробити його швидким, часто потрібно Memcache для кешування запитів MySQL і зменшення навантаження на базу даних. Поряд з цим існує WYSIWYG редактор, який, теоретично, дозволяє користувачам легко редагувати HTML, але на практиці часто генерує важкочитабельний та переповнений код.

Але основне питання: чому ми це робимо? Ми встановлюємо WordPress, MySQL і Memcache для того, щоб створити по суті "статичні" сторінки, тому що WordPress може бути повільним, а оновлення контенту зустрічаються рідко. Для кожної згенерованої сторінки:

  • Базовий сайт на WordPress робить 10-30 запитів.
  • Помірно складний сайт з кількома плагінами та популярною темою: 30-60 запитів.
  • Дуже складний сайт з багатьма плагінами та важкими темами може робити 60-100+ запитів.

Навіть проста блог-записка може вимагати від 10 до 100+ запитів, що пояснює, чому сайти на WordPress можуть бути повільними.

Чому Ми Обираємо WordPress?

Головне питання залишається: Чому ми використовуємо такий складний механізм? Історично, використання реляційної бази даних, як MySQL, для блогу мало сенс, тому що люди могли залишати коментарі, а бази даних надавали швидкий спосіб зберігати і отримувати цю інформацію. Але сьогодні мало які сайти на WordPress мають увімкнені коментарі через нескінченний потік спаму, який часто з цим пов'язаний. Як результат, більшість сайтів покладаються на сторонні рішення, такі як Disqus або Facebook Коментарі для управління коментарями користувачів. Ці сервіси беруть на себе верифікацію користувачів і фільтрацію спаму, що означає, що нам більше не потрібна база даних для обслуговування динамічного контенту у вигляді коментарів.

Статичний Підхід

У True ми обрали повністю статичний підхід. Ми використовуємо статичні файли як нашу "базу даних":

  • blog.php обробляє сторінки блогу.
  • support.php обробляє сторінки підтримки (історично різні, але тепер схожі за форматом).
  • categories.php обробляє список категорій у верхньому меню та боковій панелі.

Ми зберігаємо весь блог як прості файли PHP або JSON, що є ефективним, оскільки ми використовуємо PHP для запуску нашого сайту.

Ось як це працює:

database blog

storage

Кожен запис блогу зберігається як папка, що містить файл у форматі markdown (_.md) та пов'язані ресурси, такі як зображення та вкладення.

storage folder

У нас також є два додаткові папки для:

  • Translate: Зберігає переклади файлів markdown на різні мови (наприклад, es_ES, de_DE).
  • HTML: Містить згенеровані HTML файли з markdown, які генеруються знову при кожному розгортанні.

Магія відбувається під час процесу розгортання. Ми використовуємо Composer, щоб ініціювати перетворення з markdown у HTML за допомогою скриптів:

"scripts": {
    "post-install-cmd": [
        "php bin/markdown-to-html.php"
    ],
    "post-update-cmd": [
        "php bin/markdown-to-html.php"
    ]
}

Найкращим інструментом для перетворення markdown, який ми знайшли, є league/commonmark, який має корисні плагіни, включаючи підтримку таблиць і власні шляхи до CDN для наших зображень.

Розгортання

Ми використовуємо процес розгортання на основі GitHub Actions та Deployer, яке було легко інтегрувати. Ось приклад скрипта:

name: Deploy
on:
  push:
    branches: [ "main" ]
concurrency: production_environment
jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: "8.3"

      - name: Deploy
        uses: deployphp/action@v1
        with:
          private-key: ${{ secrets.PRIVATE_KEY }}
          dep: deploy
          verbosity: -vvv

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

  1. Копіювання зображень у папку public/img.
  2. Генерацію хеш-карти для всіх зображень та вкладень.
  3. Генерацію HTML з markdown файлів з: • Виправлення шляхів до зображень (наприклад, з /img/blog/... до cdn.truesocialmetrics.com/img/blog/...). • Оновлення шляхів до CDN, де це потрібно.

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

Переваги Статичного Підходу

Продуктивність

Статичні сайти надзвичайно швидкі, з часом завантаження сторінки всього 3-5 мс.

Простота

Навчити нашу команду підтримки використовувати Markdown набагато простіше, ніж навчити їх навігації в складному CMS, як WordPress.

Чистий Код

Контролюючи процес перетворення markdown у HTML, ми забезпечуємо чистоту та оптимізацію HTML для пошукових систем (привіт, Google!) та функцій, як "Режим читача" у браузерах.

Підтримуваність

Оскільки ми використовуємо статичні файли та Git для контролю версій, кожна зміна відслідковується автоматично, навіть до окремих рядків. Вкладення, такі як зображення, також виграють від контролю версій, тому ми завжди знаємо, хто вніс зміну і чому. Це робить пошук і модифікацію контенту ефективними, використовуючи інструменти, такі як grep і ack.

Доступність для Команди

Наша команда знаходить статичну структуру легкою в роботі, особливо з такими інструментами, як GitHub Desktop та Typora, простий і гарний редактор markdown.

Висновок

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



Коли ви будете готові розгорнути свою аналітику в соціальних мережах

спробуйте TrueSocialMetrics!


Почніть пробну версію
Кредитна картка не потрібна.






Продовжити читання →




Соціальні мережі: від крику до розмови
Ера телевізійної реклами, друкованої преси, радіо та інших каналів «монологічного маркетингу» відійшла в тінь. Головна перевага нових каналів зв’язку – реакція користувачів. Але, звикнувши до старих каналів, маркетологи все ще використовують нові за тією ж схемою: всюдисущі кричать про свій бренд, не розраховуючи на відгук.


Розкішні бренди у Facebook: аналіз найкращого та найгіршого контенту, або Чому фанати Prada ненавидять костюми
Ви коли-небудь замислювалися про те, як розкішні бренди працюють у соціальних мережах? У цій статті ми розповімо, яку складну тактику контенту використовують маркетологи предметів розкоші, щоб залучити своїх шанувальників і як вони конкурують між собою. І чому шанувальники Prada ненавидять костюми. Ми проаналізуємо Facebook-акаунти 6 топ-брендів класу люкс Burberry, Chanel, Louis Vuitton, Gucci, Prada, Hermes.


Три речі, які кожен повинен знати про Analytics
Ваш сайт, сторінка в соціальних мережах або бренд схожі на темну кімнату – ви не маєте уявлення про те, що відбувається всередині, як клієнти взаємодіють з вашим продуктом, що вони думають про ваш контент тощо. Тобто до тих пір, поки ви не включите ліхтарик аналітики. Раптом ви бачите, що клієнти ненавиділи ваші публікації про Super Bowl і ваші надихаючі прислів’я, але цілком сподобалися ваші дурні відео про котів; що у них виникли проблеми з підпискою на вашу розсилку на сайті та вони не знають, як переміщатися на сторінці цін.


Google Analytics Hacks
Google Analytics (GA) is an exceptional analytical engine, but it lacks an inherent understanding of your business’s critical metrics. Whether your key online goals revolve around subscription purchases or phone calls, GA needs customization to reflect what’s most important to you. This guide will focus on how to categorize streams of data—such as visits, events, clicks, views, and scrolls—into meaningful groups to facilitate deeper and more effective analysis.