Статичний веб: повернення до витоків?

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

Спочатку була статика.

У перші дні інтернет був товариством ентузіастів, розробників та інженерів. Незважаючи на часті порівняння між MySpace і Facebook, ці два сервісу принципово відрізняються. Вони також добре демонструють різницю в «інтернет-парадигмі» відповідного часу.

І те, і інше — соціальні мережі, але створення сторінки на MySpace вимагало базового розуміння HTML і CSS. Зрештою, сайт відкрився в 2003 році. З іншого боку, простий у використанні інтерфейс Facebook допоміг розширити аудиторію до двох з гаком мільярдів користувачів.

За антагонізмом MySpace/Facebook лежить критична точка напруженості в інтернеті: як взаємодіяти з контентом, який ми редагуємо? Тут є два основних способи.

  1. WYSIWYG (What You See Is What You Get) — як випливає з назви, у цій парадигмі мета полягає в тому, щоб редактор як можна точніше показував остаточний рендеринг. Одним з перших прихильників такого підходу був WordPress, пізніше приєдналися інші. Онлайн-редактор Medium (показаний нижче) на базі TinyMCE вважається одним з кращих WYSIWYG-редакторів в інтернеті.


    Попередня версія редактора Medium

  2. Ефективність понад усе. WYSIWYG-редактори подобаються новачкам, але зазвичай вони обмежені у функціональності або незручні. У кінцевому рахунку, додавання деякого синтаксису збільшує складність, але також дозволяє краще контролювати остаточний рендеринг контенту. Крім того, форматування все одно виконується з допомогою визначеного синтаксису HTML, CSS, Markdown…), тому не залежить від використовуваного редактора.

Схід WordPress
WordPress швидко захопив інтернет: в даний час у нього близько 60% ринку CMS. Він настільки поширений, що його можна розглядати як глобальну веб-платформу: близько третини всіх сайтів в інтернеті використовують WordPress.

Успіх не означає релевантність. Насправді досвідчені користувачі відмовляються від WordPress з різних причин:

  • Редагування: робота з WP, навіть з новим Guttenberg — справжня мука. Редактор повільний, незграбний і поставляється з заплутаною блокової логікою. Спроби відформатувати і відредагувати вміст призводять до марної трати часу і пошуку альтернативних варіантів. Крім того, він за замовчуванням не підтримує жодних інтелектуальних функцій, таких як виноски або таблиці. Вони вимагають абсурдно складного робочого процесу або ще одного плагіна.
  • Безпека: з-за свого успіху WordPress став головною метою хакерів. Будь великий WP-сайт повинен реалізувати додаткові заходи захисту (плагіни?) для обробки різних типів атак. Крім того, WordPress підтримує всі версії PHP від 5.2.4 (випущеної 12 років тому) до 7.2. Додайте всі плагіни і теми — і ви отримаєте нескінченний список атак. Ось огляд найбільш поширених.
  • Продуктивність: з коробки WordPress жахлива продуктивність. З деякими плагінами (кеш, CDN…) та іншими налаштуваннями ви можете прискорити — але ви хочете цим займатися? Хіба сенс веб-фреймворку не в мінімізації зусиль по оптимізації?
  • Роздуття плагінами: з-за всіх плагінів, необхідних WordPress, він в кінцевому підсумку уповільнює роботу сайту і погіршує безпеку. Свіжа установка WP вимагає 5-10 плагінів для роботи і 10-15 для «оптимізації»: кешування/мініфикація, CDN, стиск зображень, SEO (YoastSEO, RankMath), редиректи, безпека, боротьба зі спамом в коментарях, форматування (синтаксис коду, зовнішні посилання та ін). Будь-яка додаткова функція вимагає установки ще одного плагіна: багатомовність, кнопки соціальних мереж, імпорт Markdown, виноски, генерація змісту, каруселі…

Зробимо його статичним!
Коли WordPress dsitk у 2003 році, у нього майже не було конкурентів. Але це було 15 років тому. Пізніше з’явилися цікаві інструменти і фреймворки для форматування текстів, а також для публікації і рендеринга. Розвиток йшло паралельно, що проклало шлях для статичного веба.

Почнемо з редагування і зосередимося на Markdown.

Схід Markdown

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

Нові полегшені мови розмітки, такі як Markdown, пропонують надійну альтернативу для редагування контенту. Вони підходять навіть користувачам нетехнічного профілю. Досить витратити годину на вивчення шпаргалки — і ви скоротите час форматування текстів практично до нуля.

