Google powiedział: każda sekunda opóźnienia to 7% mniej konwersji.

53% użytkowników opuszcza stronę, jeśli ładuje się dłużej niż 3 sekundy.

Google również penalizuje wolne strony w rankingu — page speed to ranking factor.

Core Web Vitals — metryka Google oceniająca UX — jest zależna od szybkości.

LCP (Largest Contentful Paint) — jak szybko ładuje się główna zawartość. Target: <2.5s.

FID (First Input Delay) — jak szybko strona reaguje na wejście użytkownika. Target: <100ms.

CLS (Cumulative Layout Shift) — czy layout się przesywa podczas ładowania? Target: <0.1.

Mierz w PageSpeed Insights, Lighthouse, WebVitals.js.

Obrazy to zwykle 50-80% wagi strony. Optymizacja obrazów = biggest bang for buck.

Używaj nowoczesnych formatów: WebP zamiast JPEG (30% mniejszy plik).

Kompresuj: TinyPNG, ImageOptim, czy automatycznie na CDN.

Responsive images — wysyłaj różne rozmiary dla różnych ekranów.

Lazy loading — nie ładuj obrazów, które użytkownik nie widzi (loading='lazy').

Minifikacja zmniejsza rozmiar pliku o 20-40% — usu spacje, komentarze, zbędne znaki.

Treeshaking — usuń nieużywany kod JavaScript i CSS (np. z Tailwind).

Code splitting — nie wysyłaj całą aplikację naraz. Załaduj co trzeba, gdy trzeba.

Narzędzia: Webpack, Parcel, Esbuild.

Browser caching — powiedz przeglądarce aby cachowała statyczne assets (images, CSS, JS).

Service Worker — cache assets offline, przyspieszenie na powtórne wizyty.

CDN — serw zawartość z serwera blisko użytkownika (Cloudflare, AWS CloudFront).

Cache busting — zmień filename jak aktualizujesz plik, aby users nie dostał stary.

Critical CSS — inline CSS potrzebny do first paint, zaladuj resztę asynchronicnie.

Async/Defer JavaScript — nie blokuj rendering dla JS.

SSR/Static Generation — pre-render strony na serwerze zamiast w przeglądarce (Next.js).

Web Fonts — optimize fonts, use font-display: swap, limit weights/variants.

Google PageSpeed Insights — daje sugestie co poprawiać.

GTmetrix — detailed waterfall chart, dostęp z różnych lokalizacji.

WebPageTest — advanced metrics, filmik ładowania strony.

Lighthouse — built-in do Chrome DevTools, audyty SEO, accessibility, performance.

[ ] Skompresiuj i zoptymalizuj wszystkie obrazy.

[ ] Załaduj critical CSS inline, restę defer/async.

[ ] Minify CSS, JS, HTML.

[ ] Włącz browser caching na min 1 miesiąc.

[ ] Użyj CDN do serwowania assets.

[ ] Reduce tercích party scripts (analytics, ads, widgets).

[ ] Lazy load non-critical images i components.

[ ] Test z PageSpeed, GTmetrix, WebPageTest.

LCP (Largest Contentful Paint): Jak szybko ładuje się główny content na stronie. Largest element = usually hero image, big heading, czy video. Target: < 2.5 sekundy. Jeśli LCP 5 sekund, Google penalizuje. Użytkownik widzi pusty ekran przez 5 sekund — złe doświadczenie. Fix: optimize images (WebP, lazy load), minify CSS, reduce server latency, inline critical CSS.

INP (Interaction to Next Paint): Jak szybko strona reaguje gdy user klika button, wypełnia form, czy scrolluje. Target: < 200ms (poprzednio FID < 100ms). Jeśli INP 500ms, button click czeka pół sekundy — frustrujące. Fix: reduce JavaScript, defer non-critical scripts, use requestIdleCallback() dla heavy tasks. Profile w DevTools Performance tab.

CLS (Cumulative Layout Shift): Czy layout się przesywa podczas loading? Example: user czyta article, reklama loads above = layout shifts, user traci miejsce. Target: < 0.1 score (0.1 = shift < 10% width/height). Fix: specify image/video dimensions (aspect-ratio CSS), avoid unsized ads, don't insert content above existing content, use CSS containment property.

Measure w PageSpeed Insights (lab + real-world data), Lighthouse, Web Vitals library (w przeglądarce). Google uses real-world data (CrUX) dla ranking. Synthetic monitoring pokaże baseline. Real User Monitoring (RUM) shows actual user experience. Monitor continuous.

Images to 50-80% of page weight. Optimization = biggest impact. Formaty: JPEG (photos), PNG (transparent), WebP (30% mniejszy niż JPEG, browser support 95%), AVIF (35% mniejszy niż WebP, browser support 80%). Use picture element for fallbacks: <picture><source type='image/webp' srcset='img.webp'><source type='image/avif' srcset='img.avif'><img src='img.jpg'></picture>.

Sizing: nie wysyłaj 4000px image do mobile 375px screen. Use responsive images: srcset='img-400.jpg 400w, img-800.jpg 800w' + sizes='(max-width: 600px) 90vw, 800px'. Browser picks best size. Aspect ratio: set width:height ratio w CSS aby prevent layout shift. Use lazy loading='lazy' dla below-fold images.

Compression: lossless (no quality loss) lub lossy (trade quality dla size). JPEG quality 75-85% jest OK dla most photos. Use tools: TinyPNG, ImageOptim, Squoosh (Google), czy automated w CDN (Cloudflare, Bunny). Batch compression scripts: for large sites.

SVG dla icons/logos — scalable, small file size. Inline SVG direct w HTML jeśli część template, external jeśli reused. Use srcset dla different resolutions: img.jpg (1x) i img-2x.jpg (2x) dla Retina displays.

