23.06.2022 15:45 Přečtěte si, jak jsem se stal sazečem své vlastní knihy. Stalo se tak s pomocí webových technologií, knihovny Paged.js a několika přesně mířených ručních zásahů do výstupního PDF v Adobe Acrobatu. CSS je kam se podíváš. Proč ne v sazbě knih? CSS je všude. Vytváříme s jeho pomocí weby a webové aplikace. Fajn. Například také ale aplikace, které na první pohled vypadají jako nativní, jako třeba Spotify. Vývojáři je tvoří pomocí webových technologií, což umožňuje framework Electron. CSS to ale dopracovalo už i do vesmíru. Uživatelské rozhraní v kosmické lodi Dragon od SpaceX je dělané pomocí HTML, JS a CSS. „Houstone, máme problém. Vyskočila na nás cookie lišta.“ Pro mě je podstatné, že CSS hraje velkou roli v mé publikační činnosti. Skoro vše píšu v Markdownu a pak pomocí transformací převádím – jednou na blog Vzhůru dolů, jednou do e-booků… Populární formát pro e-knihy EPUB je jen přejmenovaný ZIP archiv, ve kterém opět najdete HTML a CSS soubory. Já mám tedy kaskádové styly skoro úplně všude. Ale co tištěné knížky? Když jsem vydával knihu „Vzhůru do webdesignu", štvalo mě, že sazečům musím kvůli tisku exportovat Word. Sazeči pak CSS opíší do vlastního systému designu v InDesignu. To se nedá automatizovat a je to náchylné na chyby. A navíc se mi to vůbec nelíbí. Schéma distribuce obsahu: Na web a do EPUB to jde dobře. Ty shluky křivek reprezentují procesy, kterým říkám „WTF 1“ a „WTF 2“. Nesrozumitelnou a podivnou činnost sazečů, jejichž vstupem je Word a výstupem tištěná kniha. CSS je přitom navrženo pro tvorbu designu a vzhledu čehokoliv, ne jen webů. Proč s ním tedy nesázet i knihy? Když vezmeme zjednodušené schéma vrstvení CSS vycházející z metodiky ITCSS, zjistíme, že se to hodí i na knížky: Text, komponenty a layout. Čirou náhodou je máme i v knížkách. Text Stylování textu v knížkách pomocí CSS? Jasně, to dává smysl . Komponenty Komponenty máme na webu. Existují i v knížkách? No jasně, třeba každý obrázek s popiskem je vlastně komponenta. V knížkách si umím představit celé design systémy, například pro vydavatelství. I tady se CSS, jako systematický zápis designu a vzhledu, hodí. Layout Layout je v knížkách přítomen na spoustě míst, v té mé třeba v předělu kapitol. I v tom je CSS samozřejmě dobré. Takže ano, CSS se obecně pro tvorbu knížek náramně hodí. Jak se ale dostaneme z prohlížeče do tiskárny? První věc, kterou potřebujeme, je umět vytvořit PDF, hlavní zdroj pro tisk čehokoliv. mPDF a další tradiční metody tvorby PDF Existuje řada knihoven, jako mPDF, které se spouští v PHP. Ty sice CSS používají, ale většinou je to specifická verze stylů, upravená autory knihovny. Specifikace CSS poměrně silně ohnutá také v knihovně mPDF. Přidali si tam nové vlastnosti , jiné odebrali a ty, které v mPDF podporují, mají všelijaká omezení. Prostě a jednoduše – abyste mPDF a podobné knihovny mohli používat, musíte se naučit styly prosazované těmito knihovnami. Znalost CSS vám stačit nebude. Celou dobu si při používání knihoven jako mPDF pak budete trošku ťukat na čelo, protože víte, že v CSS existuje řada vlastností určených vyloženě pro sázení tiskových dokumentů. Asi je vám jasné, že touto cestou jsem se vydat nechtěl. Naštěstí se na obzoru objevila naděje. Skvělý Paged.js V posledních letech se vyrojila celá řada nových knihoven, které fungují na základě webových standardů a principu polyfillu – pomocí JavaScriptu emulují podporu vlastností, které zatím prohlížeč nezvládá. Paged.js, javascriptová spása. Knihovna Paged.js je asi nejjednodušší z nich, ale vysázel jsem s její pomocí docela tlustou knížku, takže leccos zvládne. Paged.js je možné použít pro generování jakýchkoliv výstupů do PDF. Já sázím knížky, vy můžete chtít generovat reporty nebo doklady typu faktur. Knihovnu použijete buď jako NPM balíček na příkazové řádce… npm install -g pagedjs-cli pagedjs pagedjs-cli index.html -o result.pdf … nebo jako polyfill v prohlížeči. Stačí tohle přidat do svého HTML: V tu chvíli v prohlížeči uvidíte náhled v podobě tištěné stránky: Debuguji knížku v DevTools Chromu. Možnost vidět zdrojáky v DevTools prohlížeče je naprosto fantastická! Vy, kteří rádi „designujete v browseru“, víte o čem mluvím. Když Paged.js používáte jako polyfill, výstupem je PDF, které ukládáte z prohlížeče: „Save as PDF“ a je hotovo. Skoro. Nebo vlastně ještě vůbec. Asi vás nepřekvapím sdělením, že Paged.js je psaný v JavaScriptu. To je velká výhoda, protože si běžný webař může pohrát s výstupy. Pokud programování není vaše silná stránka, existuje řada hotový řešení – například pro obsah knihy nebo rejstřík. Já jsem si s těmito předpřipravenými kousky kódu vystačil. Teď už tedy víme, že máme nástroj, který nám ze standardní trojice HTML, CSS a JS dokáže vytvořit PDF. Otázka ale zní, zda si vystačíme s těmi samými kaskádovými styly, které používáme na webech. Nevystačíme. Musíme svou znalost stylů rozšířit o další, již standardizované, ale málo známé vlastnosti. CSS vlastnosti pro tisk CSS Paged Media. Tato část kaskádových stylů existuje již dlouhá léta a vcelku bez povšimnutí se pomalu ale jistě sune vpřed. Samotného mě překvapilo, že jsme se už dostali do stavu, kdy je to možné používat v praxi při sázení tiskových výstupů. Podpora vlastností pro tisk je v prohlížečích vcelku dobrá. Důležité je ale říct si, že občasné nedokonalosti nevadí. Používám totiž polyfill, který chybějící vlastnosti emuluje. I tak ale navíc tvůrci Paged.js doporučují pro tvorbu PDF využít Chrome. Teď už k samotným vlastnostem. Vlastnosti break-* Pomocí vlastností break-inside, break-after a break-before je možné zakázat, vynutit nebo jinak ovládnou rozdělení určité části textu nebo komponenty na dvě stránky. Hodí se to například pro zákaz rozdělení nadpisu na dvě stránky: h1, h2, h3 Více: MDN, CanIUse. Pravidlo @page Tímto pravidlem definujeme vzhled stránky k tisku, například její velikost nebo vnější okraje: @page V případě knihy „CSS: moderní layout“ jde o formát V8, ale můžete si zde nastavit samozřejmě i A4 nebo něco jiného. Více: MDN, CanIUse. Pravidla pro oblasti stránky Platí, že si můžeme pojmenovat určité části dokumentu. Každá stránka pak má své oblasti mimo hlavní obsahovou část, do kterých můžeme umísťovat různé servisní prvky. Zde je vidět například deklarace pro umístění stránkování: @page pageContentMain } Vysvětlím to: Deklarace cílíme na stránky pojmenované pageContentMain a oblast @bottom-right . Umístíme tam obsah v podobě počítadla stránek ). Vdovy a sirotci Jedna ze základních typografických pouček praví, že na posledním řádku odstavce by nemělo zůstat jedno slovo a na začátku stránky by neměl být jediný řádek textu předchozího odstavce . Touto deklarací tomu zamezíme: h1, h2, h3, p, li, blockquote Je to podporované všude, kromě Firefoxu. CanIUse. MDN: widows, orphans. Sazba do bloku a rozdělovníky Sazbu do bloku jsme si ve webdesignu už zhruba před dvaceti lety zakázali, ale v knižní sazbě se vesele používá dál. Proč? Vysvětlení je jednoduché – prohlížeče neumějí automaticky rozdělovat slova, takže sazba do bloku je možná jen tam, kde slova rozdělíme ručně, takže skoro nikde. V knize mám ale toto pravidlo: p Zarovnání do bloku samozřejmě rozumím všechny prohlížeče, ale pro automatické zalamování slov je potřeba mít polyfill jako Paged.js. Na webu bych to ale polyfillem určitě nedělal, to by bylo docela peklo pro performance. Rozdělovníky prohlížeče už ale umí , tak proč tolik povyku? Zakopaný pes je v tom, že kromě Safari nemají browsery odpovídající slovníky pro češtinu . Tolik k základům CSS pro tisk. Takhle vypadá finální knížka v PDF: Layout knihy „CSS: moderní layout“. Následně stačí exportovat z prohlížeče do PDF. A je to. A je to…? PDF máme, tak šup do tiskárny Tiskárna PBtisk, kterou jsem si pro tisk knih vybral, dělá docela velké zakázky a na malé vydavatele jako jsem já nemají zase tolik času. Když jsem jim poslal své první PDF, odpověď zněla stručně a jasně: Pro ofsetový tisk naprosto nevhodné. Trošku jsem to ale očekával, to víte, že ano. PDF z prohlížeče nesplňuje požadavky tiskárny, minimálně v tom, že je v barevném režimu RGB. Tiskárna potřebuje samozřejmě CMYK. PDF je ale možné s pomocí několika úprav v placené verzi Adobe Acrobatu doladit: Převod z RGB do CMYK je možné udělat automaticky. Ano, pro některé typy publikací by to bylo nevhodné, ale pokud se s tím předem počítá u obrázků, vyjde to dobře. Ořezové značky se řeší tak, že v Paged.js nadefinujeme o 3 mm větší stránky a pak v Acrobatu přidáme 3 mm ořezové značky. Prohlížeč nám při exportu do PDF bohužel trošku pokazí barvy, takže je nutné některé automaticky nahradit. Například ze směsi CMY barev je potřeba udělat černou . Tři kroky na půl hodiny práce, na které jsem přicházel zhruba dva měsíce. A nebýt lidí jako Petr Raist Šťastný, Dan Střelec nebo Jirka Kosek, asi bych to nikdy nedokázal. Nakonec je tiskárna spokojená a pustí se do tisku. Je to vysázené pomocí HTML a CSS a je to vytištěné. Jupí! Knížka je hotová, je krásná a má se čile k světu. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
15.06.2022 12:00 Na letošním WebExpu jsem uvedl program dodávaný naší komunitou Frontendisti.cz krátkou keynote o zásadních změnách, které se aktuálně dějí ve vývoji prohlížečů. Zde je její obsah v textové podobě, ale můžete se také podívat na prezentaci nebo video. Frontendová keynote na WebExpo 2022. Nějaký pán tam něco tlachal o prohlížečích. Chci dnes mluvit o našich milovaných prohlížečích. Chci mluvit o tom, co se na nich v posledním roce tolik změnilo. Můj vztah s prohlížeči začal v roce 1996. Když jsem přišel na vysokou školu, většina uživatelů tehdejšího internetu používala Netscape Navigator. Nesnášel jsem ho, byl plný chyb. Na trhu se ale objevil nový a progresivní prohlížeč – Internet Explorer od společnosti Microsoft. V té době nám to ještě připadalo skvělé. Éra dominance jednoho prohlížeče Vysokou školu jsem dokončil v roce 2000. V té době už s prohlížeči bylo všechno jinak. Většina trhu patřila Microsoftu jeho prohlížeči. O čtyři roky později to bylo ještě horší. V té době se zdálo, že na světě existuje jen jeden prohlížeč. Internet Explorer. Vývojáři začali na své stránky umisťovat takovéto ikony jako „Optimalizováno pro Internet Explorer”. Bylo to však zvláštní, protože Microsoft se nepodílel na webových standardech, ale vytvářel své vlastní. Měli jsme tak dvě verze standardů – teoretické oficiální od W3C a pak ty od Microsoftu, které prakticky válcovaly trh. 2022: Co se mění? Přejděme do letoška. Situace už je úplná jiná. Všechny velké technologické společnosti včetně Microsoftu pracují na webových standardech v rámci konsorcia W3C. Máme tu však jiný problém. Různé prohlížeče mají různé priority z pohledu práce na podpoře některých webových standardů. Takže na některé nové funkce čekáme dlouho. Prohlížeče v roce 2022. Zdroj: Statcounter.com. Máme dva hlavní prohlížeče – Chrome a Safari – a několik menších. Internet Explorer už prakticky neexistuje . Jako vývojáři si ale tím pádem nemáme na co stěžovat. Můžeme mluvit o štěstí, že roli Exploreru převzalo Safari, jak říkají mnozí zlí jazykové na adresu prohlížeče od Apple? Ne, ne. Zlí jazykové se už dnes pravděpodobně mýlí. V roce 2021 se začal Apple o věc zajímat na Safari více pracovat. Najali spoustu vývojářů a věci se začaly měnit. Compat 2021 a Interop 2022 Ještě před rokem bylo Safari z hlediska přidávání nových HTML a CSS vlastností nejhorším prohlížečem. Letos však začalo být plně srovnatelné s Chromem a Firefoxem. Chrome a Firefox: „Safari, co blbneš?“ Graf mám od iniciativy Compat 2021. Je to skupina lidí, kteří se snaží sjednotit přidávání podpory webových standardů do prohlížečů. Určují, které funkce jsou nejdůležitější. Díky nim máme v moderních prohlížečích řadu nových funkcí. Například odstranili chyby ve flexboxu a gridu. Přidali také funkci position:sticky nebo vlastnost CSS aspect-ratio. Letošní iniciativa se jmenuje Interop 2022. Jejím cílem je zaměřit se na nové funkce a dostat je do prohlížečů. Díky tomu jsme mohli na WebExpo 2022 prezentovat novinky, jako jsou kaskádové vrstvy v CSS nebo dialogové okno v HTML. A těšíme se na další novinky – například CSS color functions, subgrid a další… Interop 2022 dashboard. Jsou na tom dobře. Všichni. Konečně! Toto je aktuální stav. Jak vidíte, menší prohlížeče nyní z pohledu přidávání vlastností ze standardů mohou konkurovat Chromu a vývoj nových CSS a HTML vlastností se odehrává v režimu kooperace mezi prohlížeči. Myslím si, že to je pro nás jako webové vývojáře skvělé. Děje se to poprvé v historii, buďme za to rádi. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
14.06.2022 02:54 :has je funkční selektor, který můžeme mimojiné použít jako selektor rodiče, tedy vybrat rodičovské prvky, obsahující potomky určitého typu: a:has Tento selektor cílí na všechny odkazy , které mají v DOMu jako potomka obrázek . Je to selektor rodiče. Ale taky nemusí být. Selektor :has je podporován v Safari a to od verze 15.4 z března 2022. Fanfáry prosím! Chrome oznámil, že od verze 101, takže v nejbližším měsíci, bude selektor podporovat zkušebně s možností zapnout jej pod nastavením vlaječek . Nejen selektor rodiče Selektor :has je součástí návrhu specifikace W3C Selectors Level 4. Vzbudil velkou pozornost, protože jednou z možností jeho použití je právě selektor rodiče, což je v CSS už asi dvacet let něco jako banány za komunistů. Lidé to strašně moc chtějí, stáli by na to fronty, ono se to občas někde objeví, ale zpravidla je to planý poplach. Jenže :has ve skutečnosti selektor rodiče není. Doslovně, přesně podle specifikace, jde o relační pseudotřídu . Relační proto, že do závorek můžete napsat jakýkoliv relativní selektor, se vztahem k selektoru před dvojtečkou: a:has section:has img:has Všimněte si posledního případu. Vybírá prvního z bezprostředně navazujících sourozenců v DOMu. Tady o selektoru rodiče nemůže být řeč. Navíc je to užitečné a skoro stejně nedostatkové jako ty banány za komunistů. Nebo jako selektor rodiče v CSS. Ukázka se selektorem rodiče Podívejme se na následující CodePen. Jsou v něm dva prvky .box. Jeden obsahuje obrázek a jeden pouze text: Lorem ipsum… Quam doloremque… Relační pseudotřídou :has se pak snažím zacílit boxík s obrázkem: .box:has Výsledek uvidíte níže. Jen pozor, v dubnu 2022 to bude fungovat jen v Safari 15.4: Ukázka se selektorem předchozího sourozence V tomto demíčku se zaměříme na stylování prvků v textu, za nimiž následují jiné specifické prvky. Máme dva nadpisy, za jedním následuje odstavec, za druhým seznam položek: Lorem ipsum, dolor sit amet Lorem… Quam doloremque… Lorem… Pokud bychom ten druhý chtěli stylovat jinak, opět nemusíme složitě přidávat třídu, ale použít relační pseudotřídu :has: h2:has Ani tuto ukázku neuvidíte plně funkční jinde než v Safari 15.4: Další možnosti, občas dechberoucí Když jsem procházel, co se selektorem :has vykouzlili jiní autoři, občas mě srdíčko poskočilo radostí. O jejich nápady se s vámi musím podělit, v tomto případě hlavně o nápady Matthiase Otta. form:has form:has figure img:has .grid:has :last-child) Všimněte si hlavně té poslední možnosti. Rozložení v CSS layoutu upravujeme počítáním prvků uvnitř. Jde o aplikaci takzvaných quantity queries, které už před lety popsal Heydon Pickering. Máte jiný zajímavý příklad použití? Napište mi, přidám jej do článku. Podpora v prohlížečích Stav podpory :has k dubnu 2022 je tento: Safari nový selektor plně podporuje od poslední verze, tzn. 15.4. Chrome si s :has pohrává a od verze 101 bude možné zkoušet za vlaječkou. Firefox zatím nevysílá signály, že by měl podporu v nejbližší době v plánu. To nás mrzí, že… ? V tuto chvíli by, kvůli zdaleka ne plné podpoře, asi nebylo vhodné selektor :has začít používat na veřejných webech. Pokud byste to přes to chtěli zkusit, zmiňuji zde nápad testování podpory selektoru s možností vytvoření alternativního řešení pro přohlížeče, které :has neumí. Prostě využijeme dotaz na podporu @supports: @supports selector ) Existují samozřejmě také javascriptové polyfilly, které funkci :has nahrazují, ale neodkážu na ně, protože z pohledu výkonu považuji nahrazování takto nízkoúrovňové funkce prohlížeče za nepěknou prasárnu. Nevím jak vy, ale já se na podporu :has v prohlížečích docela těším. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
10.06.2022 00:15 S Robinem tradičně reagujeme na výsledky ankety State of CSS 2021. Nejprve krátké zamýšlení o výhodách a nevýhodách anket. Pak už sypeme novinky a přemýšlíme, jak užitečné pro webaře mohou být. Grid, subgrid, Container Queries, Cascade Layers, clamp , funkce barev, funkce pro porovnávání… Opět se nám to do stylů sype ve velkém. State of CSS: Graf používanosti a popularity nástrojů a vlastností kolem CSS. Smysl anket a nesmysly v nich Anketám „State of CSS/JS“ se věnujeme pravidelně a tak nám tentokrát přišlo správné se zamyslet nad různými zkresleními, které v jejich výsledcích vidíme. Prvním je specifická cílová skupina. Ankety vyplňují jen jednotky tisíc lidí z pravděpodobně mnohamilionové skupiny vývojářů. A vyplní je ti, kteří sledují trendy a jsou vlastně na špičce vývoje frontendových technologií. Dále zde můžeme čekat zkreslení způsobené egem. Vzhledem k tomu, že ankety poněkud nešťastně kombinují průzkum s kvízem, jehož výsledek je možné sdílet na webu, je docela dobře možné, že účastníci nad svými znalostmi přimhouří oči a to může silně zkreslovat míru známosti některých technologií, hlavně právě u CSS. O těchto zkresleních je dobré vědět, pokud se anketami necháváte inspirovat. Firemní strategie bychom na základě State of CSS/JS nestanovovali, ankety mohou ale být vcelku návodem, které technologie jednotliví webaři mohou učit a které naopak pomalu opouštět. Doufám, že v tomhle vám pomůže i náš komentář k nim. Podcast MP3 ke stažení Obsah Robinův tip: Vývojářská kata na Exercism.org Martinův tip: Why Lighthouse Performance Score Doesn’t Work Zamyšlení nad anketami State of CSS/JS Nerozumění kolem CSS Modules Proč možná raději nesdílet svoje skóre na sociálních sítích Buildovací nástroje kolem CSS: CSS Modules, vanilla-extract a TypeScript jako preprocesor CSS-in-JS: Stitches, Styled Components a jak to je aktuálně v téhle oblasti? Frameworky: TailwindCSS a verze 3, Windi CSS a nesmrtelný Bootstrap s 85 % používanosti Preprocesory, postprocesory: Proč Sass pořád takhle dominuje? PureCSS pořád na Robina mává z minulosti Prettier Kde se lidi vzdělávají a proč dává Medium pořád smysl, nejen pro autory CSS vlastnosti: nástup používání gridu a vymírání MSIE, dále subgrid, Container Queries, porovnávací funkce, aspect-ratio Bram.us: predikce pro CSS v roce 2022: Container Queries, parent selektor :has, kaskádové vrstvy a blýská se u Safari na lepší časy? Sekání zahrady, mytí nádobí, luxování nebo vana. Kde nás posloucháte vy? Nalaďte nás Spotify – iTunes – Google Podcasty – TuneIn – Anchor – RSS podcastů. Ale vážně – kde nás posloucháte? podcast@vzhurudolu.cz
03.06.2022 03:45 INP je nová metrika rychlosti webu, se kterou přichází Google. Zatím je považována za experimentální, ale všeobecně se očekává, že po doladění nahradí v rámci metrik Web Vitals.) zhruba v horizontu jednoho roku poměrně 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ší. 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. 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. 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 u webů, které jsou plné reklam nebo špatně postavené na moderních frontendových frameworcích, zde máme dlouhodobě. Ale FID to ani u těchto webů neukazuje. Důvody, proč FID 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 , vybírají se percentily, nejčastěji to bude 98. percentil. 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á a nepočítá se s dobou vykreslení. Odhadem FID změří jen třetinu a poloviny 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. A opravdu, troufnu si tvrdit, že INP bude pro spoustu provozovatelů webů docela postrachem. 3) Větší část webů přes INP neprojde Jak jsem psal, FID splní 95 % webů. Google deklaruje, že u INP to má spočteno zhruba na dvě třetiny splňujících webů. Od doby, co je možné INP změřit, namátkou kontroluji hodnoty metriky pro weby klientů PageSpeed.cz i neklientů, u kterých bych osobně tipoval, že budou mít problémy. No a co myslíte? Skoro vždycky to tam je. :) 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ě: Projděme to ještě slovně: Hodnota INP nižší nebo rovna 200 milisekundám = stránka má dobrou odezvu interakcí. INP nad 200 ms a pod 500 ms nebo na této hodnotě = odezva interakcí vyžaduje zlepšení. INP nad 500 ms = stránka má špatnou odezvu interakcí. 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 . 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. 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. Ale i tak pozor – jde o novou, zatím experimentální metriku, která se ale může časem měnit, takže vám doporučuji sledovat její vývoj. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
