Налагодження продуктивності в Laravel часто починається з індексів бази даних, оптимізації запитів або апгрейду інфраструктури. Але в багатьох випадках найпростіший і найефективніший крок — визнати, що великі частини вашого Laravel‑додатка по суті статичні.
Нещодавно я поспілкувався з JMac — творцем Laravel Shift та нового курсу Fast Laravel — щоб показати, як кешування сторінок на Cloudflare може перетворити робочий Laravel‑сайт.
Як приклад ми розібрали сам Laravel News. Ось головні висновки:
За замовчуванням Laravel не дружній до кешування на рівні сторінки. Сесії, стандартні middleware та динамічний рендеринг сигналізують CDN, що відповіді персоналізовані. Через це багато Laravel‑сайтів стоять за Cloudflare, але фактично не користуються кешуванням сторінок.
У випадку Laravel News Cloudflare був увімкнений переважно для захисту від DDoS. Статичні ресурси — зображення, CSS і JavaScript — кешувалися автоматично, але HTML‑відповіді постійно обходили кеш.
Внаслідок сайт виглядав статичним для користувачів, але при кожному запиті поводився як повністю динамічний.
Для більшості сайтів головна сторінка — найвідвідуваніша з великою перевагою. Laravel News — не виняток. Незважаючи на те, що вона побудована з Livewire, головна сторінка не має інтерактивності, опитувань чи контенту, який залежить від користувача. Вона змінюється лише коли публікується нова стаття.
Це робить її ідеальним кандидатом для кешування сторінки.
Jason наголошує, що навіть короткі вікна кешування дають величезний ефект. Якщо головну сторінку кешувати 30–60 хвилин, навантаження на обчислення скорочується, а час відповіді помітно покращується.
Одна з найцікавіших тем — Livewire. Це чудовий інструмент для інтерактивних інтерфейсів, але використання його на не‑реактивних сторінках може випадково заблокувати можливості кешування.
У випадку Laravel News головна сторінка використовує Livewire-компоненти переважно як завантажувачі даних із кешованими обчислюваними властивостями. Хоч це й працює, та все одно змушує Laravel і PHP виконуватись при кожному запиті.
Пропонований рефактор мінімальний: замінити не‑реактивні Livewire‑компоненти на Blade‑компоненти або прості кешовані запити. Поведінка залишиться та сама, але сторінка стане повністю кешованою на рівні CDN.
Головний висновок — Cloudflare дає дуже багато на безкоштовному плані. Правила кешування сторінок, заголовки Cache‑Control, WAF‑правила, редиректи і навіть сервіси на кшталт Turnstile доступні без апгрейду.
Курс Fast Laravel орієнтований на точечне застосування цих інструментів, а не на перепроєктування додатків. Мета — не боротися з конвенціями Laravel, а використовувати їх свідомо.
Окрім швидших відповідей, ефективне кешування безпосередньо впливає на інфраструктурні витрати. Коли менше запитів доходить до PHP і ваших серверів додатків, падає завантаження CPU, знижується тиск на пам’ять і масштабування стає менш реактивним.
Коли Laravel News готується перейти на Laravel Cloud, це дає змогу виміряти, як кешування на рівні CDN впливає на реальне використання обчислень і щомісячні витрати.
Головний висновок простий: не потрібно переписувати додаток або відмовлятися від екосистеми Laravel, щоб досягти відчутного покращення продуктивності.
Виділивши справді статичні сторінки, зрозумівши, як налаштування фреймворку впливає на кешування, і правильно сконфігурувавши Cloudflare, багато Laravel‑додатків можуть одразу покращити швидкість і знизити витрати.
Цей кейс‑стаді від Laravel News покаже ці ідеї на практиці й буде корисним для всіх, хто тримає Laravel у проді сьогодні.
Eric Barnes (14:36.855) Привіт усім, ласкаво просимо на наш канал. Сьогодні зі мною J‑Mac, у якого класний новий курс Fast Laravel. Отже, J‑Mac, коротко: що таке Fast Laravel?
JMac (15:10.2) Fast Laravel — це новий відеокурс, присвячений кешуванню Laravel‑додатків на рівні сторінок, зокрема з Cloudflare. Це найшвидший спосіб реально поліпшити продуктивність сайту. Не потрібно тонко оптимізувати код або базу — достатньо вмикнути кешування сторінок через Cloudflare або будь‑який CDN, бо значна частина вашого сайту, навіть у Laravel‑додатку, статична й рідко змінюється. Саме це ми й розбираємо в курсі.
Курс містить 30 практичних відео з точковими рефакторами, які допоможуть зменшити час відповіді з сотень мс до ~40 мс. Я зробив це для Laravel Shift, використавши його як початковий кейс, і створив відеокурс навколо цього.
Eric Barnes (16:01.179) Саме так. Ми спілкувалися ще до запуску — я вже використовую Cloudflare для Laravel News і попросив тебе подивитися, як його покращити. Тепер можемо це показати й дати план дій.
JMac (16:14.382) Так.
JMac (16:30.542) Цікаво: я спочатку писав кілька статей для Laravel News про те, що бачив, і коли накопичилось більше матеріалу — вирішив зробити курс. Я поділився постом на Reddit, і хтось звернув увагу: вони подивились трафік Laravel News, Userscape, Laracasts — усі на Cloudflare, але не кешують сторінки. Тоді я сказав: добре, зробимо кейс‑стаді, почнемо з Laravel News, подивимось, чи можна підняти кешування, прискорити сайт і знизити витрати.
Eric Barnes (17:08.751) Так, у мене Cloudflare стояв переважно для захисту від DDoS — я його не налаштовував, просто підключив і забув. Саме тому курс корисний: можна дізнатися, що ще пропонує Cloudflare, бо там багато функцій.
JMac (17:22.315) Так.
JMac (17:31.094) В них зараз нечувано багато сервісів — і це стало однією з причин курсу. Я хотів показати не лише кешування сторінок, а й WAF‑правила, правила редиректів, сторінкове кешування, Turnstile, геолокацію, сервіси зображень тощо. І важливо, що все це можна використовувати на безкоштовному плані — що неймовірно.
Eric Barnes (18:14.341) Клас. Я пам’ятаю, я плачу за план — мабуть за Argo чи щось таке, але грубо кажучи я погодився на апсейл без детального розуміння. Просто підписався.
JMac (18:26.572) Розумію.
JMac (18:33.122) Так, їхній платний план швидко дорожчає, але все, що я покриваю у курсі, технічно доступне на безкоштовному плані.
Eric Barnes (18:48.763) Чудово. Гаразд, давай подивимося — я поділюся екраном і покажу головну сторінку Laravel News.
JMac (18:57.677) Так.
JMac (19:01.814) Для більшості сайтів головна або лендинг‑сторінка — далеко найпопулярніша. Можемо глянути аналітику за останні 30 днів, але здогадуюсь, що її трафік у декілька разів вищий за інші сторінки. Якщо у вас був матеріал, що розійшовся вірусно, інша сторінка може тимчасово перегнати, але в загальному головна — №1. І в багатьох випадках вона статична в короткому часовому проміжку: годину‑три вона майже не змінюється, тож виграє від кешування.
Eric Barnes (20:15.717) Саме так. Ця сторінка приблизно в три рази популярніша за будь‑яку іншу щомісяця.
JMac (20:33.9) Тому зручно починати саме з головної, потім — зі сторінок статей. Це дасть найбільший ефект. Якщо хочете, щоб графік кеш‑статусу на Cloudflare підскочив з 10% до 60–90%, працюйте над найпопулярнішими сторінками.
Почнемо з того, як це побудовано: за замовчуванням Laravel не кешується на рівні сторінки — він використовує сесію і робить речі, що ускладнюють кешування. Саме це й побачив Reddit‑користувач: при інспекції трафіку CF cache status показував bypass або dynamic, а не hit, тобто хоча ви й на Cloudflare, кешування сторінок не відбувається.
Eric Barnes (21:37.967) Так, вони мене викрили. Могли б просто написати, але нічого — добре, що звернули увагу.
JMac (21:44.749) Чесно кажучи, це справедливе зауваження — трохи вивело нас на чисту воду.
Eric Barnes (21:53.788) Саме так. На головній ми скрізь використовуємо Livewire, але вона зовсім не динамічна — якщо лишити сторінку відкритою весь день, її вміст не зміниться, хіба зʼявиться нова стаття. Весь кеш реалізований всередині Livewire‑компонентів.
JMac (22:03.553) Зрозуміло.
JMac (22:23.319) Гаразд.
Eric Barnes (22:23.751) І нічого не оновлюється, поки не опублікуємо нову статтю — кеш не інвалідовується автоматично. Отже, стандартний Livewire без реактивності.
JMac (22:31.96) Добре.
Так, це Livewire‑компонент, але на сторінці немає дій, що викликають wire‑запити. Ви кажете, там є кешовані обчислювані властивості, але вони не…
Eric Barnes (22:48.271) Ні.
Eric Barnes (22:54.49) Так.
JMac (23:01.686) Тобто немає реактивності — коли ви очищаєте кеш, сторінка не підписана на події для автоматичного оновлення.
Eric Barnes (23:11.035) Саме так. Покажу код: ось приклад секції головної — це Livewire з кешованою обчислюваною властивістю. Просто виконується запит і передається в Blade‑компоненти. Нічого складного.
JMac (23:20.034) Гаразд.
JMac (23:33.504) Зрозуміло.
JMac (23:38.562) Отже, ви просто кешуєте деякі речі і повертаєте їх. Можливо, в Livewire 4 ситуація з кешуванням покращена, а в Livewire 3 були нюанси: навіть кешовані computed‑властивості все одно рендерились на запит. Варто це перевірити.
Eric Barnes (23:57.211) Ммм.
JMac (24:20.748) У випадках без реактивності варто кешувати, але питання — скільки вигоди дає саме Livewire тут.
Eric Barnes (24:30.873) Я не впевнений, чи є хоч якась користь від Livewire у цьому випадку. Це не те, для чого він призначений. У вигляді шаблону ми просто циклимо й використовуємо невеликі компоненти — і все.
JMac (24:36.865) Так.
JMac (24:44.44) Так.
JMac (24:53.026) Отже, схоже, що деякі частини — це Blade‑компоненти, наприклад секція latest articles, тоді як інші — Livewire. Добре.
Eric Barnes (25:02.906) Так.
Eric Barnes (25:07.075) Точно, good call. Тут немає нічого реактивного.
JMac (25:14.752) Чи є якісь елементи, що змінюються в реальному часі?
Eric Barnes (25:24.834) Ні.
JMac (25:24.834) Загалом Livewire, як і Laravel, припускає використання сесій — саме сесії сильно ускладнюють кешування сторінок, бо вони переважно користувацькі. Я також бачив на головній кнопку входу: чи змінюється навігація при логіні, чи ви просто редиректите в адмінку?
Eric Barnes (25:59.438) Можу показати. У нас є «Your account», але головне — що фронтенд не показує жодних відмінностей для залогіненого користувача: ми не виводимо аватар чи персональні дані. Тому на фронті факт логіну нігде не важливий.
JMac (26:14.861) Розумію.
JMac (26:19.798) Добре.
JMac (26:25.848) Так, ви не показуєте аватар тощо.
Eric Barnes (26:28.731) Ми не маємо коментарів і нічого, що було б прив’язане до аккаунта на фронті.
JMac (26:36.524) Зрозуміло. Fast Laravel про точкові рефактори — не про зміну стека. Ідея така: ваш Laravel‑додаток, але швидший. Якщо ви використовуєте Livewire у цій обмеженій ролі, можна просто замінити його на Blade‑компонент з класом, який кешує ті ж дані.
Eric Barnes (26:54.395) Мм‑хм.
JMac (27:04.426) Бо по суті ви використовуєте computed‑властивість Laravel для збереження чогось в кеші.
Eric Barnes (28:01.486) Так, так — все працює, але питання в тому, чи варто платити за цю надбудову, коли можна досягти кешованої сторінки без виконання PHP‑лозіки при кожному запиті.
JMac (28:09.838) Все правильно. Немає нічого поганого у такому підході, але порівняно з вигодою кешування високонавантаженої сторінки — це може значно покращити UX та зменшити обчислювальні витрати. Навіть якщо дані у кеші, PHP все одно виконується й генерує відповідь; залишається значна робота на сервері.
Eric Barnes (29:04.057) Я покажу аналітику Cloudflare за сайт, щоб було зрозуміло, скільки запитів і як вони кешуються.
JMac (29:06.935) Гаразд.
JMac (29:14.973) За 7 днів у вас 1.5M запитів і доволі пристойний відсоток кешу. Моя підозра — це через велику кількість медіа: багато зображень, і більшість трафіку саме на них. Cloudflare за замовчуванням кешує зображення, JS і CSS — тому ви отримуєте кеш на статичні ресурси без додаткових налаштувань, зазвичай близько години.
Eric Barnes (29:45.651) Так, будь‑яке зображення в public, логотипи тощо, кешуються за замовчуванням.
JMac (29:51.798) Так. Коли я починав із Laravel Shift, у мене відсоток кешу був 7%, бо Shift — це тексто‑важкий сайт без багатьох зображень. Cloudflare за замовчуванням дає кеш для зображень, JS, CSS приблизно на годину.
Eric Barnes (30:02.322) Цікаво.
JMac (30:18.038) На медіа‑важкому сайті, як Laravel News, 20–30% кешу з коробки — нормальний показник. Але я впевнений: якщо ми кешуємо головну сторінку, цей відсоток може підскочити до ~70%, а якщо ще й усі сторінки статей — до 90%+
Eric Barnes (30:30.203) Це буде великий стрибок.
Eric Barnes (30:38.629) Бо саме головна та сторінки статей — ключові. Якщо підсилити їх кешування, отримаємо найбільший ефект.
JMac (30:42.54) Так.
JMac (30:50.284) Пропоную: дай мені доступ до коду — я зроблю коротке відео, продемонструю рефактор Livewire→Blade для не‑реактивного компонента й підключу конфігурацію Fast Laravel. Для цього є безкоштовний shift, який автоматично вставить необхідні налаштування кешування сторінок.
Eric Barnes (31:21.179) Коли це зʼявилось? Я про такий shift не чув.
JMac (31:24.782) Останнім часом я багато роблю — оновлення для Livewire 4.1, Fast Laravel, ще кілька інструментів. Тож я швидко додаю нові шифти. Отже, ок — можу зробити відео рефактора.
Eric Barnes (31:36.059) Клас. До того ж я планую мігрувати сайт на Laravel Cloud наступного тижня — зробимо стрім і переведемо на cloud. Це теж впливатиме на кешування й витрати.
JMac (31:50.808) Добре.
JMac (31:58.629) Класно.
JMac (32:05.91) Цікаво буде порівняти: чи зменшаться витрати на Laravel Cloud, коли більше запитів оброблятиме CDN замість серверів. На cloud ви можете зекономити, якщо ваш план залежить від обчислень і запитів; тому буде корисно зробити порівняння.
Eric Barnes (32:18.48) Ммм.
JMac (32:30.926) Залежить від плану: якщо ви платите фіксовано за ресурс, економія може бути меншою, але на динамічних планах, що рахують CPU або процеси, кешування може знизити витрати.
Eric Barnes (32:49.091) Ми могли б перевести сайт на cloud, потім включити кеш для головної сторінки і порівняти витрати — класна ідея.
JMac (33:03.566) Було б цікаво. Я теж цікавлюсь порівнянням витрат. Це буде цікавий кейс‑стаді.
Eric Barnes (33:28.591) Отримаємо дві користі в одному.
JMac (33:32.342) Чудово. Я зроблю відео, де покажу зміни в коді. Надішли доступ, я зроблю патч, ви задеплоїте, увімкнемо потрібні опції в Cloudflare і подивимося, як зросте відсоток кешу і зменшаться витрати.
Eric Barnes (34:11.547) Супер. Я зараз плачу близько $80 на місяць — раніше пробував дешевший сервер за $20, але одного разу він пропав, і я просто переплатив, щоб не паритись. Було б круто повернутися до дешевшого хостингу.
JMac (34:34.19) Ти зробив як Ian Landsman — просто підняв план і забув. Я все ще на дешевому сервері і пишаюсь цим. Можливо, Fast Laravel допоможе повернутися до «дитячого» сервера.
Eric Barnes (34:43.269) Ха‑ха! Так, гарна ціль.
Eric Barnes (34:47.035) Дякую всім, хто слухав. Перевіряйте Fast Laravel, Laravel Shift — усе, що створює Jason, зазвичай круте. А він ще й король regex‑ів.
JMac (35:09.422) Наступного разу я вдягну свій «regex‑»костюм.
Eric Barnes (35:16.507) Дякую всім, до зустрічі.
JMac (35:16.802) Гуд, давай.
Ви знали, що в одному додатку Laravel можна реалізувати кілька API? У нашій статті ви дізнаєтеся, як за допомогою Scramble легко документувати різні версії API та налаштувати доступ до документації, щоб зробити її публічною або приватною. Читайте далі, щоб дізнатися більше
Використання Vite для створення фронтенд-ресурсів у вашому додатку Laravel може бути захоплюючим, але іноді ви можете стикнутися з певними помилками. У цій статті ми розглянемо чотири поширені помилки, з якими ви можете зіткнутися, а також підкажемо способи їх усунення, щоб ви могли знову зосередитися на розробці вашого додатку
Встановлення Xdebug може бути складним завданням, але в цій статті ми розкриємо, як швидко та просто налаштувати його за допомогою Docker на прикладі Laravel. Дочитайте до кінця, щоб дізнатися, як за кілька хвилин зробити Xdebug вашим надійним помічником у розробці