Time to First Byte (TTFB): jak szybko serwer responds na request. Target: < 600ms. Jeśli TTFB 2 sekund, LCP będzie zawsze high. Fix: better hosting, closer servers, database optimization, caching. Shared hosting zwykle ma slow TTFB. VPS/dedicated/cloud (AWS, Vercel, Netlify) = faster.

Hosting dla e-commerce: cheap hosting = slow servers = high bounce rate. Vercel (Next.js), Netlify (static), AWS, DigitalOcean, Linode są dobrymi opcjami. Location matters: jeśli audience Poland, serwer EU region (Frankfurt, Warszawa, Dublin) powinien być faster niż USA.

Database optimization: slow queries = slow response. Add indexes, cache frequently accessed data (Redis), use CDN dla static assets. ORM optimization (N+1 queries?). Use query monitoring tools (New Relic, Datadog) to identify slowdowns.

Caching: browser cache (1 month dla static assets), server-side caching (Redis, Memcached), CDN caching. 304 Not Modified responses (resource hasn't changed since last visit) = super fast. Set Cache-Control headers properly.

JavaScript blocks rendering. <script> tag synchronously loads and executes — parser pauses. Defer: <script src='...' defer></script> loads async, executes po HTML parsed. Async: loads async, executes immediately when ready (order not guaranteed). Defer usually better untuk most scripts. Critical JS inline, rest deferred.

Code splitting: don't send entire app bundle upfront. Lazy load routes, modals, heavy components. Example: /blog loads blog-chunk.js only, nie whole app. Tools: Webpack, Next.js (automatic), Vite. Measure bundle size: webpack-bundle-analyzer, Bundle Phobia (npm packages size).

Third-party scripts (analytics, ads, chat): load asynchronously z low priority. If Google Analytics blocks page, problem. Use data attributes: <script async src='gtag.js'></script>. Avoid render-blocking resources. Use Web Workers dla heavy computations (don't block main thread).

Framework optimization: React: lazy() + Suspense dla components. Vue: async components. Svelte: smaller bundle by default. Choose framework wisely. Framework code is overhead — vanilla JS faster but development time slower. Trade-off optimization.

CDN (Content Delivery Network): requests routed to closest server geographically. Użytkownik w Warszawie requests Poland server (50ms latency) nie USA server (200ms). CDN zmniejsza latency significantly. Popular: Cloudflare (free tier!), AWS CloudFront, Bunny, Fastly. Cost varies — Cloudflare free tier covers basic needs.

Setup: point DNS do CDN. CDN caches static assets (images, CSS, JS, HTML). Set cache headers: Cache-Control: public, max-age=2592000 (30 days). CDN purges cache on demand. Dla dynamic content: CDN can cache HTML (if properly configured). Invalidation: redeployment purges cache automatically (good CDN supports).

Performance impact: typical CDN setup = 30-50% speed improvement. Cloudflare offers DDoS protection, WAF (Web Application Firewall), SSL/TLS encryption built-in. Vercel/Netlify have built-in CDN — automatic dla Next.js/static sites.

Analytics: CDN dashboards show cache hit ratio (% requests served from cache). Higher = better performance + lower origin server load. Goal: > 80% cache hit ratio. Monitor w CDN dashboard (Cloudflare Analytics).

Synthetic monitoring (PageSpeed, Lighthouse): controlled environment, consistent results. útil baseline. Real User Monitoring (RUM): actual user data. Chrome User Experience Report (CrUX): anonymized real-world metrics Google collects. Available in Google Search Console (free!). Breakdown by device (mobile, desktop, tablet), connection (4G, 3G, etc).

Web Vitals library (web-vitals npm): measure actual user metrics. Track w Google Analytics 4 (GA4 integration available). Sentry, Datadog, New Relic provide RUM. Key insight: synthetic je 2.5s LCP, real-world jest 4s (some users have slow connection). Monitor both.

Establish baseline: measure current state. Set goals (e.g., 'LCP < 2.5s for 75% users'). Optimize. Re-measure. Improve gradually. Continuous monitoring = continuous improvement. Don't optimize once; it's ongoing.

Alert on regressions: if new deployment makes performance worse, alert. Setup budgets w Webpack (error jeśli bundle > limit), czy monitoring alerts (Sentry: alert if LCP regression). Prevent performance regressions from going live.

Pytanie: Co ma biggest impact na speed improvement? Odpowiedź: Image optimization (30-40% improvement). Server response time (20-30%). Caching (20-30%). Framework bloat (10-20%). Start z obrazkami — biggest bang for buck.

Pytanie: Czy Page Speed Insights score 'needs improvement' (50-89) to problem? Odpowiedź: Nie necessarily. Score jest relative. Real metrics (LCP, INP, CLS) matter więcej. Site z 'needs improvement' score może mieć good LCP. Focus na metrics, nie score.

Pytanie: Jaki jest typical speed improvement timeline? Odpowiedź: Image optimization: immediate (recompressed images deployed). Caching: immediate (cache headers set). Server upgrade: weeks (time to migrate hosting). Framework refactor: months. Start w quick wins.

Pytanie: Czy page speed wpływa na conversion rate bezpośrednio? Odpowiedź: Tak. Each 100ms delay = 1% conversion drop (approximate). Strona ładująca się 5s zamiast 2s = potential 3-7% revenue loss. Calculate ROI: if 1% improvement = 10,000 PLN extra monthly, optimization is worth investment.

Szybkość to nie nice-to-have — to requirement dla konwersji i SEO.

Największy impact: kompresja obrazów, caching, render optimization.

Continuous monitoring — speed to nie jednorazowy projekt. Monitor Core Web Vitals.

Szybsza strona = więcej konwersji = lepszy ranking = więcej biznesu.