6. Co bývá špatně
- [DB] duplicitní volání DB dotazů
- [DB] použitý špatný (žádný) index
- [DB ]vybírání hodnot pomocí id = 1 místo využití IN (1, 2, 3)
- [DB] řazení na disku (typicky sloupec s dlouhým řetězcem při řazení)
- externí služby (pomalé, padající)
- špatný kód (vložené cykly, in_array, serializace, debug data)
7. Backend
Co měříme?
- CPU (~ PHP), DB, elasticsearch, externí služby
- přihlášený vs. nepřihlášený už.
- roboti vs. lidé vs. naši admini
Jak měříme?
1. agregovaná data si postupně ukládáme do APC a jednou za čas
posíláme do DB
2. u pomalých stránek si ihned uložíme úplně všechno co se na té
stránce dělo do DB
15. Frontend
- Page load time matters!
- Zaměřujeme se na mobil, >50% jsou mobilní sessions a exity do
shopů (záleží na reklamě)
- Sledujeme firstContentfulPaint
- Reportujeme pomocí GA eventu, z GA taháme přes AddOn do Google
Spreadsheet
- Pingdom Page Speed - objevili jsme zvětšení JS o 100kb (requirejs a
ES5)
- Chrome inspector, webpagetest.org (kdyz jsme nasazovali http2
nebo pro AB testování)
16.
17.
18. Frontend - Jak?
- Snažíme se, aby uživatel co nejdříve viděl smysluplný obsah (FCP)
- Co nejmenší HTML a CSS (render blocking)
- Inline CSS na 1. načtení pro non-H2 klienty
- H2 Server Push pro CSS
- Lazyloadujeme, co se dá (pomocí IntersectionObserver API)
- WebP obrázky a WebM videa a brotli kompresi
- Resource Hints:
- preconnect na remarketing
- <link rel="dns-prefetch preconnect" href="https://www.google-analytics.com">
- preload na místech, kde nám to dává smysl
19. Tools
- Google Lighthouse (audit stránky)
- performance
- pristupnost
- https://www.thinkwithgoogle.com/feature/mobile/
- Porovnání rychlosti reálných uživatelů sbírané z Google Chrome
- Dobrý na porovnání vaší služby vs. konkurence