Brand360

Výkon

10 výkonnostných kontrol

P1

Response Time (TTFB)

Čo to je

Time to First Byte (TTFB) meria čas od odoslania HTTP požiadavky po prijatie prvého bajtu odpovede zo servera. Ideálna hodnota je pod 800 ms. TTFB je základná metrika, ktorá ovplyvňuje všetky nasledujúce metriky ako FCP a LCP. Pomalý server znamená, že používateľ čaká ešte pred tým, než sa začne čokoľvek vykresľovať.

Prečo je to dôležité

Pomalý TTFB spomaľuje celú stránku. Ak server odpovedá pomaly, používateľ vidí bielu obrazovku. Google používa rýchlosť načítania ako ranking faktor. Podľa web.dev by mal byť TTFB pod 800 ms pre dobré hodnotenie. Každých 100 ms oneskorenia znižuje konverzie o približne 1 %.

Príklad z praxe

Amazon zistil, že každých 100 ms oneskorenia ich stojí 1 % tržieb. Google má TTFB typicky pod 200 ms vďaka distribuovaným serverom a edge cachingu. Ak váš e-shop odpovedá za 2500 ms, zákazníkom sa stránka načíta až po 4–5 sekundách a väčšina odíde.

Overené zdroje

P2

HTML veľkosť

Čo to je

Kontroluje veľkosť HTML dokumentu stránky. Ideálna veľkosť je pod 100 KB. Veľké HTML dokumenty spomaľujú parsing a zvyšujú čas do prvého vykreslenia. Nadmerne veľké HTML často vznikajú kvôli inline štýlom, inline skriptom alebo duplikovanému obsahu.

Prečo je to dôležité

Veľké HTML spomaľuje načítanie, pretože prehliadač musí celý dokument stiahnuť a sparsovať pred tým, než začne renderovať. Na mobilných sieťach je to ešte výraznejšie. Menší HTML tiež zníži spotrebu dát používateľov a zrýchli DOM parsing.

Príklad z praxe

Google homepage má HTML pod 50 KB, čo umožňuje bleskurýchle načítanie. Shopify optimalizuje HTML svojich šablón na minimum. Ak váš blog generuje 500 KB HTML kvôli inline CSS a zbytočným atribútom, načítanie na 3G sieti trvá aj 5 sekúnd.

Overené zdroje

P3

Externé zdroje

Čo to je

Počíta počet externých skriptov a CSS súborov načítaných na stránke. Ideálny počet je menej ako 15. Každý externý zdroj vyžaduje DNS lookup, TCP spojenie a HTTP požiadavku, čo pridáva latenciu. Render-blocking skripty a štýly sú obzvlášť problematické.

Prečo je to dôležité

Každý externý zdroj pridáva sieťovú latenciu. CSS a JavaScript sú render-blocking — prehliadač nemôže zobraziť obsah, kým ich všetky nenačíta. Príliš veľa externých zdrojov dramaticky spomaľuje First Contentful Paint a zvyšuje dobu, kedy používateľ vidí prázdnu stránku.

Príklad z praxe

Typický WordPress web načítava 15–30 externých zdrojov kvôli pluginom. Google homepage používa len 3–4 externé zdroje. Ak váš web načítava 25 externých skriptov z rôznych CDN, každý pridáva 50–200 ms latencie a celkové oneskorenie môže byť aj 2 sekundy.

Overené zdroje

P4

Inline CSS

Čo to je

Meria veľkosť inline CSS štýlov priamo v HTML dokumente oproti externým štýlom. Malé množstvo kritického inline CSS (do 15 KB) je prospešné pre rýchle vykreslenie above-the-fold obsahu. Príliš veľa inline CSS však zvyšuje veľkosť HTML a znemožňuje cachovanie štýlov.

Prečo je to dôležité

Inline CSS sa nedá cachovať — stiahne sa pri každom načítaní stránky. Veľké bloky inline CSS zväčšujú HTML dokument a spomaľujú parsing. Správny prístup je vložiť inline len kritické CSS pre obsah nad záhybom a zvyšok načítať asynchrónne z externého súboru.

Príklad z praxe

Google vkladá kritické CSS pre above-the-fold obsah (cca 10 KB) a zvyšok načítava asynchrónne. Ak váš web má 200 KB inline CSS v každom HTML dokumente, používateľ stiahne zbytočné dáta pri každom requeste a prehliadač nemôže CSS cachovať medzi stránkami.

Overené zdroje

P5

Inline JS

Čo to je

Meria veľkosť inline JavaScript kódu priamo v HTML dokumente oproti externým skriptom. Malé inline skripty (do 5 KB) sú akceptovateľné pre kritickú funkcionalitu. Veľké bloky inline JS zväčšujú HTML, spomaľujú parsing a znemožňujú cachovanie a optimalizáciu skriptov.

Prečo je to dôležité

Inline JavaScript blokuje HTML parser a nemôže byť cachovaný prehliadačom. Veľké inline skripty spomaľujú Time to Interactive a zvyšujú veľkosť každého HTML dokumentu. Externé skripty sa dajú cachovať, minifikovať a načítavať asynchrónne pomocou atribútov async alebo defer.

Príklad z praxe

Shopify presunul väčšinu inline JS do externých súborov s async/defer atribútmi, čo zlepšilo TTI o 30 %. Ak váš e-shop má 150 KB inline JavaScriptu (trackery, analytické skripty), každá stránka bude o 150 KB väčšia a neoptimalizovateľná.

Overené zdroje

P6

Optimalizácia obrázkov

Čo to je

