Oldalsebesség optimalizálás modern technikákkal

Miért számít minden ezredmásodperc?

A weboldalad sebessége közvetlenül befolyásolja a bevételeidet. A Cloudflare mérései szerint minden 100 ms-os javulás akár 7%-kal növeli a konverziót. A Google adatai alapján, ha egy oldal betöltése 3 másodpercnél tovább tart, a látogatók 53%-a egyszerűen bezárja a böngészőt.

2026-ban a Core Web Vitals közvetlenül befolyásolja a Google rangsorolását, és a mérce tovább szigorodott. Ha a konkurenciád oldala gyorsabb, mint a tiéd, magasabbra kerül a keresési találatokban, te pedig elveszíted az organikus forgalmat.

Core Web Vitals — a három szám, ami számít

• LCP (Largest Contentful Paint) — a legnagyobb vizuális elem megjelenésének ideje. Cél: 2,5 másodperc alatt.
• INP (Interaction to Next Paint) — a felhasználói interakciókra adott válaszidő (2024 márciusától váltotta le a FID-et). Cél: 200 ms alatt.
• CLS (Cumulative Layout Shift) — vizuális stabilitás, mennyire „ugrál” az oldal betöltés közben. Cél: 0,1 alatt.

2026-ban a Google különösen a mobilos teljesítményt súlyozza erősebben a rangsorolásban, és az INP metrika az egyik legfontosabb tényezővé vált. A lassú interakciók közvetlenül rontják a pozíciódat.

Ezeket a PageSpeed Insights és a Google Search Console segítségével mérheted. Két típusú adatot kapsz: labóradatot (Lighthouse szimuláció) és valós felhasználói adatot (CrUX). A rangsoroláshoz a valós felhasználói adatok számítanak.

Képoptimalizálás — a legnagyobb hatás a legkisebb erőfeszítéssel

A képek általában a weboldalak sávszélesség-fogyasztásának 50–70%-áért felelősek. Ha csak egy dolgot csinálsz ebből a cikkből, legyen ez.

Modern képformátumok — WebP és AVIF

A JPEG és PNG helyett 2026-ban már WebP-t és AVIF-et kell használnod:

• WebP: ~30%-kal kisebb fájlméret, mint a JPEG, 97%-os böngészőtámogatás
• AVIF: ~50%-kal kisebb, mint a JPEG, 95%-os böngészőtámogatás

Az ideális megoldás a <picture> elem használata fallback-kel:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Hero kép" width="1200" height="630">
</picture>

Az Astro 5 és a Next.js 16 beépített képoptimalizálóval rendelkeznek, amik automatikusan elvégzik ezt a konverziót build time-ban. Az Astro <Image> komponense például automatikusan WebP-re konvertál és responsive srcset-et generál.

Lazy loading stratégiák

A böngésző natív lazy loadingja egyszerű és hatékony:

<img src="product.webp" alt="Termék" loading="lazy" width="400" height="300">

<img src="hero.webp" alt="Hero" fetchpriority="high" width="1200" height="630">

Azonnali oldalnavigáció — Speculation Rules API

A klasszikus <link rel="prefetch"> mellett 2026-ban a Chromium böngészők (Chrome, Edge, Opera) egy sokkal hatékonyabb eszközt kínálnak: a Speculation Rules API-t. Ez nem csak előtölti a következő oldalt, hanem teljes egészében lerendereli a háttérben.

<script type="speculationrules">
{
  "prerender": [
    { "where": { "href_matches": "/szolgaltatasok/*" } }
  ]
}
</script>

Az eredmény: amikor a felhasználó rákattint egy linkre, az oldal azonnal megjelenik — nulla várakozási idővel. A Google saját keresőmotorja is használja ezt a technológiát a találati oldalon.

A Speculation Rules API-t a nem támogató böngészők egyszerűen figyelmen kívül hagyják, így biztonságosan használható progressive enhancement-ként.

View Transitions API

A View Transitions API 2026-ra stabil lett a Chrome-ban és a Firefox-ban is (Baseline Newly Available). Ezzel animált átmeneteket adhatsz az oldalváltásokhoz, natív app-szerű élményt teremtve, CSS-ből, JavaScript nélkül:

@view-transition {
  navigation: auto;
}

::view-transition-old(root) {
  animation: fade-out 0.2s ease-out;
}

::view-transition-new(root) {
  animation: fade-in 0.2s ease-in;
}

Az Astro beépített View Transitions támogatása (ClientRouter) automatikusan kihasználja ezt az API-t.

Harmadik feles szkriptek kezelése Partytown-nal

Google Analytics, Facebook Pixel, Hotjar, chat widgetek — ezek a harmadik feles szkriptek gyakran a fő szál legnagyobb terhelői. Egy átlagos marketing oldalon a harmadik feles szkriptek akár 800–1200 ms-ot adhatnak a Time to Interactive értékhez.

A Partytown megoldása zseniálisan egyszerű: a harmadik feles szkripteket Web Worker-be helyezi át, így nem blokkolják a fő szálat.

<script type="text/partytown">
  // Google Tag Manager
  (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
  new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
  j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
  'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
  })(window,document,'script','dataLayer','GTM-MKQMQNRM');
</script>

A Partytown a window és document API-kat proxyként teszi elérhetővé a Web Worker-ben, így a szkriptek azt hiszik, hogy a fő szálon futnak, miközben valójában nem blokkolják a renderelést.

Resource hintek — előre jelezni, amit a böngésző nem lát

Preconnect

Ha tudod, hogy egy külső domainről fogsz erőforrásokat tölteni, a preconnect előre felépíti a kapcsolatot (DNS lookup + TCP + TLS):

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Ez akár 100–300 ms-ot spórolhat az első kérésnél.

Prefetch és preload

• Preload: kritikus erőforrások azonnali letöltése (pl. hero kép, fő betűtípus)
• Prefetch: a következő oldal erőforrásainak háttérben történő előtöltése

<!-- Kritikus betűtípus preloadolása -->
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>

<!-- Következő oldal prefetchelése -->
<link rel="prefetch" href="/szolgaltatasok/webfejlesztes">

Ne preloadolj mindent — ha túl sok preload van, az valójában lassítja az oldalt, mert a böngésző nem tudja priorizálni a valóban fontos erőforrásokat.

Betűtípus-optimalizálás

A betűtípusok gyakran láthatatlan teljesítménygyilkosok. Egy rosszul konfigurált betűtípus-betöltés FOIT-ot (Flash of Invisible Text) vagy FOUT-ot (Flash of Unstyled Text) okozhat, ami rontja az LCP-t és a CLS-t is.

1. WOFF2 formátum: a legkisebb fájlméret, szinte teljes böngészőtámogatás
2. font-display: swap: azonnal megmutatja a szöveget fallback betűtípussal, majd cseréli
3. Subsetting: csak a ténylegesen használt karakterek betöltése (pl. latin extended helyett csak latin)
4. Önhosztolás: a Google Fonts-ról való betöltés helyett hostold magad — egy DNS lookup-pal és TCP kapcsolattal kevesebb

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-var.woff2') format('woff2');
  font-weight: 100 900;
  font-display: swap;
  unicode-range: U+0000-00FF, U+0131, U+0150-0151, U+0170-0171;
}

A variable fontok különösen hasznosak: egyetlen fájlból szolgálják ki az összes vastagságot és stílust. Az Inter variable font például ~100 KB egyetlen fájlként, míg 4 külön súlyban betöltve ~200 KB lenne.

CDN és edge computing

A statikus fájlok CDN-ről való kiszolgálása ma már alapvető elvárás, de 2026-ban ennél tovább mehetsz.

Edge computing

A Cloudflare Workers, Vercel Edge Functions és Deno Deploy segítségével a szerver oldali logikát is a felhasználóhoz legközelebbi edge szerveren futtathatod. Ez nem csak statikus fájloknál, hanem dinamikus tartalmaknál is drámai sebességjavulást jelent:

• TTFB (Time to First Byte): tipikusan 50–100 ms edge-ről, szemben a 200–500 ms-mal egy központi szerverről
• Globális elérhetőség: a felhasználó Budapestről, Tokióból vagy São Paulóból is hasonló sebességet tapasztal

Az Astro 5 a Cloudflare adapterrel natívan támogatja az edge-re történő deployolást, ami a statikus generálás előnyeit kombinálja a szerver oldali rugalmassággal.

Critical CSS és kódfelosztás

Critical CSS

A böngésző csak akkor tudja megjeleníteni az oldalt, ha a teljes CSS betöltődött. A critical CSS technikával a hajtás feletti tartalom megjelenítéséhez szükséges stílusokat inline-olod a HTML <head>-be, a többi CSS-t pedig aszinkron töltöd:

<head>
  <style>
    /* Critical CSS - csak a hajtás feletti tartalom stílusai */
    .hero { ... }
    .nav { ... }
  </style>
  <link rel="preload" href="/styles/main.css" as="style"
        onload="this.onload=null;this.rel='stylesheet'">
</head>

Tree shaking és bundle analízis

A modern bundlerek (Vite 7, Rollup, esbuild) automatikusan eltávolítják a nem használt kódot (tree shaking). De ez csak akkor működik hatékonyan, ha:

• ES module importokat használsz (import { x } from 'lib' vs const lib = require('lib'))
• A csomagok tree-shakeable formátumban vannak exportálva
• Nem importálsz teljes könyvtárakat, ha csak egy függvényre van szükséged

Használj bundle analízis eszközöket a fájlméretek vizualizálásához:

# Vite projektben
npx vite-bundle-visualizer

# Webpack projektben
npx webpack-bundle-analyzer

Gyakori meglepetés: a moment.js (~300 KB) helyett használhatsz date-fns-t (~30 KB tree-shake után), vagy a lodash (~70 KB) helyett lodash-es-t (tree-shakeable, csak a használt függvények maradnak).

A három szám, amire optimalizálsz

Összegzés — a prioritási sorrend

Ha nem tudod, hol kezdd, itt egy prioritási lista a tipikus ROI alapján:

1. Képek optimalizálása (WebP/AVIF + lazy loading + fetchpriority) — legnagyobb hatás, legkisebb erőfeszítés
2. Betűtípus-optimalizálás (WOFF2 + swap + subsetting) — gyakran figyelmen kívül hagyott, jelentős javulás
3. Speculation Rules API + View Transitions — néhány sor HTML/CSS, azonnali oldalnavigáció
4. Resource hintek (preconnect, preload) — néhány sor HTML, azonnali eredmény
5. Harmadik feles szkriptek (Partytown vagy defer/async) — különösen marketing oldalaknál drámai hatás
6. CDN + edge — ha még nem használsz CDN-t, ez az első lépés
7. Critical CSS és kódfelosztás — haladó technika, de megéri az erőfeszítést

Ha segítségre van szükséged a weboldalad sebességének optimalizálásában, kérj egy konzultációt. Kapcsolódó: AEO útmutató (Core Web Vitals SEO-szempontból), és a weboldal karbantartás a havi monitoringhoz.