09.08.2023 11:45 E-mail nemusí být zlo. Elektronickou poštu nemusíte mít plnou reklamních newsletterů, ani ji nemusíte mít plnou nevyřízených a nerelevantních zpráv. Nemusíte ji mít plnou vůbec. Nemusíte pořád na něco nebo na někoho zapomínat. Nemusíte se cítit blbě pokaždé, když si vzpomenete na svůj e-mail. Řešení znám dvě. První je se tvářit, že e-mail neexistuje. Druhé je Inbox Zero, metodika pro systematické zpracovávání e-mailů. Tohle chceme všichni. Někdy stačí jen vypnout odznáček z ikony aplikace. Někdy je potřeba víc, metodiku. Výhody e-pošty E-mail u některých profesionálů získal tak špatné renomé, že utíkají k nástrojům pro komunikaci v reálném čase nebo úplně zbytečně kvůli každé blbině telefonují. To ovšem dříve či později vede k zapomínání, nedostatečné informovanosti zúčastněných a komunikačnímu chaosu. Elektronická pošta má své výhody. Příjemce by neměl očekávat okamžitou reakci, takže máte čas na rozmyšlenou. Konverzace v něm poskytují prohledávatelný a trvalý záznam. E-mail není tak předurčený k vyrušování jako IM a díky tomu více podporuje režim hluboké práce. E-mail mají všichni, i ti, kteří jej nepoužívají, takže jde o jedinou skutečně univerzální platformu. E-mail prostě jiné způsoby komunikace skvěle doplňuje. Skoro bych řekl, je to nutný základní kámen online komunikace. Má špatnou pověst, ale možná jen proto, že jej lidé nepoužívají správně. Pro mě se návod na správné použití e-mailu jmenuje Inbox Zero. Překvapilo mě, jak málo je tato metodika známá a používaná. Američtí vědci prokázali, že 83,8 % lidí ocení článek o Inbox Zero. I proto vznikl tenhle text. Pojďme na to. Co je Inbox Zero? Inbox Zero je metodika, jejímž cílem je efektivní zpracování a organizace příchozích e-mailů. Cílem je mít schránku příchozí pošty pravidelně prázdnou nebo blízkou tomu stavu. Inbox Zero vymyslel a v nultých letech propagoval Merlin Mann, expert na produktivitu. V praxi Inbox Zero vypadá dle definice asi takto: Alespoň jednou denně věnujete čas své elektronické poštovní schránce. Procházíte zprávy a akce se řídí metodikou čtyř D . Každou zprávu následně buď archivujete nebo smažete. Profit! Inbox je čistý. Hlavním cílem Inbox Zero prostě je snížit stres spojený s elektronickou poštou, zvýšit produktivitu a udržet si pocit kontroly nad e-mailovou komunikací. Reklamní slogan říká, že cílem je udržovat vaši mysl a inbox čistými. To sedí. Fakt. V následujícím textu toto rozvedu a doplním svými zkušenostmi. Já osobně Inbox Zero používám kolem deseti let. Odhaduji, že jsem na metodiku přešel s příchodem Google Inbox, dnes už neexistující inovativní alternativy Gmailu, která šla mimo jiné naproti nadšencům do Inbox Zero. Dnes jsem zůstal u Gmailu, ale více či méně to bude fungovat s jakýmkoliv e-mailovým klientem. Co mi Inbox Zero přináší? Méně stresu z přeplněného inboxu, méně obav z nestíhání, méně zapomínání, efektivnější dohledávání informací. Snadnější a systematičtější organizaci práce. Jak pracuji a jaké nástroje pro komunikaci používám? Než se pustíme do konkrétních praktických tipů, cítím potřebu uvést svou verzi metodiky Inbox Zero do širšího kontextu. Jak pracuji? Jsem sice freelancer, odborně se zaměřuji na poradenství k rychlosti webu, ale hlavní část mé práce je dnes více méně management. Se třemi kolegy děláme konzultace pod značkou PageSpeed.cz, kde máme zhruba padesát klientů. V rámci dalšího týmu pomáhám vyvíjet tester rychlosti. Spolupracuji také na managementu komunity Frontendisti.cz a občas tvořím články nebo knížky v rámci své značky Vzhůru dolů. Denně mi přijde kolem stovky e-mailů a nějaké ty zprávy na sociální sítě, do IM nástrojů… Je toho vcelku docela dost a bez metodiky bych byl v čudu. Komunikačních kanálů používám mrak, asi jako všichni. Zde nastíním svůj vztah k nim v kontextu s mým pojetím metodiky Inbox Zero. E-mail Elektronická pošta je pro mě hlavní komunikační centrála. Všechny notifikace, které tak šly nastavit, hlavně z Basecampu, nástroje pro řízení projektu, mi chodí do e-mailu. Sem ale nechodím často, jen párkrát denně. Notifikace mám vypnuté. Používám Gmail. IM Slack používáme v týmu pro pracovní komunikaci v reálném čase. IM je zásadní pro případné záseky a problémy, které nepočkají. Máme zde ale i kanály jen tak pro tlachání s nižší prioritou. Notifikace ze Slacku mám zapnuté jen odpoledne, když se nevěnuji hluboké práci, ale občas se tam podívám i dopoledne. Totéž platí pro Whatsapp, Messenger, iMessages… v rámci soukromé komunikace. Pokud to nehoří, neodpovídám hned. S výjimkou ženy a dětí, samozřejmě. Telefon Telefon používám velmi málo, ale občas se hodí okolí dovysvětlit složitější nebo spíše středně složité témata. Někteří klienti jsou hodně telefonní, snažím se to respektovat. Hořáky a průšvihy naštěstí v práci nemívám, takže telefon obvykle můžu vzít bez strachu z velkého vyrušení a bez stresu. Po dlouhodobější komunikace e-mailem může mít člověk pocit, kterému říkám „emoční odpojení“, takže někdy je dobrý se vidět nebo si alespoň zavolat. Telefon je pro mě, kromě osobního setkání, nejlidštější forma komunikace. Ale raději se s lidmi setkávám, než telefonuji. Online schůzky Online meetingy v mém oboru prakticky úplně vytlačily osobní schůzky, ale v zásadě mě to vyhovuje. Pravidelně se slýcháváme s většinou klientů. Jednou za čas preferuji osobní setkání. Ale je stále těžší osobní pracovní setkávání prosazovat, nemyslíte? Tolik k širšímu kontextu mého způsobu elektronické komunikace. A teď už k e-mailu a metodice Inbox Zero. Než začneme, musíme splnit určité předpoklady. Předpoklad první: vyhrazený a omezený čas, třeba po obědě Bude vás to stát čas. Bez toho to nepůjde. Se s tim smiřte. E-maily v Inboxu čekají a nemají nožičky. Neodejdou a nevyřeší se samy, aniž byste jim věnovali čas. Ten si musíte vyhradit. Některé metodiky doporučují věnovat se e-mailu co nejrychleji nebo třeba jednou za hodinu, ale mě osobně by to zabilo. E-mailu se věnuji jen párkrát denně. Funguje to asi takto: Dopoledne do inboxu vůbec nekoukám. Jsem zahloubán v hluboké práci, sorry. Po obědě věnuji e-mailu půl hodiny až tři čtvrtě. To je můj hlavní čas na Inbox zero. Odpoledne dělám už více manažerskou práci, do e-mailu občas kouknu, občas odpovím, aby na mě něco nestálo, ale většinu z nich stejně odložím na další den. Tu půl hodinu až tři čtvrtě hodinu po obědě mám každý den v časovém plánu a počítám s ní. Není možné ji vytvořit z ničeho, pokud bych měl den nabitý jinými úkoly. Zpracování e-mailů si normálně počítám v Toggl jako práci: Komunikaci v rámci projektů PageSpeed.cz měřím jako management týmu. Složitější, poradenské e-maily klientům trackuji jako placenou práci pro ně. Pro ostatní e-mailovou komunikaci mám štítek „Komunikace“ a snažím se, aby nepřesáhla tak těch 30 minut denně. Sem patří neplacená komunikace s klienty, různé newslettery, komunikace kolem Vzhůru dolů, občasný soukromý e-mail, a tak dále. Všimněte si, že se e-mailům věnuji po obědě. Ano, to jsem většinou nejunavenější z celého dne a e-maily zároveň nepotřebují tolik mých moznových kapacit. A co další předpoklady? Chce to trochu pošolíchat nastavení e-mailu Pojďme na další krok, přenastavit si všechno tak, aby to bylo co nejméně otravné a aby to bylo na jednom místě. Žádné notifikace Jsem fakt velký odpůrce notifikací přicházejících v reálném čase a otročině při jejich vyřizování. Chodí mi vlastně jen telefonická smsková upozornění a občas něco důležitého z IM, jako třeba rodina. E-mail nemá žádnou výjimku. Čistá mysl s tímhle v mobilu? Kde se to zařízení safra vypíná?! Vypl jsem si i odznáčky hlásící počet příchozích e-mailů na ikonkách všech aplikací. Díky Inbox Zero ale i tak většinu e-mailů vyřídím do 24 hodin. Všechno v jednom Všechny svoje e-mailové schránky, i ty historické, mám přesměrované do jediné, té nejaktuálnější, kterou používám. V Gmailu jsem si zrušil záložky jako Promotions, Social… Pokud mi to má chodit, ať to chodí rovnou do inboxu. Včetně newsletterů, kterých odebírám něco mezi pěti až deseti, a pořád mi to připadá hodně. Promo neodebírám vůbec a e-maily s notifikacemi ze sociálních sítí taky ne. Co se děje na sociálních sítích, ať tam zůstane. Občas se tam podívám, to ne, že ne. Vlastně nezdravě často, ehm. Téměř také v Gmailu nepoužívám štítky a kategorie. Jedinou výjimkou jsou automatické zprávy z různých nástrojů, jako je Google Search Console, protože ty nejde přesměrovat do Slacku nebo na jiné rozumné místo, kam nám chodí pracovní notifikace. Rozumná délka e-mailu Kdysi jsem psal dlouhé zprávy. Všímám si, že to je u vývojářů časté. Dneska mám vůči tomu odpor a tak když mi napíšete dlouhý e-mail, asi budete chvilku čekat na odpověď nebo vám prostě zavolám. Snažím se to držet i na své straně. Líbí se mi tedy metodiky nebo spíše popis ideálního stavu znění e-mailu jako Five.sentenc.es. Zkuste vše nacpat do pěti vět. Vždy se to nepovede, ale je to super výuka stručnosti. Pro méně zkušené je dobré si zkusit osvojit metodu pěti W. Jak tedy postupovat každý den při procházení příchozí pošty? Různí lidé to dělají jinak a nechci nikomu nic vnucovat, takže mohu jen nabídnout svůj vlastní postup. Pro inspiraci. Krok 1: prioritizace Projdu očima e-maily a začnu od těch nejjednodušších. Proto, aby to zkraje odsejpalo. Co si totiž budeme povídat – vyřizování e-mailů obvykle není nejúžasnější část dne. Obecně nejprve procházím interní zprávy týmu, což znamená vyřídit všechny e-mailové notifikace z Basecampu. To eviduji jako samostatní časový úsek. Druhé na řadě jsou ostatní e-maily, které se dají vyřídit rychle, tak do minuty jeden. To eviduji jako samostatnou položku „Komunikace“. Přitom často ještě vyřídím různé notifikace ze sociálních sítí. Třetí jsou konkrétní složitější e-maily, které můžu trackovat jako samostatný čas, obvykle pro konkrétního klienta. Jde většinou o rychlou radu, připomenutí priorit nebo rychlé vytěžení nějakých dat a dodání ilustrace. Čtvrté na řadě jsou e-maily, u kterých vím, že se na ně nedostane. Většinou mají nízkou prioritu. Ty odkládám na další den. Je jich každý den tak desetina. Krok 2: Akce S každým e-mailem je potřeba něco udělat a smazat je všechny nemůžeme, že ano… Zjednodušený a pořád složitý graf. A přitom taková blbost, že? Původní metodika Inbox Zero počítá s těmito akcemi od „D“, trošku jsem to doplnil o své zkušenosti: Smazat Pokud e-mail není relevantní nebo nevyžaduje akci, prostě ho smažte. Asi přišel jen pro info nebo ani to ne. U mě se to ještě rozdvojuje na dvě různé akce: Smazat – e-maily, které nebudu potřebovat archivovat. Neobsahují důležitou informaci nebo jde jen o duplikát zprávy z Basecampu nebo jiného nástroje, kde bude zpráva dohledatelná. I tak se ale hodí nějak reagovat, aby lidé na druhém konci drátu věděli, že jste zprávu viděli. K tomu jsou dobře hodí emoji v Basecampu. E-mail toto zatím nenabízí. Archivovat – zprávy nebo vlákna zpráv, které obsahují důležité informace. Většinu zpráv archivuji, ale nemažu. Díky tomu vím, jaké blbosti jem komu napsal před osmi nebo desíti lety. To chcete. Delegovat Pokud e-mail vyžaduje akci, ale vy nejste správná osoba, která by se tím měla zabývat, delegujte jej na vhodnou osobu nebo tým. U mě to znamená přidat nebo aktualizovat adekvátní úkol u kolegů. Obvykle ale moc nedeleguji, protože máme docela dobře rozdělené kompetence a všichni víme, co máme dělat. Vyřídit Pokud e-mail vyžaduje rychlou a jednoduchou akci, kterou můžete dokončit během několika minut, vyřídím jej hned. Odpovězte, proveďte požadovanou akci nebo tak něco. Tady budete mít pocit, že jste něco udělali. Je to složitější než na minutu či dvě? Měřím si čas pro klienta. Odsunout Pro e-maily, které vyžadují více času nebo úsilí na zpracování, ale nemůžete se jimi zabývat okamžitě, odstavte je na později. Použijte svůj úkolníček nebo funkci odkladu ve vašem e-mailovém klientovi. Zmizí vám z očí, alespoň pro teď. Odmítnout E-maily, které jsou spam nebo nerelevantní prostě označte jako spam nebo se odhlaste. Tohle je obzvlášť zábavné. Krok 3: Profit! Máte hotovo. Každý den pak budete odměňováni pohledem na prázdný inbox: Tady je klid. Je to fajn. Nemusí to být hned dokonalé. U mě to taky není dokonalé, ani po těch letech. Ale pomáhá to. Zkuste Inbox Zero. Budu rád, když mi do komentářů napíšete své vlastní zkušenosti. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
09.08.2023 11:45 Ve 45. epizodě podcastu jsme s Liborem, který momentálně působí jako Head of Front-End Development v CDN77, probrali aktuální směřování javascriptových frameworků. Naše povídání se netočí jen kolem SSR, ale také dalších známých problémů frameworků, jako je hydratace. Jak si s tím pokouší poradit moderní frameworky typu SvelteKit nebo Qwik? Podcast Host: Libor Vaněk Head of Front-End Development v CDN77, kde poskytují infrastrukturu pro globální internet. Fanoušek World Wide Web platformy a rozumného přístupu k web developmentu. Má rád všechny JS frameworky, ale ještě radši je podrobuje kritickému pohledu. Kdysi dělal meetupy Vue.js, dneska migruje většinu věcí z Nextu na SvelteKit. Ve volném čase dělá pro bono projekty, jako např. web a newsletter pro novináře Davida Klimeše a konzultuje architekturu a výkon webových aplikací. LinkedIn – Twitter O čem se bavíme? Robinův tip: 20 let od CSS Zen Garden Martinův tip: 6 CSS snippets every front-end developer should know in 2023 Představení Libora Historický kontext: proč dříve převažoval server, architektura MPA Svět webových aplikací, nikoliv webů, a SPA architektura Nevýhoda SPA: totální závislost na JS Nová generace „client-side“ vývojářů Pojďme tam přidat server Izomorfní aplikace vs. SSR Další problém: hydratace na klientovi Diskuze o budoucnosti, reflexe v komunitě Reactu Odkazujeme na podcast o trendech pro ‘21 a Hotwire – vracíme se zpět? Tipy na zdroje: Alex Russell, Rich Harris, Ryan Carniato, Mishko Hevery Děkujeme za spolupráci: Honza Michálek . Odebírejte podcast ze Vzhůru dolů Spotify – iTunes – Google Podcasty – TuneIn – Anchor – RSS podcastů. Nápad? Chyba? Připomínka? Pochvala? Pište nám na e-mail podcast@vzhurudolu.cz nebo do komentářů. Naslyšenou příště!
05.08.2023 09:00 V tomto rozhovoru s Petrou Nulíčkovou , se ponoříme do světa HR a LinkedInu ve vztahu k vývojářkám a vývojářům. Víme, že mnoho z nás má z oblasti hiringu rozporuplné pocity, proto jsme se rozhodli rozptýlit nedorozumění a nabídnout tipy a triky pro hledání lepší práce. Petra nám odhaluje svůj pohled na to, jaké to je být na „druhé straně“ náborového procesu, a jak se trh s vývojáři proměnil v důsledku pandemie covidu. Společně se pouštíme do diskuze o tom, jak účinně hledat dobrou práci a na co si dát pozor, když ptáčka lapají. Zvláštní pozornost věnujeme náboru talentovaných IT juniorů, kterým Petra poskytuje rady pro úspěšné hledání práce. Zaměřujeme se také na motivační dopisy – a říkáme, že dneska už je díky ChatGPT umí psát každý. Dále se bavíme o vývojářích a LinkedInu - jaký profil by měli mít a jak ho efektivně využívat, aby dosáhli svých profesních cílů. Petra přichází s tajnými tipy, jak se elegantně vyhnout nežádoucím pracovním nabídkám a jak si správně vytvořit profil na LinkedInu, který zaujme. Host: Petra Nulíčková Petra Nulíčková je současně šéfkou HR v investiční skupině Pale Fire Capital a náborářkou v Aukro.cz. Kromě toho působí v komunitě „Holky z marketingu“ a má za sebou bohaté zkušenosti z Alzy. Své rozsáhlé znalosti a rady sdílí na svém osobním webu a aktivně komunikuje s komunitou na svých sociálních sítích. Navíc je spoluautorkou projektu propousteni.cz, který se zabývá propouštěním ve firmách. petranulickova.cz – LinkedIn – Instagram O čem se bavíme? Robin a Martin zvou na WebExpo 2023 Jaké to je být na „té druhé straně“? Změnil se trh po covidu, když se v Silicon Valley hodně vyhazuje? Jak hledat práci a na co si dát pozor, když ptáčka lapají? Hiring juniorů Motivační dopis a jak na něj Vývojáři a LinkedIn, být tam a jaký mít profil? Jak odmítat nabídky? Jak si vyplnit profil na LinkedInu? Je karma zdarma? Video: Petřina přednáška „Když ptáčka lapají“ Petřina vyšla na jejím webu také v podobě článku. Ukázka: nabírání juniorních lidí v IT Děkujeme za spolupráci: Honza Michálek . Odebírejte podcast ze Vzhůru dolů Spotify – iTunes – Google Podcasty – TuneIn – Anchor – RSS podcastů. Líbil se vám tento díl? Prosíme vás o zhodnocení podcastu na vaší oblíbené platformě. Nápad? Chyba? Připomínka? Pochvala? Pište nám na e-mail podcast@vzhurudolu.cz nebo do komentářů.
02.08.2023 14:30 „Page Experience“ bylo pojmové zarámování snah Googlu o zhodnocení uživatelské zkušenosti se stránkou. Dnes, tedy v květnu 2023, se už tento pojem přestává používat. Šlo v podstatě o dvě věci: Stejnojmenný update algoritmu Google, který se týkal rychlosti načítání stránek atd. Sekci v Google Search Console, kde se dalo hodnocení uživatelské zkušenosti se stránkami sledovat. První i druhé je dnes už historií. Důraz na rychlost webů platí, jen se tomu dnes už říká jinak. Google začal více tlačit pojem Core Web Vitals jakožto základních metrik rychlosti. Updaty algoritmu Google v letech 2021-2022 Google od června 2021 postupně nasazoval aktualizaci algoritmu zvanou Page Experience. Kluci a holky v největším vyhledávači ji navrhli tak, aby zvýrazňovala stránky, které nabízejí výborný uživatelský prožitek. Během roku 2021 se to začalo projevovat v mobilním vyhledávání a od února 2022 naplánoval Google nasazení také nasazení do hodnocení desktopových webů. Page Experience v Google Search Console V Google Search Console šlo zobrazovat počet stránek, které splňují celou oblast Page Experience. Dnes už tam najdete upozornění na to, že sekce bude zrušena: Notice: The page experience report will be changing in the coming months. Tento report kombinoval už dříve přidanou stránku Core Web Vitals s dalšími složkami signálů uživatelského zážitku, jako je zabezpečení HTTPS, stav bezpečného prohlížení nebo přívětivost pro mobilní zařízení. Google Search Console: Report „Kvalita stránky“. Na obrázku je nejdůležitější hodnota pro „Adresy URL s dobrými výsledky“, protože vidíte, kolik stránek podle GSC nevyhovuje z pohledu signálů Page Experience. Tato část tedy bude zrušena. Zhodnocení zabezpečení nebo přívětivosti pro mobilní zařízení už v Search Consoli nenajdete. Hodnocení rychlosti však zůstává v části „Rychlost“ : Google Search Console: Report stránek, které vyhovují nebo nevyhovují metrikám Core Web Vitals. Odtud už se pak proklikáme na konkrétní ukázkové URL a můžeme začít hledat konkrétní problém. Google Search Console: Příklady stránek, které nevyhovují konkrétní metrice. Search Console zobrazuje pro každý typ problému podmnožinu adres URL. Tyto URL představují různé typy stránek, které váš web může mít. Účelem této zprávy je pomoci uživatelům odhalit problematické typy stránek tak, aby je bylo možné ladit v nástrojích, jako je Page Speed Insights nebo Lighthouse. Vzorky stránek jsou vybrané tak, aby se jejich opravou zlepšilo celkové hodnocení typu stránky. Jak Google posuzuje rychlost webu? Když Google přišel se signály Page Experience, kladl jsem si otázku, jak přesně to budou měřit a vyhodnocovat. Platí to myslím, po menších úpravách, dodnes. 0) Obsah je stále král, zůstaňte v klidu Signály z oblasti Page Experience platforma používá spolu se stovkami dalších a nikdy nebudou silnější než signály pro kvalitní obsah. Říká to sám Google: we will prioritize pages with the best information overall, even if some aspects of page experience are subpar. A good page experience doesn't override having great, relevant content. However, in cases where there are multiple pages that have similar content, page experience becomes much more important for visibility in Search. Prostě obsah zůstává králem, i když cvrlikání na sítích někdy může působit jinak. Podle studie Sistrixu ze září 2021 to vypadá, že vliv signálu Page Experience byl menší, ale postupně rostl: Zjištění Sistrix o vlivu Page Experience na SEO:– Weby, který splňují PX mají nyní v průměru o 1 % lepší pozice v SERP, ale průběžně se rozdíl zvyšuje.– Weby, které některé z požadavků nesplňují, mají pozice o 3,7 % horší. – Twitter Moje zkušenost z praxe poradenství k rychlosti webu je taková, že rychlost k vyšší návštěvnosti z Googlu pomůže jen ve specifických případech, jako je vysoce konkurenční prostředí a specifické typy webů. 1) Měří se u uživatelů Důležité je zmínit, že se využívají data od skutečných uživatelů, z Chrome UX Reportu . Vyhodnocuje se stav metrik Core Web Vitals, tedy LCP, FID a CLS. Explicitně raději uvádím, že Google v hodnocení nezajímají syntetická měření v Lighthouse a už vůbec ne Lighthouse skóre. Tato syntetická měření slouží vývojářům ke zjednodušení optimalizací, nikoliv pro zjištění, jak na tom web je u Googlu. Důležitý je také proces počítání: Google vezme hodnoty u všech návštěv dané stránky za posledních 28 dní. V distribuci těchto čísel vytáhne hodnotu na 75. percentilu. Posledních 28 dní znamená, že skokové aktualizace se projevují klouzavě, nikoliv hned. Zajímavé je soustředění na 75. percentil, nikoliv například na průměr nebo medián. Je to ale dle mého správně – většina návštěv na webu pak má lepší než v percentilu uvedenou hodnotu metriky. Co například URL, která byla nedávno zveřejněna a ještě nemá data z 28 dní? Dojde pak k seskupení stránek, které jsou si podobné, píšu o tom dále. Stránka dostane skóre podle skupiny stránek nebo podle celé domény. Data od uživatelů můžete vytáhnout: Nejjednodušším způsobem z PageSpeed Insights Podrobněji a s vývojem v čase pak v našem testeru na PageSpeed.cz Doplňujte to vždy pohledem do Google Search Console. Další aspekty, které byly uváděny u příležitosti spuštění hodnocení Page Experience skvěle v tweetu shrnul Fabian Krumbholz, takže z něj vyjdu. 2) Každá metrika samostatně jako signál V rámci Page Experience Google hodnotí každou z Web Vitals samostatně jako signál pro hodnocení. Chápu to tak, že nemusíte mít všechny zelené, ale pro každou jednotlivou metriku budete porovnáváni s konkurencí. Takže pokud konkurence nebude mít zelené LCP a vy ano, můžete za tuto oblast získat zvýhodnění. 3) Zvýhodnění dostanete za zelené metriky Systém je postavený na zvýhodňování. Pokud máte metriku v červené oblasti hodnot, nezískáváte žádné plusové body. Pokud jste v oranžové oblasti hodnot, čím blíže bude hodnota optimu, tím vyšší zvýhodnění získáte. Nejvyšší „boost“ získáváte s metrikou v zeleném škále hodnot. 4) Lepší než zelené už to být nemůže Google dále píše: Dopad na hodnocení stránek bude stejný pro všechny stránky, které jsou v dobrém rozsahu u všech základních ukazatelů Web Vitals, bez ohledu na jejich individuální skóre v Core Web Vitals. To znamená, že když už máte zelené skóre, nemůže to být lepší. Google píše, že například stránka s metrikou LCP na hodnotě 1750 ms a jiná stránka s 2500 ms by se na základě signálu LCP nerozlišovaly. Mimo zelený rozsah skóre by rozdílné hodnoty metriky Core Web Vitals u dvou stránek mohly vést k rozdílnému hodnocení v rámci Page Experience. Jen připomínám, že podstatná motivace pro zrychlení webu je především ve zlepšení uživatelského prožitku. Takže ano, hodnoty metrik lepší než zelené mohou být pro uživatele a konverze lepší. Jen na SEO to už pak nejspíš nemá žádný vliv. 5) Doména > Skupina stránek > URL Možná už víte, že z CrUX dat často nejde vytáhnout informace pro konkrétních URL. Je zajímavé, že Google v tom případě nesáhne po datech pro celou doménu, ale po datech pro „skupinu stránek“. Skupinu stránek osobně chápu podle seskupení, které Google dělá v reportu Web Vitals v Search Console. Na jednu hromadu tam dává stránky, které jsou si podobné a zároveň vidí, že mají problémy s podobnými metrikami. Takže, když nejsou data pro URL, vezmou se data pro skupinu stránek. Když nejsou data pro skupinu stránek, vezmou se data pro doménu. Přesně jak říká Babica. A co když nejsou data pro doménu? I to se stává, zejména u méně navštěvovaných webů. Myslím, že pak prostě výhodu na základě Page Experience signálů získat nemůžete. A rychlost jen pro SEO řešit nemusíte. 6) Data se berou globálně Zajímavé také je, že data se z CrUX nevezmou podle aktuální lokality, takže například pro Česko nebo Slovensko, ale z globální návštěvnosti. Takže pokud v ČR a SR máte dobré hodnoty Web Vitals, ale kazí vám je malá část návštěvníků kdesi na druhém konci světa, budete to muset vyřešit. 7) Data se berou za posledních 28 dní Google nepracuje s měsíčními daty, která např. na PageSpeed.cz zobrazujeme v záložce Domény, ale se stavem za posledních 28 dní . 8) Data od všech stránek, včetně blokovaných v robots.txt? Docela zmatek je v jedné věci: URL, které mají blokované indexování roboty pomocí direktivy „noindex“ nebo uvedením v souboru robots.txt. Budou hodnocené v rámci Page Experience nebo ne? Z principu by, dle mého názoru, mělo jejich skóre ovlivňovat minimálně skóre domény. Vyplývá to z prostého faktu, že hodnocení stránky se nesbírá robotem, ale od uživatelů. Google sám ale ve své nápovědě uvádí, že případě měření přes PageSpeed Insights se zobrazují pouze informace o veřejně indexovatelných stránkách, které zároveň splňují určitý práh návštěvnosti. V případě tahání dat přímo z Chrome UX Reportu pak mohou být zahrnuty souhrnné údaje ze všech veřejných i neveřejných stránek. Navíc se zdá, že v Google Search Console data o Page Experience z těchto stránek vůbec nejsou. Můj odhad? Pro tyto stránky se skóre počítá, výsledky v SERPu to ovlivňuje, ale měřící nástroje od Googlu v tom zatím dělají zmatky. Na závěr Zpětně se ukázalo, že Google svým updatem Page Experience nespustil žádnou velkou revoluci, spíše postupné zlepšení hodnocení, které odskákaly hodně pomalé weby, ale naprosté většiny webů se to nijak nedotklo. Důvodů, proč řešit rychlost webu ale najdete celou řadu. To, že ji prosazuje Google, je jen důsledkem faktu, že pro návštěvníka i provozovatele je mít rychlý web prostě dobré. Co tedy dělat, pokud se chystáte na optimalizaci? V Google Search Console sledujte report Core Web Vitals. Snažte se odstraňovat problémy zde uvedené. Dlouhodobě sledujte rychlost typových stránek webu, i celé domény pomocí testeru PageSpeed.cz. Naučte se, jak správně měřit rychlost webu a ladění metrik CLS a LCP. Třeba pomohou mé webináře. Tyto tři webináře teď můžete pořídit i najednou. Optimalizujte, optimalizujte, optimalizujte. Pomůže vám checklist z PageSpeed.cz nebo moje tipy na novinky - jak zrychlit web. Vzdělávajte se v oblasti rychlosti webu. Pokud si nevíte rady, ozvěte se. Přeji vám rychlé weby a dobré pozice v Googlu. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
01.08.2023 06:00 INP je nová metrika rychlosti webu, se kterou přichází Google v rámci své sady Core Web Vitals. V březnu 2024 má nahradit dnes už neuspokojivou metriku FID . Tato změna se dotkne celé řady z vás, protože INP je metrika daleko přesnější a k webům přísnější. Poznámky k nadcházející výměně FID za INP Lidé z Googlu oznámili, že metrika INP nahradí FID v Core Web Vitals už v březnu 2024. Prodlevy způsobené JavaScriptem budou více vidět. A pro některé vývojáře to může znamenat docela bolehlav. INP je totiž daleko přísnější. Například Tim Kadlec změřil, že z webů postavených na Reactu vyhovuje této metrice jen 17 %. Weby postavené na Next.js jsou na 12 % úspěšnosti. Tim Kadlec doslova píše, že INP bude pro javascriptové vývojáře „tvrdým budíčkem“. A já s ním souhlasím. Vzal jsem 100 nejnavštěvovanějších českých e-shopů z naší studie o rychlosti webů českých e-shopů. Je to mazec. Na mobilu jich novou metriku rychlosti reakce INP splňuje pouhých 17. To jsou důvody, proč mě oznámení o tom, že INP bude už za méně než rok metrikou Core Web Vitals, překvapilo. Google sice v rámci projektu Aurora pomáhá autorům javascriptových frameworků mimojiné s optimalizací INP, ale to je jen malá část problému. Velký balvan bude ležet na ramenou vývojářů konkrétních webů a já vím, že optimalizovat JavaScript pro ně nebude snadné. Pojďme si teď něco povědět o samotné metrice Interaction to Next Paint. Metrika rychlosti odezvy Metrika Interaction to Next Paint zaznamenává prodlevu veškerých interakcí v průběhu celého životního cyklu stránky. Interaction to Next Paint je podobně jako právě FID metrikou interaktivity. Stránka se vám načte a vykreslí, vy můžete provádět interakce z myši, z dotykové obrazovky nebo z klávesnice, ale stránka nereaguje. Hlavní příčinou bývá samozřejmě JavaScript a probíhající dlouhotrvající úlohy , které zablokují vykreslovací vlákno prohlížeče. Metriky jako INP a FID se snaží tyto nepříjemnosti v uživatelském prožitku změřit a tím nám umožnit je odstranit. Odezva vpravo je dobrá, protože indikátor načítání se zobrazí okamžitě po vstupu uživatele, který chce zobrazit obrázek. Autoři z Googlu v případě INP namísto pojmu „interaktivita“ používají pojem „responsiveness“, tedy víceméně schopnost rychle reagovat. Zjednodušeně řečeno je INP metrikou rychlosti odezvy na uživatelské interakce. Ukazuje na to i samotný název. Interaction to Next Paint by se dalo přeložit jako „od interakce do dalšího vykreslení“. Překládat do češtiny se tento název bude špatně, a ani já o to tentokrát nebudu usilovat. Nicméně – v původním názvu se přesně odráží fungování tohoto nového ukazatele. Co INP měří a jak se liší od FID? Metriku First Input Delay už dlouho považuji za nevyhovující. Problém s odezvou na interakce u webů, které jsou plné reklam nebo špatně postavené na moderních frontendových frameworcích, zde máme dlouhodobě. Ale FID žádné problémy ani u těchto webů neukazuje. Důvody, proč metrika FID už z dnešního pohledu nevyhovuje, jsou tři: Měří jen prodlevu při první interakci, nikoliv celou dobu pobytu uživatele na stránce. Neměří celou prodlevu, ale jen její první část. FID je málo přísné, podle dat Googlu metriku splňuje 95 % webů. Asi nikoho nepřekvapím, když napíšu, že INP toto všechno řeší: 1) Měří se celou dobu pobytu na stránce INP měří odezvu všech interakcí až do změny URL a vybere tu nejhorší odezvu se všech interakcí. Pokud je interakcí více než 50 , nevybere se nejhorší hodnota, ale percentil, nejčastěji 98. Měřením po celou dobu pobytu na URL se řeší velká slepota metriky FID, protože podle propočtů Googlu zhruba 90 % interakcí probíhá až po úvodním načtení stránky. INP si tak můžete připodobnit k metrice Cumulative Layout Shift , která se také měří po celou dobu pobytu na stránce. 2) Počítá se celá prodleva FID měří jen první část prodlevy reakce – než reakce probublá do JavaScriptu, který ji musí zpracovat. Vůbec se ale nepočítá s dobou zpracování v samotném JS kódu, která může být opravdu dlouhá. Dále se nepočítá s dobou vykreslení. FID změří odhadem jen třetinu až polovinu reálného zpoždění po akci uživatele. Metrika INP a tři části, kde může nastat průšvih Na schématu vidíme tři části možného zpoždění interakce: Zpoždění vstupu – to, co nyní měří FID. Zpracování vstupu – události, ale hlavně zpracování JS. Zpoždění prezentace – většinou bývá v pohodě, mohou ale pokazit špatné CSS animace atd. Už z tohoto je jasné, že weby, které dříve v pohodě procházely přes metriku FID, teď projít nemohou. 3) Větší část webů přes INP neprojde Jak jsem psal, FID splní 93 % webů. Google deklaruje, že u INP to má spočteno zhruba na dvě třetiny splňujících webů. Hodnoty metriky INP a jak je změřit? Interaction to Next Paint má, stejně jako jiné Web Vitals, od výroby nastavené třístupňové hodnoty, kdy stránka vyhovuje více či méně: V tabulce to pak vypadá následovně: Metrika Dobrá Vyžaduje zlepšení Špatná INP ≤ 200 ms 200 - 500 ms > 500 ms Měření INP Hodnoty nové metriky odezvy interakcí můžete pro své weby získat už teď, protože Google ji už nějakou dobu pro uživatele Chrome sbírá v rámci svého Chrome UX Reportu a poskytuje ve svých měřících nástrojích. Podobně jako u CLS nebo FID bude složitější ji naměřit pomocí syntetických měření typu Lighthouse, protože metrika se sbírá až na základě uživatelských akcí. Ale je zde světlo na konci tunelu, totiž nové režimy fungování právě u nástroje s majákem ve znaku. Takže jak novou metriku změřit? Data od uživatelů vašeho webu získáte například z PageSpeed Insights: pagespeed.web.dev. Můžete použít knihovnu web-vitals nebo extension Web Vitals . V Lighthouse je možné INP změřit v novém režimu Time Span. Nová verze rozšíření Web Vitals umí změřit prodlevy jednotlivých interakcí uživatele. Optimalizace INP Asi byste ode mě rádi dostali rovnou návod, jak tuto metriku snadno optimalizovat. Ale bohužel, tak jednoduché to nebude. Z praxe pro klienty vím, že obecné rady u jakékoliv metriky málokdy zafungují, vždy je potřeba analyzovat konkrétní web a konkrétní stránky. U této metriky to bude ještě složitější. Samozřejmě vás ale zkusím alespoň trochu navést. Zaměřte se na TBT Metriky jako FID nebo nově INP jsou velmi citlivé na takzvané long tasks v JavaScriptu. Pokud má totiž prohlížeč práci s dlouhým zpracováním JS kódu, nemůže reagovat na vstupy od uživatele. Zaměřit byste se tedy měli na optimalizaci metriky TBT , kterou jde změřit snadno všemi možnými nástroji. Podle údajů Googlu koreluje TBT dvakrát lépe s INP než s FID, což je dobrá zpráva, protože optimalizace FID byla často docela peklíčko. Obecná rada? Optimalizujte JavaScript Obecně samozřejmě pomáhá mít ve stránce co nejméně JS, který něco provádí: odstraňovat nevyužitý kód, správně bundlovat, odkládat stahování a spouštění kódu, který v daném uživatelském kontextu není potřeba. Dávat pozor na třetí strany. Důležitá v případě INP může být také volba JS frameworku. Např. weby běžící na Next.js na mobilu splňují metriku jen z 20 %. Lidé z Googlu sice deklarují, že s autory těchto knihoven budou pracovat na zlepšení, ale tipuji, že některé autory webů běžících na těchto frameworcích čekají zajímavé časy. Více o optimalizaci INP najdete jako vždy v materiálech přímo od Googlu Co s tím teď? Pokud vám můžu poradit, zatím si INP pro své weby změřte hlavně změřte. Jestliže vám vyjdou velmi špatná čísla a chcete-li do budoucna Web Vitals splňovat a hlavně mít rychlý web, pak raději začněte připravovat plán na nápravu . Z mé zkušenosti je totiž právě optimalizace JavaScriptu jedna z nejsložitějších a nejdéle se táhnoucích prací na rychlosti webu. Pokud INP splňujete, nezbývá než vám gratulovat. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
01.08.2023 06:00 V pozvánce na WebExpo 2023 jsme soutěžili o jednu vstupenku a jednu knížku. Dopadlo to dobře, výherce už známe: Jakub Machač vyhrál vstupenku na WebExpo. Michaela Havlíková vyhrává knížku CSS: moderní layout. Soutěžících jsem se ptal, co je na webařině baví. A protože mě přišly zajímavé odpovědi, s jejich svolením některé z nich publikuji zde, na Vzhůru dolů. Antonín Zejda napsal: Nejvíc mě k webu táhne paradoxně to, co ještě neexistuje. Technologie a neomezené možnosti, které nám technologie nabízejí. Daniel Beránek napsal: Ačkoli teda nemám s webařinou velké zkušenosti, tak mě moc baví to, že zde mohu uplatnit svoji kreativitu. Žil jsem v klišé, že aby někdo mohl být ajťák, musí to být brutální analytická mašina s matematickým myšlením. Tento stereotyp se mi pomale daří odbourávat a více pronikám do IT světa. Lýdie Hemalová napsala: Testování webových aplikací je občas výzva. Na webu se dá řešit tolik zajímavých věcí od přístupnosti po performance. Proto mým nejoblíbenějším nástrojem jsou DevTools, kde stále objevuji nové a nové funkce. Andra Nistor napsala: Baví mě, když se můžu podílet na vývoji aplikací, které uživatelům pomáhají při jejich každodenní práci tím, že jim ulehčuji činnost . Michaela Havlíková napsala: Mám ráda pocit, že dokážu vytvořit něco, co je užitečné a mohu vidět výsledky své práce takřka okamžitě. Jakub Machač napsal: Nejvíc mě baví že s pár základními nástroji je člověk schopen udělat téměř cokoliv ho napadne. A navíc se na téhle cestě se dá objevovat a zdokonalovat do nekonečna. Hezké, že? A co na webařině baví vás? Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