Kontroluje, či obrázky používajú moderné formáty (WebP, AVIF), lazy loading (loading='lazy') a responzívne veľkosti cez srcset atribút. Lazy loading odkladá načítanie obrázkov mimo viewport, srcset umožňuje prehliadaču vybrať správnu veľkosť obrázka pre dané zariadenie.

Prečo je to dôležité

Obrázky sú typicky najväčšia časť stránky (50–70 % dát). Bez lazy loadingu sa načítavajú všetky obrázky naraz, aj tie ktoré používateľ nikdy neuvidí. Bez srcset mobilné zariadenia stiahnu desktopové obrázky zbytočne veľké. Moderné formáty ako WebP sú o 25–35 % menšie ako JPEG.

Príklad z praxe

Medium používa lazy loading a srcset pre všetky obrázky v článkoch — načítava len obrázky viditeľné vo viewport a pre mobil posiela menšie verzie. Ak váš blog má 20 obrázkov po 500 KB bez lazy loadingu, používateľ stiahne 10 MB dát hneď pri načítaní stránky.

Overené zdroje

P7

Celková váha stránky

Čo to je

Meria celkovú veľkosť všetkých zdrojov stránky v KB (HTML, CSS, JS, obrázky, fonty). Ideálna hodnota je pod 2 000 KB. Podľa HTTP Archive je medián okolo 1 700–1 900 KB. Veľká stránka spomaľuje načítanie, zvlášť na mobilných sieťach a slabších zariadeniach.

Prečo je to dôležité

Celková veľkosť stránky priamo ovplyvňuje čas načítania. Na 3G sieti trvá stiahnutie 5 MB stránky viac ako 15 sekúnd. Google odporúča držať kritický obsah pod 170 KB komprimovaných dát pre dosiahnutie TTI pod 10 sekúnd na mobilných zariadeniach.

Príklad z praxe

Google.com má celkovú veľkosť pod 500 KB. Priemerný e-commerce web má 3–5 MB kvôli veľkým obrázkom produktov. Amazon optimalizuje obrázky a používa lazy loading, aby celková veľkosť neprekročila 2 MB pri prvom načítaní.

Overené zdroje

P8

Počet requestov

Čo to je

Počíta celkový počet HTTP požiadaviek potrebných na načítanie stránky. Ideálny počet je menej ako 50. Každý request pridáva latenciu kvôli DNS, TCP a TLS handshake. Aj s HTTP/2 multiplexingom má vysoký počet requestov negatívny dopad na výkon.

Prečo je to dôležité

Vysoký počet requestov spomaľuje načítanie stránky, zvlášť na vysokolatentných mobilných sieťach. Render-blocking požiadavky (CSS, synchronný JS) musia byť dokončené pred zobrazením obsahu. Cachovanie, bundlovanie a sprite techniky znižujú počet requestov.

Príklad z praxe

Typický WordPress web s 15 pluginmi generuje 80–120 HTTP requestov. Google.com potrebuje menej ako 20 requestov. Ak váš web vyžaduje 95 requestov (30 skriptov, 25 obrázkov, 15 CSS, 25 ďalších), na mobilnej sieti to môže trvať aj 8 sekúnd.

Overené zdroje

P9

CSS Coverage

Čo to je

Meria percento nepoužitého CSS kódu na stránke. Ideálna hodnota je menej ako 50 % nepoužitého CSS. Nepoužité CSS štýly zbytočne zväčšujú súbory, spomaľujú stiahnutie a blokujú renderovanie stránky, pretože prehliadač musí spracovať všetky CSS pravidlá.

Prečo je to dôležité

CSS je render-blocking zdroj — prehliadač musí spracovať všetky CSS pravidlá pred vykreslením stránky. Ak 70 % CSS nie je použitých, prehliadač zbytočne strácal čas ich parsovaním. Odstránenie nepoužitého CSS zlepší FCP a LCP a zmenší veľkosť stránky.

Príklad z praxe

Bootstrap framework načítava často 90 % nepoužitého CSS ak sa použije len pár komponentov. Tailwind CSS s purge funkciou odstráni nepoužité triedy a zmenší CSS z 3 MB na 10 KB. Ak váš web používa 500 KB CSS ale reálne potrebuje len 50 KB, spomaľujete renderovanie zbytočne.

Overené zdroje

P10

JS Coverage

Čo to je

Meria percento nepoužitého JavaScript kódu na stránke. Ideálna hodnota je menej ako 50 % nepoužitého JS. Nepoužitý JavaScript zbytočne zväčšuje súbory, spomaľuje stiahnutie, parsovanie a kompiláciu, čo priamo ovplyvňuje Time to Interactive.

Prečo je to dôležité

JavaScript je najdrahší zdroj na spracovanie — musí sa stiahnuť, sparsovať, skompilovať a vykonať. Nepoužitý JS plytvá všetkými týmito zdrojmi. Lighthouse označí každý JS súbor s viac ako 20 KiB nepoužitého kódu. Tree shaking a code splitting sú kľúčové optimalizácie.

Príklad z praxe

Webpack bundle analyzer často odhalí, že 60 % JavaScript kódu nie je použitých. Next.js používa automatický code splitting — každá stránka načíta len JS ktorý potrebuje. Ak váš web načítava 2 MB JavaScriptu ale používa len 400 KB, mobilné zariadenia strávia sekundy parsovaním zbytočného kódu.

Overené zdroje

Vyskúšajte audit vášho webu

Otestujte váš web proti všetkým kontrolám a zistite, čo zlepšiť.

Spustiť analýzu