A render-blokkoló erőforrás olyan CSS- vagy JavaScript-fájl, amelyet a böngészőnek le kell töltenie és fel kell dolgoznia, mielőtt az oldal első képpontját kirajzolná. Amíg ezek a fájlok nem készülnek el, a látogató üres fehér képernyőt néz, akkor is, ha a HTML már régen megérkezett.
Hogyan működik
A böngésző fentről lefelé olvassa a HTML-t. Amikor <link rel="stylesheet"> elemet talál, megáll a rajzolással: a stíluslap nélkül nem tudja, hogyan nézzen ki a tartalom. A <head>-ben lévő klasszikus <script src="..."> ennél is durvább, mert a HTML feldolgozását is felfüggeszti.
A blokkolás ideje két részből áll:
Miért lassít ez többet, mint gondolnád
Egy render-blokkoló fájl gyakran további fájlokat hív be. Ez láncot alkot, és a lánc minden eleme hozzáad egy teljes hálózati körfordulót. Mobilhálózaton egy körfordulás 100-300 ms is lehet. Öt láncszem már másodpercekben mérhető késés.
Emiatt a blokkoló erőforrás egyszerre rontja az első tartalmi megjelenést és az legnagyobb tartalmi elem idejét. A riportokban ezt látjuk a leggyakrabban: a szerver 200 ms alatt válaszol, mégis 4 másodperc a hasznos tartalom.
Mit néz ebből a riport
Az audit megszámolja a <head>-ben található, attribútum nélküli scripteket és a blokkoló stíluslapokat. Ez nyers darabszám, nem szimulált betöltés, ezért a hatása alacsony besorolású. Irányjelző: ha a szám magas, a valódi mérést érdemes elvégezni.
Röviden: minden <head>-ben lévő, attribútum nélküli script és stíluslap addig tartja fehéren a képernyőt, amíg le nem töltődik.
Miért fontos
Sebesség és rangsorolás
A LCP (Largest Contentful Paint) a Core Web Vitals egyik mért mutatója. A jó küszöb 2,5 másodperc. A render-blokkoló erőforrások közvetlenül tolják felfelé ezt az értéket, mert a képernyő kirajzolása csak utánuk kezdődik.
Üzleti következmény
A fehér képernyő a legrosszabb fajta várakozás: a látogató nem lát visszajelzést arról, hogy egyáltalán történik valami. Mobilon, hirdetésből érkező forgalomnál ez mérhető visszalépési arányt okoz. Webshopban ez közvetlenül kevesebb kosár.
AI-szempont
A generatív keresők crawlerei ritkán futtatnak teljes JavaScriptet. Ha a tartalmad csak a blokkoló JS lefutása után kerül a DOM-ba, az AI-crawlerek egy része üres oldalt lát. A blokkoló erőforrás így nemcsak lassít, hanem tartalmat is rejthet a gépek elől.
A lassú oldal ritkán kapja meg az első helyet a találati oldalon azonos tartalmi minőség mellett. A sebesség önmagában nem rangsorol előre, de a lassúság visszafog.
Technikai példa
Rossz és jó <head>
<!-- Rossz: minden blokkol -->
<head>
<link rel="stylesheet" href="/css/reset.css">
<link rel="stylesheet" href="/css/grid.css">
<link rel="stylesheet" href="/css/theme.css">
<script src="/js/jquery.min.js"></script>
<script src="/js/slider.js"></script>
</head>
<!-- Jó: egy bundle, defer scriptek -->
<head>
<style>/* kritikus CSS, kb. 10-14 KB */</style>
<link rel="preload" href="/dist/app.css" as="style"
onload="this.rel='stylesheet'">
<script src="/dist/app.js" defer></script>
<script src="https://www.googletagmanager.com/gtag/js?id=G-XXXX" async></script>
</head>
A preload + onload minta aszinkronná teszi a nem kritikus stíluslapot. A defer megtartja a scriptek sorrendjét, az async csak a független mérőkódon van.
Blokkoló elemek listázása parancssorból
curl -s https://pelda.hu \
| sed -n '/<head/,/<\/head>/p' \
| grep -E '<script src|rel="stylesheet"'
A találatok közül minden olyan <script> sor gond, amelyben nincs async vagy defer. A stíluslapoknál a darabszám számít: háromnál több külön fájl már összevonásért kiált.
Gyakori kérdések
Mi a különbség az async és a defer között?
A defer megvárja a HTML teljes feldolgozását, és a scriptek az eredeti sorrendjükben futnak le. Az async azonnal lefuttatja a scriptet, amint letöltődött, tetszőleges sorrendben. Ha a kódod más scriptre épül, defer kell. Az async független mérőkódokra való.
A CSS-re is rátehetem a defer attribútumot?
Nem, a <link> elem nem ismeri a defer attribútumot. A stíluslapot preload + onload mintával vagy media="print" trükkel teheted nem blokkolóvá. A látható tartalomhoz tartozó kritikus CSS viszont maradjon inline a <head>-ben.
Miért tört el az oldalam a CSS-összevonás után?
A legtöbb optimalizáló bővítmény átrendezi a betöltési sorrendet, és egyes sablonok erre érzékenyek. A megoldás a kivétellista: vedd ki az összevonásból a problémás fájlt. Összevonás után mindig kattints végig a kosáron, az űrlapokon és a szűrőkön.
Mennyit javít ez a valóságban?
Jellemzően 0,5-2 másodpercet mobilon, ha sok különálló fájl volt a <head>-ben. A pontos nyereséget a PageSpeed Insights becsüli meg fájlonként. Ha a becsült megtakarítás 300 ms alatt van, van fontosabb tennivalód.
Elég ehhez egy gyorsítótárazó bővítmény?
Részben. A
cache (gyorsítótár) a második betöltést gyorsítja, de az első látogató ugyanúgy megvárja a blokkoló fájlokat. A render-blokkolás megszüntetése az első betöltésre hat, ezért a kettő egymást kiegészíti, nem helyettesíti.