Дійсно, Markdown досить простий, швидкий в освоєнні, при цьому неймовірно потужний. При використанні Markdown і деяких сполучень клавіш автор може одночасно писати і форматувати свій контент. Крім того, Markdown пропонує безліч варіантів експорту (HTML, PDF, LaTex, doc…) і гарантує, що форматування збережеться незалежно від формату.

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


Приклад архітектури JAMstack

Управління версіями подобається не тільки програмістам, але і письменникам!

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

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

Зрештою, як це ні парадоксально, але репозиторії Github являють собою досить переконливу CMS:

  • Просте управління доступом. Логіка гілок підходить для редагування та публікації текстів. Наприклад, якщо потрібно суворо контролювати публікацію контенту, то повноваження на злиття в головну гілку можна видати тільки головному редактору.
  • Логіка гілок. При використанні репозиторію в якості CMS гілки можуть служити різним цілям. Можна використовувати одну гілку в якості проміжної середовища, щоб автори могли оцінити остаточний рендеринг контенту на своїй машині.
  • Історія файлів. З репозиторіями GitHub ви одержуєте доступ до всієї історії файлів і легко порівнюєте версії. Це зручно, особливо якщо у блозі багато різних авторів.
  • Не потрібна установка. Репозиторій можна відкрити одним клацанням миші. У сервісі начебто Netlify ще одне клацання — і блог в онлайні.

Жирні сторінки відсікають аудиторію
Досі ми розглядали переваги статичних веб-сайтів дуже прагматично: з точки зору продуктивності або підвищення ефективності. Давайте повернемося трохи назад і оцінимо загальну картину.

Середній розмір сайту зараз набагато перевищує 3 МБ, станом на 2017 рік. Але набагато важливіше зміна структури веб-сторінки. Для довідки, ось еволюція середньої сторінки з 2011 року:


Роздування середньої веб-сторінки. Джерело: Speed Matters

Для порівняння, у нашому блозі головна сторінка важить 10 КБ, а середня сторінка (включаючи зображення) — близько 400 КБ.

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

Навіщо мені завантажувати всю роздуту сторінку на три з гаком мегабайта, щоб прочитати текст, де може бути всього кілька слів?

Пам’ятайте про користувачів

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

В кінцевому підсумку ми приходимо до такого висновку: створення непотрібної динамічного веб-сайту в 2019 році завдає шкоди суспільству. Інтернет — це спільний ресурс. Чому б нам не спробувати уникнути ще однієї трагедії громад, адже для цього не потрібно нічого, крім здорового глузду?

Користувачі йдуть з повільних сайтів

Давайте просто запитаємо у розробників сайтів, які в 12 разів масивніше, ніж повинні бути: звідки у вас стільки ненависті? В ідеальних умовах середньостатистичному користувачеві із середнім підключенням 7,2 Мбіт/с потрібно більше трьох секунд, щоб завантажити одну сторінку.

Який ефект? Ніл Патель, відома фігура в SEO-співтоваристві, зробив дуже докладну інфографіку на цю тему. За його оцінками, 40% (на мобільних пристроях 53%) користувачів йдуть зі сторінки, завантаження якої перевищує три секунди. Таким чином, виникає абсурдна ситуація:

Новинні, медійні та інші сайти втрачають до 40% аудиторії з-за низької продуктивності, обумовленої необґрунтованим вибором динамічної візуалізації. Ця цифра не включає трафік з пошукових систем через погіршення SEO.

Так що давайте знімемо жир. Навіщо стільки скриптів? Невже в 2019 році так складно реалізувати правильну обробку зображень (зміна розміру, стиснення, порядок завантаження)?

«Як взагалі динамічний движок, який постійно заново генерує один і той же статичний контент, став стандартом Інтернету?» — Флоран Шово
Переходимо на статику
Ми переконані, що скоро статичні сайти стануть звичайним явищем. У той же час статичний сайт легко перемагає роздутого динамічного конкурента в SEO-грі: настав час пограти!

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


Переходи з пошукових систем (органіка)

На щастя, з моменту випуску Jekyll в 2008 році з’явилося набагато більше статичних генераторів веб-сайтів і інших супутніх сервісів.

Читайте також  Виявлення сарказму з допомогою нейромереж згорткових

Степан Лютий

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

You may also like...

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *