bfcache, Speculation Rules и AI дебъгване – три техники за мигновена навигация в WordPress

Какво общо имат Back бутонът, предвиждането на кликове и AI дебъгерът

Всеки път, когато потребител натисне „Назад“ в браузъра и страницата се презарежда от нулата, губите време, трафик и пари от реклами. bfcache, Speculation Rules API и AI интеграцията в Chrome DevTools атакуват точно тези три проблема – но от различни ъгли. Първата технология пази вече заредени страници в паметта. Втората зарежда бъдещи страници преди потребителят да кликне. Третата съкращава времето за намиране и отстраняване на бъгове, които блокират първите две.

Yahoo! JAPAN News отчитат 9% ръст в мобилните приходи и 13% повече прегледи на сесия само от bfcache. Netzwelt (немски новинарски сайт) вдигат рекламните приходи с 18% и page views с 27% след оптимизация на Core Web Vitals. Числата не са теоретични – идват от публични case studies на Google.

bfcache – мигновено връщане назад без reload

Back-forward cache (bfcache) съхранява пълен snapshot на страницата в паметта на браузъра. При натискане на „Назад“ или „Напред“ страницата се възстановява моментално, без мрежови заявки, без повторен render, без ново изпълнение на JavaScript.

Звучи просто, но доста WordPress сайтове несъзнателно блокират тази функционалност. Три са основните причини: unload event handlers, Cache-Control: no-store хедъри и отворени WebSocket или IndexedDB връзки при навигация. Всяка от тях казва на браузъра „не кеширай тази страница в паметта“, дори когато няма реална причина за това. Monrif (италианска медийна група) подобряват user engagement с 8.9% и LCP с 17.9% след като премахват точно такива блокери.

Решението започва с одит в Chrome DevTools.

Отворете Application > Back-forward cache и натиснете „Test back/forward cache“. Браузърът ще покаже списък с причини, ако страницата не влиза в bfcache. Типични проблеми при WordPress:

// ГРЕШНО - unload блокира bfcache
window.addEventListener('unload', () => {
  sendAnalytics();
});

// ПРАВИЛНО - pagehide не блокира bfcache
window.addEventListener('pagehide', () => {
  sendAnalytics();
});

За Cache-Control: no-store проверете дали темата или плъгин не добавят този хедър за публични страници. В повечето случаи no-cache или must-revalidate вършат същата работа, без да убиват bfcache. Ако ползвате WP Rocket или друг кеширащ плъгин, проверете настройките за HTTP хедъри – някои конфигурации форсират no-store по подразбиране.

WebSocket връзките от чат плъгини или real-time нотификации също блокират bfcache. Затворете ги в pagehide или visibilitychange event-а, за да освободите страницата за кеширане. Списъкът с WordPress чат плъгини на сайта може да помогне при избора на решение, което не пречи на bfcache.

Speculation Rules API – браузърът зарежда следващата страница преди клик

Speculation Rules API позволява на браузъра да предзарежда (prefetch) или дори напълно да рендерира (prerender) страници, към които потребителят вероятно ще навигира. Разликата с класическия „ е в гъвкавостта – правилата се дефинират декларативно с JSON и поддържат условия, филтри и различни нива на агресивност.

Най-безопасната начална конфигурация използва prefetch с moderate eagerness:

{
  "prefetch": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": { "href_matches": "/wp-admin/*" } },
        { "not": { "href_matches": "/cart/*" } },
        { "not": { "href_matches": "/checkout/*" } },
        { "not": { "href_matches": "/my-account/*" } }
      ]
    },
    "eagerness": "moderate"
  }]
}

Изключенията за /cart/, /checkout/ и /my-account/ са критични за WooCommerce сайтове. Предзареждането на тези страници може да наруши сесийната логика, да объркае бисквитките на количката или да покаже грешни данни на потребителя. Тествайте винаги в staging среда преди deploy към production.

За WordPress съществува официален плъгин от WordPress Performance Team – Speculative Loading. Той добавя speculation rules автоматично, без ръчна намеса в кода. Инсталацията е стандартна от Plugins > Add New. След активиране плъгинът вмъква ` блок в ` секцията с prefetch правила за вътрешни линкове.

Ако предпочитате ръчна имплементация, добавете скрипта чрез wp_head hook:

„`php

add_action(‘wp_head’, function () {

if (is_admin()) return;

?>

{

„prefetch“: [{

„where“: {

„and“: [

{ „href_matches“: „/*“ },

{ „not“: { „href_matches“: „/wp-admin/*“ } }

]

},

„eagerness“: „moderate“

}]

}

Preferences > AI assistance.

Как трите техники работят заедно при WordPress

bfcache покрива „Назад“ навигацията. Speculation Rules покрива „Напред“ навигацията (предвидени кликове). AI дебъгването съкращава времето за откриване на проблеми, които блокират първите две.

Един типичен сценарий: потребител отваря архивна страница, кликва на статия, натиска „Назад“. Без bfcache – нов HTTP request, ново зареждане на ресурси, които влияят на Core Web Vitals, ново изпълнение на JavaScript. С bfcache – моментално възстановяване от паметта. С добавени Speculation Rules – следващият клик от архива също зарежда мигновено, защото браузърът вече е дръпнал HTML-а на вероятната цел.

Когато нещо не работи – например страница не влиза в bfcache заради script от трета страна – DevTools MCP агентът може да идентифицира блокера, да предложи алтернативен подход и да генерира patch. Сигурността на сайта не трябва да се компрометира в процеса – проверявайте всяка AI-генерирана промяна ръчно преди да я приложите.

Практическа стъпка за днес

Отворете Chrome DevTools на произволна страница от сайта. Application > Back-forward cache > Test. Ако видите блокери – поправете unload handlers и no-store хедъри. Добавете Speculation Rules с moderate eagerness за вътрешни линкове. Тествайте с Chrome DevTools AI или MCP агент за бързо идентифициране на останалите проблеми.

Резултатът е по-добри URL метрики, по-ниско TTFB за „Назад“ навигация (практически 0ms при bfcache hit) и повече page views на сесия. А повече page views означава повече рекламни импресии.

Често задавани въпроси