Optimalizace výkonu webu: Checklist pro rok 2026

Google uses Core Web Vitals as a ranking signal. Visitors bounce from slow sites. Every 100ms of additional load time reduces conversion by 1.1%. Performance isn't a nice-to-have — it's a direct revenue lever.

This checklist covers every optimization that matters in 2026, ordered by impact. We use this exact list when auditing and building sites at Empirium. Each item includes what to do, why it matters, and the expected improvement.

The 2026 Performance Baseline

Google's Core Web Vitals thresholds for a "good" rating:

Metric	Good	Needs Improvement	Poor
LCP (Largest Contentful Paint)	≤ 2.5s	2.5 - 4.0s	> 4.0s
INP (Interaction to Next Paint)	≤ 200ms	200 - 500ms	> 500ms
CLS (Cumulative Layout Shift)	≤ 0.1	0.1 - 0.25	> 0.25

INP replaced FID (First Input Delay) in March 2024 and remains the hardest metric to optimize. FID only measured the delay before the browser started processing the first interaction. INP measures the entire duration — from input to the next visual update — for all interactions throughout the page lifecycle. A page that handled the first click fine but lagged on subsequent interactions would pass FID but fail INP.

The target for 2026: all three metrics in the "good" range on mobile. Desktop performance is easier and less impactful — Google primarily uses mobile scores for ranking. Test on a mid-range Android device over a 4G connection, not a MacBook Pro on fiber.

Image Optimization: The Biggest Win

Images typically account for 50-80% of a page's total weight. Optimizing images delivers more performance improvement per hour of effort than any other optimization.

Format selection. AVIF is the best format in 2026 — 50% smaller than JPEG at equivalent quality, with broad browser support (96%+ global). WebP is the fallback for older browsers. JPEG and PNG should only appear as fallback formats in a <picture> element.

<picture>
  <source srcset="/hero.avif" type="image/avif" />
  <source srcset="/hero.webp" type="image/webp" />
  <img src="/hero.jpg" alt="Description" width="1200" height="600" />
</picture>

Responsive images. Don't serve a 2400px image to a 375px mobile screen. Use srcset with multiple sizes and let the browser choose the appropriate resolution. A typical setup includes 640px, 960px, 1280px, and 1920px variants.

Lazy loading. Add loading="lazy" to every image below the fold. This defers downloading until the image enters the viewport. Critical exception: the LCP image (usually the hero image) must NOT be lazy loaded — it should load immediately. Add fetchpriority="high" to the LCP image instead.

Next.js Image component. If you're using Next.js, the <Image> component handles responsive images, format conversion, and lazy loading automatically. It generates optimized images on-demand and caches them. The one gotcha: the first request for each image size triggers a real-time optimization that adds 200-500ms. Warm your cache by hitting key pages after deployment.

Expected impact: Converting from unoptimized JPEG/PNG to responsive AVIF/WebP typically reduces page weight by 60-80% and improves LCP by 1-3 seconds.

JavaScript: Less Is More

JavaScript is the most expensive resource on a web page — not because of download size (though that matters), but because the browser must parse and execute every byte. 200KB of JavaScript is more expensive than 200KB of images because images only need decoding while JS blocks the main thread.

Bundle analysis. Before optimizing, know what you're shipping. Run your build with bundle analysis enabled:

# Next.js
ANALYZE=true next build

# Webpack
npx webpack-bundle-analyzer stats.json

The analyzer shows you exactly which packages consume the most space. Common offenders: moment.js (330KB — replace with date-fns at 12KB), lodash full bundle (72KB — import individual functions), and analytics SDKs that ship their entire platform.

Code splitting. Split your JavaScript by route so visitors only download the code needed for the current page. Next.js does this automatically per page. For heavy components (charts, editors, maps), use dynamic imports:

const Chart = dynamic(() => import('@/components/Chart'), {
  loading: () => <ChartSkeleton />,
  ssr: false
})

Tree shaking. Modern bundlers (Turbopack, esbuild, Rollup) eliminate unused code automatically — but only if your imports are structured correctly. import { debounce } from 'lodash-es' tree-shakes properly. import _ from 'lodash' imports the entire library.

Third-party scripts. Analytics, chat widgets, A/B testing tools, and marketing pixels collectively add 200-500KB of JavaScript to many sites. Audit each one: does it justify its performance cost? Load non-essential scripts with async or defer, and consider loading them after the page is interactive.

Expected impact: Reducing JavaScript payload from 500KB to 150KB typically improves INP by 50-70% and LCP by 0.5-1.5 seconds.

Font Loading Done Right

Web fonts cause two problems: they block text rendering (invisible text until the font loads) and they cause layout shift when the font swap occurs.

font-display: swap shows a fallback system font immediately and swaps to the web font when it loads. This eliminates invisible text but can cause CLS if the web font is a significantly different size than the fallback.

font-display: optional shows the fallback font and only uses the web font if it's already cached. First-time visitors always see the system font. Return visitors see the web font. This eliminates both invisible text and CLS entirely.

Preloading critical fonts. Add preload hints for the fonts used above the fold:

<link rel="preload" href="/fonts/inter-var.woff2" as="font"
      type="font/woff2" crossorigin />

Font subsetting. If you only use Latin characters, subset your font to exclude Cyrillic, Greek, Arabic, and other character sets. Google Fonts does this automatically via the &subset=latin parameter. For self-hosted fonts, use pyftsubset to strip unused glyphs. A full Inter font file is 300KB. Subsetted to Latin, it's 40KB.

The ideal setup: Self-host your fonts (avoid the DNS lookup and connection to Google's CDN), preload the primary weight (regular or 400), use font-display: swap with a size-adjusted fallback, and subset to the character sets you actually use.

Expected impact: Proper font loading eliminates 0.05-0.15 CLS and reduces LCP by 200-500ms on slow connections.

Server and CDN Configuration

The fastest page in the world is slow if the server takes a second to respond.

TTFB target: under 200ms. Time to First Byte is the foundation — everything else stacks on top of it. If your TTFB is 800ms, even a perfectly optimized page will have an LCP of at least 800ms + rendering time. Shared hosting typically delivers 500-2,000ms TTFB. A CDN-served static page: 20-50ms.

Compression: Brotli over gzip. Brotli compresses 15-20% better than gzip for text resources (HTML, CSS, JS). All modern browsers support it. Enable Brotli on your server or CDN. If Brotli isn't available, gzip is still essential — uncompressed HTML is unacceptable in 2026.

HTTP/3 and QUIC. HTTP/3 eliminates head-of-line blocking and reduces connection setup time, especially on mobile networks with packet loss. Cloudflare, Vercel, and most modern CDNs support HTTP/3 automatically. The improvement is most noticeable on poor connections: 10-30% faster page loads on 3G/4G.

Cache headers. Static assets (JS, CSS, images, fonts) should have Cache-Control: public, max-age=31536000, immutable. HTML pages should have short or no-cache headers to ensure visitors get fresh content. The combination means: HTML loads fresh, but every asset it references is served from the browser cache on repeat visits.

Edge caching for dynamic pages. If you're using SSR, cache the HTML at the CDN edge with stale-while-revalidate. The visitor gets the cached version instantly while the edge fetches a fresh version for the next request. This gives near-static performance for dynamic pages.

Expected impact: Moving from shared hosting to edge deployment typically reduces TTFB from 800ms to 50ms, improving LCP by 500-1500ms.

The Checklist (Printable)

High Impact (Do First)

• ☐ Serve images in AVIF/WebP with responsive srcset
• ☐ Add fetchpriority="high" to the LCP image
• ☐ Lazy load all below-fold images
• ☐ Enable Brotli compression (or gzip minimum)
• ☐ Set Cache-Control: immutable on static assets
• ☐ Serve from a CDN (Cloudflare free tier works)
• ☐ Remove unused JavaScript (bundle analysis first)
• ☐ Code-split heavy components with dynamic imports

Medium Impact (Do Second)

• ☐ Preload critical fonts with proper font-display
• ☐ Subset fonts to used character sets
• ☐ Self-host fonts (eliminate third-party DNS lookup)
• ☐ Set explicit width/height on all images and videos
• ☐ Defer non-critical third-party scripts
• ☐ Enable HTTP/3 on your CDN
• ☐ Preconnect to required third-party origins
• ☐ Minimize main-thread work (optimize event handlers)

Lower Impact (Polish)

• ☐ Inline critical CSS for above-fold content
• ☐ Use content-visibility: auto for off-screen sections
• ☐ Prefetch next-page resources on hover
• ☐ Optimize CSS (remove unused rules, minimize specificity)
• ☐ Review and reduce cookie/header payload
• ☐ Enable early hints (103 responses) if CDN supports it
• ☐ Test on real mid-range mobile devices, not just emulators

FAQ

Should I trust Lighthouse scores or real user data? Both, but they measure different things. Lighthouse runs a synthetic test on a simulated device — it's reproducible and good for development. CrUX (Chrome User Experience Report) shows real user data — it captures the actual experience of your visitors across diverse devices and connections. Optimize using Lighthouse during development. Validate with CrUX in production. If they disagree, trust CrUX.

Should I prioritize mobile or desktop performance? Mobile. Google uses mobile-first indexing, and Core Web Vitals scores from mobile CrUX data determine your ranking impact. Mobile devices have slower processors, smaller screens, and often worse connections. A page that scores 95 on desktop might score 60 on mobile — and it's the 60 that matters for SEO.

How do I optimize a WordPress site specifically? Remove page builders if possible. If not, use Asset CleanUp or Perfmatters to dequeue unused CSS/JS per page. Install a caching plugin (WP Super Cache or W3 Total Cache). Use ShortPixel or Imagify for automatic image optimization. Move to managed WordPress hosting. These steps can improve a WordPress Lighthouse score from 30-40 to 60-75. Getting above 80 usually requires migrating off WordPress.

What monitoring tools should I use? Google Search Console shows Core Web Vitals for your indexed pages (free). PageSpeed Insights provides per-URL analysis (free). SpeedCurve or Calibre provide continuous monitoring with alerting ($20-100/month). For most B2B sites, Search Console + monthly PageSpeed Insights checks are sufficient. Set up a monthly calendar reminder to review.

Does performance optimization have diminishing returns? Yes. Going from a 30 to a 70 Lighthouse score is transformative — visitors notice, conversions improve, and rankings change. Going from 90 to 95 is measurable but the business impact is marginal. Going from 95 to 100 is an engineering exercise with near-zero user impact. Focus your effort where it moves the needle: if you're below 80, there's almost certainly a high-impact optimization waiting.