30.04.2021 16:04 Hotwire je „krásná nová věc“ ze světa frameworku Ruby on Rails. Jde o zastřešující název pro balíček knihoven. To podstatné je řečeno hned zkraje: Hotwire je alternativní přístup k vytváření moderních webových aplikací bez použití velkého množství JavaScriptu zasíláním HTML namísto JSON, říká text na titulce. Hotwire jde proti aktuálnímu trendu javascriptových klientských aplikací , které se naopak snaží klienta vytěžit co nejvíce. Do architektury moderních webových aplikací, ať už jde o server nebo klienta, zase tak moc nevidím, ale velmi mě to zajímá z pohledu toho, co mě živí – rychlosti, nebo chcete-li performance. Ještě jsem neviděl web, kde by tuny JavaScriptu zpracovávané na klientovi, vedly k pěknému uživatelskému zážitku, minimálně ne při prvním vstupu. Ještě dál jde Matt E. Patterson v zajímavém textu s poněkud provokativním titulkem The Future of Web Software Is HTML-over-WebSockets. Autor se pohybuje ve světě Ruby on Rails, takže titulek berte s rezervou, ale určitě je zajímavé si to přečíst. Javascriptové frameworky s příchodem Angularu a Reactu umí vyřešit problémy, které jsme dříve řešit neuměli, „reaktivita“ při interakcích s aplikací přinesla zásadní benefity z pohledu UX a na fakturách za servery viditelně šetříme: „Server“ byl odsunut výlučně k hostování datové služby API, přičemž většina business logiky a veškerého vykreslování HTML se děje na klientovi. Jenže náklady dnes netvoří ani tak infrastruktura jako platy vývojářů. U složitějších aplikací potřebujeme kromě frontendistů ještě backendisty, což komplikuje komunikaci a zvyšuje náklady. A pak je tu ten vliv JS frameworků na rychlost. Co nabízí Hotwire? Programátoři backendových aplikací ze světa Ruby on Rails s pomocí balíčku knihoven z Hotwire budou prý schopni dosáhnout podobné interaktivity jakou zajišťují javascriptové SPA. Je to založené na WebSockets, které umožňují rychlý oboustranný přenos dat. Na klientovi neparsujeme JSON, ale do stránky prostě vkládáme kousky HTML, což je samozřejmě výkonnostně pro klienta daleko méně náročné. Matt E. Peterson uvádí příklad s našeptávačem: Při každém stisknutí klávesy odešlete dotaz na server přes WebSockets, zpět do klienta dostáváme změněnou sadu značek . Silný server, tenký klient. Takže jsme tam, kde jsme byli. Tyto technologie i postupy jsou známy a používány už léta. Tak jasně, málokdo má koule, aby takové věci říkal NEW MAGIC jako David Heinemeier Hansson, že ano: Hotwire aka NEW MAGIC is finally here: An alternative approach to building modern web applications without using much JavaScript by sending HTML instead of JSON over the wire. This includes our brand-new Turbo framework and pairs with Stimulus 2.0 https://t.co/Pa4EG8Av5E— DHH December 22, 2020 Ale znáte to – staré technologie se objevují v nových kontextech, aby další generaci vývojářek a vývojářů otevřely oči. Proč ne, když to něčemu pomůže: Progressive enhancement gets repackaged and released as “new magic” time and time again, but seriously if it gets more people doing it, it’s a good thing.— Jake Archibald December 23, 2020 A co ta rychlost? Srovnání vstupní rychlosti Gmailu a Hey.com Gmail asi znáte, ale možná nevíte, že je to klasická klientská javascriptová SPA. Klient stáhne HTML, v něm skoro nic není, jen javascriptový soubor, ten začne stahovat další JS soubory, spoustu JSONů… No a výsledek je takový, jaký byste čekali. Lighthouse test pro Gmail. Hey.com je e-mailový klient z dílny Basecamp, kde dámy a pánové implementovali právě sadu Hotwire. Výsledek je trapně dobrý, jako z nějaké korporátní případovky o rychlosti webu. Lighthouse test pro Hey.com. Vy, kteří umíte číst výsledky Lighthouse, asi od boku řeknete: Ano, ty rozdíly tady dělá JavaScript. Vy ostatní se podívejte na metriku Total Blocking Time. Tohle srovnání je dělané opravdu z voleje. První, které mě napadlo. Pravděpodobně porovnávám z pohledu performance špatně napsanou klientskou javascriptovou aplikaci , s odladěným Hey.com, který autoři používají jako případovku pro svůj devstack. Aplikaci, která umí běžet offline s aplikací, která to neumí. A tak dále. Ale i tak… z pohledu rychlosti to rozhodně zajímavé je. Jsem fakt zvědavý, jak na to budou reagovat vývojáři a další frontendové i backendové frameworky. Pokud bychom se dívali na vývoj webů jako jednolitý proud a Hotwire jako nový „trend“, pak jde o zpátečku a přesun zpět na server. Jenže takhle to není. Weboví vývojáři už jsou dneska uzavření ve světech svých platforem – máme tu frontendisty , péhápkáře, vývojáře na technologiích Microsoftu a pak vývojáře ze světa Ruby on Rails. Takže vlastně by mě nejvíc zajímalo, jestli jsou myšlenky z technologie jako je Hotwire přenositelné do jiných světů. Dodatek: Čtenář Jan Oppolzer píše, že v ekosystému péhápkovského frameworku Laravel se objevilo podobné řešení jménem Livewire. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
30.04.2021 16:04 Zápis image-set umožňuje nechat prohlížeč vybrat nejvhodnější obrázek, definovaný v rámci vlastnosti background-image, ze sady, kterou mu připravíme. Je to vhodné zejména pro posílání různých obrázků na obrazovky s vysokou hustotou pixelů: .box Od února 2021 tento zápis podporuje Firefox . Díky tomu už bude brzy možné základní varianty zápisu image-set používat ve všech moderních prohlížečích. Jak jste asi pochopili, jde o obdobu atributu srcset pro značku . Některé varianty zápisu image-set mohou přebírat také funkčnost značky , jenže ty zatím nejsou podporované. image-set je prostě takový malý srcset pro obrázky na pozadí vkládané přes CSS. Výběr obrázku podle hustoty pixelů Obrázky definované ve vlastnosti background-image občas potřebujeme prohlížečům poslat v různých variantách, protože nevíme, jakou hustotu pixelů bude mít zařízení, na kterém běží. .box Obecně vzato, v image-set vždy uvádíme adresu obrázku a podmínky za jakých se má zobrazovat. Tak je to ve specifikaci. Jenže prakticky vzato dnes máme jediný možný zápis – deskriptory 1x, 2x, 3x a podobné udávají hustotu pixelů, tedy hodnotu dppx, kterou znáte z hodnoty resolution v Media Queries. Takže například na většině počítačů s Windows se stáhne první obrázek , protože dppx má hodnotu 1. Na iPhonu 11 se stáhne druhý obrázek. Na některých moderních Androidech, které mívají vyšší hustotu pixelů, i 3 a více, pak poslední obrázek. Není to jediná varianta, kterou bychom podle specifikace mohli použít. Další teoretické možnosti použití image-set , zatím nepodporované Specifikace je jedna věc, praxe ale velí vycházet z podpory v prohlížečích. Dále uváděné možnosti zůstávají na papíře. Jediný prohlížeč, který je podporuje, je právě nový Firefox Nighly. Výběr podle typu obrázku Podobně jako u značky bychom i tady mohli prohlížeči nabídnout dva formáty pro jeden obrázek. To by bylo skvělé pro využití u nových formátů jako WebP nebo AVIF… .box …kdyby to ovšem podporovaly prohlížeče. Ke dni psaní s tímto zápisem uspějete jen Firefox Nightly. Více je možné vidět v CodePenu. Kombinace obrázků s generovaným pozadím Občas by se kódérkám a kóderům mohla hodit kombinace obrázku s generovaným pozadím, např. přechody tvořenými pomocí linear-gradient . .box Podporuje to opět jen nový Firefox ve vývojářské verzi Nightly. CodePen k hraní. Deskriptor w V atributu srcset bychom teoreticky mohli mít možnost používat deskriptor w, jenž prohlížeč informuje o šířkách nabízených obrázků. To aby si lépe vybral. .box Tady ale pouštím imaginaci na plné obrátky a troufám si jít opravdu daleko, protože i ve specifikace o tomto mluví jako o přání a úkolu pro budoucí specifikátory, nikoliv o navržené vlastnosti. Tak nic. Mrkněte se na CodePen. Na vaše objevování zápisu image-set se těší celá moje kolekce CodePenů. Podpora Použitelnost zápisu image-set díky implementaci ve Firefoxu bez pochyby v příštích měsících prudce stoupne. Jde totiž o poslední moderní prohlížeč, který jej dosud neuměl. Jenže pokud jste se, jako já, nechali namlsat všemi zde uvedenými možnostmi zápisu, budete stejně zklamaní. Ale tak už to mezi námi webaři chodí. Jsme nadšení z implementace nový vlastností, abychom byli tentýž den zklamaní, co všechno ještě prohlížeče neumí. Při implementaci nezapomeňte na Autoprefixer, protože i moderní prohlížeče pro tuto vlastnost vyžadují prefixy – např. Chrome rozumí jen zápisu -webkit-image-set . Internet Explorer je sice už téměř vymřelý druh, ale pokud byste potřebovali zajistit si fungování i v něm, musíte uvést náhradní řešení. Je to vidět v mém prvním CodePenu: .box Vše o podpoře image-set najdete klasicky na CanIUse. caniuse.com/css-image-set Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
14.04.2021 16:02 Martin Kolář pro Vzhůru dolů píše o nástroji, který u vývojářů není právě populární. Přesto se bez Google Tag Manageru na většině dnešních webů nedá obejít. Po rychlém úvodu si v textu vysvětlíme, proč je GTM tak důležitý a proč by se vývojáři neměli vzdávat zodpovědnosti za správu značek na svých webech. Základním účelem správců značek je snadná správa značek . V případě webu jsou značky defakto kusy javascriptového kódu. Video: GTM očima marketéra a vývojáře Martin Kolář a Marek Pěntoň vysvětlují, proč by vás Google Tag Manager měl zajímat. → YouTube kanál V textu se budeme zabývat Google Tag Managerem . Kromě GTM existují i další správci, například Adobe Experience Platform, IBM Digital Data Exchange, Ensighten, Salesforce Data Management nebo Tealium. Několik základních pojmů Pojďme si na začátek vysvětlit pár pojmů, se kterými se můžeme v GTM potkat. Záměrně uvádím anglický i český název: Tag - Předdefinovaný či vlastní kus kódu, který se provede při splnění nějakého pravidla. Trigger - Značky spouštíme nad nějakými pravidly. Ty mohou velmi připomínat javascriptové eventy . Variables - Naše proměnné v rámci GTM kontejneru dataLayer - Definovaná datová vrstva, do které můžeme pomocí funkce dataLayer.push vkládat data. Kontejner - V něm máme všechny ty značky, pravidla a proměnné. Celý kontejner můžeme exportovat nebo importovat a pracujeme s ním jako s balíkem informací. Workspace - V řeči vývojářů by kontejner byl takový Git repozitář a workspace pak byla větev. Workspace je dobrá věc pro práci v týmu. Publikace - Vytvoření verze a nasazení - takový merge request a deploy. GTM spravuje značky, ale nic neměří Než se pustíme do vkládání GTM na web, je nutné si říct, že Google Analytics != GTM. Analytics jsou dostupné v GTM jako předdefinovaná značka. Můžete tedy použít GA mimo GTM, nebo GA v rámci GTM. Spuštění měření při tahání GA v rámci GTM může být pomalejší, ale rozdíl asi nepoznáte. Obrázek: Schéma vztahu sebu, datové vrstvy, Google Tag Managera a jednotlivých značek. GTM centralizuje správu dat o používání stránky. Pokud jen pomocí Analytics měříme počty návštěvníků a v GTM nemáme nic dalšího, je to zbytečný kód navíc. Pokud ale budeme do GA posílat události a v GTM mít více značek - tadá, tady to dává smysl! Jak vložím GTM na svůj web Na stránce tagmanager.google.com použiji nebo si vytvořím účet a pod účtem si vytvořím kontejner. Související Google Analytics: jak přidat web Google Analytics: pro vývojáře Google Search Console Po jeho pojmenování a vybrání, že jde o webovou stránku, mi GTM ukáže i samotné nastavení na webu. Jde o 2 kódy, první je javascriptový a ten vkládám do hlavičky webu, druhý je ve značce a slouží pro případy, kdy návštěvník má z nějakého důvodu vypnutý JavaScript. Takhle vypadá kód pro instalaci GTM do stránky. Ani po vložení se ale ještě nic neměří. Mohlo by se zdát, že už máte svoje GTM na webu, ale soubor gtm.js se vygeneruje až poté, co ve svém GTM odešlete první verzi svého kontejneru. Může být prázdný, ale musíte ho odeslat. Do té doby vložený script vrací chybu 404. Výhody GTM Co nám jako vývojářům tedy GTM může přinést za výhody? Pojďme se na některé z nich podívat: Centralizace dat Díky datové vrstvě si můžete sjednotit všechny marketingové nástroje na jedno místo - do GTM. Nestane se, že váš markeťák nebude tušit, který ty kousky kódu potřebuje a které ne. A hlavně - neděláte si nepořádek v kódu marketingovými scripty. Rychlá změna kódu Potřebujete rychle přidat kus JS kódu tak, aby se dostal ke všem? Ideální situace, v GTM máte za minutku hotovo. Rozhodně to není trvalé řešení, tak na to prosím myslete. Částečná automatizace procesů Tohle „rychlo-přidání“ kódu můžete využít i pro automatizaci. Máte třeba levnější tarif Hotjaru? Nevadí, nastavte si spuštění jen první 2 dny v měsíci. Nasadili jste novou věc a chcete vědět, zda funguje? Tadá! Stačí v GTM kliknout a až zjistíte, jak se věci mají, zase to vypnete. Ušetření práce vývojářů A když už máte dataLayer - markeťáci a designéři netrápí vývojáře nasazením každého nového trackovacího nástroje. Stačí jej přidat v GTM a druhý den můžete sbírat data. Jenže tady přichází ta věc… Sdílená zodpovědnost Už asi chápete, že GTM nemůžeme nazvat marketingovým nástrojem – přeci jen většinu věcí dělá JavaScript a který markeťák ho umí? Ale taky ho nemůžeme nazvat frontenďáckým nástrojem – mnoho frontenďáků například netuší k čemu je nutné na webu mít Facebook Pixel. Takže zodpovědnost je zde sdílená: Frontend zodpovídá za to, že všechny ty kódy správně fungují, nic nerozbijí a spouští se ve chvíli, kdy jsou potřeba. Marketing by si měl ohlídat, zda mu do GA apod. nástrojů chodí správné data a správu těchto dat dlouhodobě obstarat. No a pokud je na jedné z obou stran problém, například s rychlostí, musíte ho řešit týmově. Ono to totiž, a teď se obracím na markeťáky, není o kopírování kódů do značek. A frontenďáci - pro vás zase GTM nemá být magie. Vaším cílem je mít web rychlý, funkční a měřitelný. U GTM je dobré vzájemně komunikovat a být spolu v kontaktu. Jasně, je těžké někomu vysvětlit, že jQuery na webu fakt nemáte, ale jako frontenďák taky asi netušíte, k čemu jsou transakce v Analytics… Značky Zopakujme, že značka je kód, který GTM provádí. Abychom si to zjednodušili, pojďme si rozdělit značky podle možných autorů: Předdefinované od Googlu - ty jsou zcela bezpečné. Značky třetích stran - Google je schvaluje a zdrojové kódy jsou veřejně dostupné, ale myslete na to, že: „Google žádným způsobem nezaručuje funkčnost, kvalitu a obsah služeb a aplikací zajišťovaných těmito šablonami.“ abychom citovali z nápovědy. Vlastní značky - ať už kus HTML kódu, obrázek nebo vlastní šablonu. Využití značek už tu zaznělo - většinou jde o marketingový nástroj nebo kus javascriptového kódu. Ty mohou spouštět nahrávání obrazovky, chaty nebo třeba Sentry. Takto vypadají značky v Google Tag Manageru. Kdy se ty značky ale spouštějí? Spouštění - triggery Této části asi na první dobrou neporozumí markeťák, ale frontenďák už určitě tuší, že si budeme hrát s tím, kdy kterou věc spustíme. Důležitá otázka: Kdy tu značku sakra zapnout? Pokud se bavíme o značkách, které chceme spustit na každé stránce, máme 3 možnosti: Zobrazení Model DOM je připraven Okno načteno Události nastávají přesně v tomto pořadí. Asi tušíte kdy přesně, ale radši si to ještě projděme. Zobrazení nastane ihned, jak je GTM funkční. Vhodné to tedy je pro analytické nástroje jako GA. DOM Ready využijete pro scripty, které potřebují už celý DOM a není je potřeba spouštět co nejdříve. Okno načteno je vnitřní událost, která se spouští až ve chvíli, kdy se přestane nějaký obsah stahovat. Ideální pro nějaké chaty a další blokující nekritický JS. Mimo tyto eventy můžete používat také události na kliknutí, odeslání formuláře, posun stránky, viditelnost prvku apod. Vlastní kapitolou jsou pak vlastní eventy, které se posílají přes dataLayer. Můžete si tak například do datové vrstvy poslat událost „prohlédnutí obrázku“ a v GTM ho nějaký způsobem zpracovat do analytických nástrojů. Pravidla – kdy se spouští která značka? Datová vrstva, dataLayer Už jsem tu mnohokrát zmínil pojem dataLayer. Jeho dokumentaci pro GA4 případně pro Universal Analytics je dobré si pročíst. Ve zkratce se jedná o vrstvu, do které posíláte data. Co uživatel viděl, kam kliknul, co si vložil do košíku… Následně můžete tyto data dále v rámci GTM uložit do GA a dalších analytických nástrojů. Tzv. „push“, kterým se toto ukládání děje, potom může například na na detailu produktu e-shopu vypadat takto: dataLayer.push ; Vysvětlíme si to: event - jakou událost v GTM spouštíme. view_item - předdefinovaná událost pro měření prohlížení produktů . ecommerce - data pro ecommerce vrstvu. items - předdefinovaná struktura dat pro GTM. V takovémto kódu může samozřejmě vznikat leckerý problém, který ovlivní rychlost webu. GTM a rychlost Může být web rychlý i s GTM? Ano, jde to. Jde jen o to, co si do Tag Managera dáte, jak si ho budete hlídat a jak se o něj budete starat. Můžeme si říct pár základních pouček: Vypínejte značky, které nepoužíváte - nenechávejte zapnutý např. Hotjar, pokud uživatele aktivně nesledujete. Nastavte správné spouštění značek - jak jsem psal výše: myslete na to, kdy se která značka má spustit. Ne všechno potřebujete spouštět hned - i když ten spouštěč s názvem „Zobrazení“ zní tak krásně… Vybírejte značky podle reálný dopadů. Není totiž chat jako chat. Dobře a kvalitně měřte aplikace třetích stran, případně webu jako celku. Jednoduše pak zjistíte, co přesně web z ničeho nic zpomalilo. Když už manažer značek může rozbít rychlost, nemůže rozbít také něco jiného…? Bezpečnost a GTM Na závěr jedna důležitá, ale zároveň ignorovaná věc. Bezpečnost. GTM vám možná už i jako vývojářům teď zní jako super nástroj. Dejte si ale pozor, kdo k němu má přístup. Ona totiž vlastní značka s kódem… …udělá přesně to, co si myslíte. Ano, asi toto nenastane, ale krásně to vypovídá o tom, jak moc opatrní u udělování přístupů musíte být. A taky jak moc je důležité, abyste se jako vývojáři o manažery značek zajímali a sledovali je. Pokud dáte přístup správným lidem, předdefinovaným i komunitním značkám můžete věřit. Google jejich bezpečnost řeší a upozorní i na to, k čemu mají značky přístup, takže se snad můžeme spolehnout, že se v průběhu času nezmění na tajného sledovače našich uživatelů. Závěrem Jak už jsem napsal, GTM je dobrý sluha, ale zlý pán. V rukou jen markeťáka, nebo jen frontenďáka může být nebezpečný. V rukou obou těchto oborů to může být skvělý nástroj, který vám ušetří spoustu nervů. O GTM by se toho dalo napsat ještě spoustu dalšího. Například jak na vlastní šablony značek, jak na práci s proměnnými, verzování a workspaces… Pokud vás zajímá více, přihlaste na naši marketingo-frontendovou sérii webinářů o GTM na gtmskoleni.cz.
07.04.2021 09:33 V květnu letošního roku proběhne ve vyhledávání Googlu aktualizace zvaná Page Experience, kde mají nový význam ukazatele uživatelského prožitku, včetně metrik rychlosti webu zvaných Core Web Vitals. Podle všech vyjádření z Googlu, které jsem měl možnost číst, nepůjde o velký revoluční posun a pokud nemáte obzvlášť pomalý web, asi se nemusíte bát. V každém případě se ale mít rychlý web vyplatí. Důvody jsem kdysi sepisoval na blogu, ale detailněji také na PageSpeed.cz. Kromě možných výhod ve vyhledávání k nim patří vliv na obchodní výkonnost webu, včetně konverzního poměru. → Toto je rozšířená verze textu, který vyšel v newsletteru ze Vzhůru dolů. V následujícím seznamu tipů jak zrychlit web nemám ambici být obsahově vyčerpávající. Spíše připomínám metody, které jsou relativně nové, které se mi osvědčily při práci pro klienty, a o kterých jsem psal na Vzhůru dolů. Dobře měřte Metriky? Sledujte hlavně Core Web Vitals Lazy loading dejte skoro všude Nepoužívejte CDN pro kritické zdroje Preconnect pro kritické zdroje Preloadujte, ale šetřete s tím Využijte nové formáty obrázků: AVIF, WebP Držte layout Předpokládám, že základy znáte. Že zmenšujete datový objem, snižujete počet requestů, máte nasazené HTTP/2 a neděláte moc velké blbosti. Pojďme už na ten seznam. 1) Dobře měřte Nezapomeňte, že skóre nástroje Lighthouse neudává rychlost webu. Jen zhruba indikuje, kolik problémů na webu máte. V různých oborech vrací různá čísla a většinou nedává smysl usilovat o stoprocentní hodnocení. Lighthouse Performance Score je užitečný ukazatel, když víte, jak jej číst. V opačném případě je to jedna velká kulatá past. Dívejte se na jednotlivé metriky a snažte se je vylepšit, zejména ty důležité – Largest Contentful Paint a Total Blocking Time se podílejí na polovině celkového skóre. Lighthouse Performance Score je fajn, ale důležitější je vidět jednotlivé metriky a filmový pás vykreslování. I to však Lighthouse nebo PageSpeed Insights nabízejí. Když už používáte tyto jednoduché nástroje, dívejte se na data od uživatelů z Chrome UX Reportu. „Data pole“, metriky přímo od uživatelů Chrome pro konkrétní stránku a jejich shrnutí pro celou doménu – v „Origin Summary“. Rychlost webu je vždy nutné posuzovat v širším kontextu a ten vám jednorázový test neukáže. Náš nástroj pro měření rychlosti webu – PageSpeed.cz vám k už uvedenému přidá pohled na vývoj v čase: Porovnání rychlosti úvodních stránek prodejců elektroniky, konkrétně vývoj Lighthouse skóre v čase. Čím je v grafu vyšší, tím lépe. Zdroj: Test na PageSpeed.cz Pro vývojáře je pak podstatné umět používat DevTools v prohlížeči, protože žádný checklist, žádný článek vám nevyřeší konkrétní problémy na konkrétní stránce. Jednomu z největších omylů kolem #RychlostWebu říkám „checklistová optimalizace“.Práce podle kontrolních seznamů je důležitá, ale velké posuny skoro nikdy neudělá. Pro dobré optimalizace potřebujeme chirurgicky přesně najít problémy. A taky vymyslet jejich efektivní řešení.— Martin Michálek February 19, 2021 Vývojáři a vývojářky, naučte se používat Chrome DevTools, zejména nástroje Performance, Network a Lighthouse, naučte se tam číst, co brzdí rychlost vašeho webu, co ovlivňuje konkrétní metriky. → Tip: Záznam z webináře Ladíme rychlost v Chrome DevTools. 2) Metriky? Sledujte hlavně Core Web Vitals Metrik rychlosti je opravu hodně, pro různé projekty a různé účely se hodí různé ukazatele. Postupný vznik událostí při vykreslování stránky. Raději než na Lighthouse skóre se v prvé řadě se zaměřte na Core Web Vitals získané od uživatelů – alespoň z Chrome UX Reportu. Ony totiž určují, jak si povedete v signálech Page Experience v Googlu. LCP – největší vykreslení obsahu. Asi nejdůležitější metrika, protože udává rychlost načtení. Mám o ní také video. FID – první nečinnost procesoru, tedy zhruba jak moc máte pokažený javascriptový kód. Obvykle je na webech v pořádku, protože v rámci Core Web Vitals je nastavená málo přísně. V syntetických měřeních sledujte TBT. CLS – kumulativní posun layoutu. Nová a poněkud zmatená a matoucí metrika. I o ní jsem natočil hodinové video. Jednotlivé metriky Web Vitals a jejich doporučené hodnoty. Teď, když jsme se naučili základně měřit a sledovat správné metriky, můžeme přistoupit k technickým metodám, které nám v posledních letech rozšířily kufřík s optimalizačním nářadím. → Tip: Záznam z webináře Jak správně měřit rychlost webu?. 3) Lazy loading dejte skoro všude Líné načtení pro nebo opravdu pomůže. Sníží datový objem stránky, vylepší prioritizaci zdrojů. Odložené načtení ušetří to data a může zrychlit vykreslení stránky. Je to dostupné už skoro ve všech prohlížečích, takže stačí přidat atribut loading: Je to možné nastavit i pro vkládané rámce: Zatím to nepodporuje Safari, ale tam nic použitím nativního líného načtení nerozbijete. A v moderních prohlížečích by byla škoda použít javascriptovou knihovnu k něčemu, co prohlížeče zvládají samy. Líně ale nenačítejte zdroje důležité pro první viewport a už vůbec ne elementy, které jsou označené jako „LCP prvky“. → Tip: O líném načtení mám hodinový webinář. 4) Nepoužívejte CDN pro kritické zdroje Díky přechodu Chrome na partitioned cache, přestaly CDN dávat smysl pro sdílení zdrojů mezi weby. Jak to bylo dříve a jak je to teď. Schéma partitioned cache v prohlížečích. CDN může být v mnoha případech užitečná, například pro distribuci obsahu do různých koutů světa. Pokud tedy máte zahraniční projekt. Ovšem vzhledem k výše uvedenému ale nedává velký smysl stahovat z CDN zdroje webu kritické pro první vykreslení obsahu , jako například tento: https://cdn.jquery.com/jquery.latest.js 5) Preconnect pro kritické zdroje Včasné připojení pomocí může stránku urychlit, pokud už jsou kritické zdroje uložené na jiných doménách. Nepoužívejte to ale na všechny domény, kde jsou uložené zdroje stránky, jen pro zdroje kritické pro vykreslení první obrazovky. Například u analytiky to většinou smysl nedává. Tohle vypadá fajn, ale je to zjednodušené. V rámci „navázání spojení“ prohlížeč dělá tři úkony: DNS lookup, TCP handshake, vyhodnocení TLS . 6) Preloadujte, ale šetřete s tím může opravdu hodně pomoci, hlavně s metrikou LCP. Jenže zpravidla řeší problém, který vznikl špatným nakódovaním stránky. Přednačíst můžete například řezy fontů podstatné pro vykreslení LCP prvku: Ale může to přinést problémy nové. Daleko lepší je přirozeně optimalizovat frontu stahování a spouštění prvků ve stránce, například odložením načtení zdrojů, které nejsou kritické. Přemýšlejte, než přednačtení nasadíte. Je to hack a může to být past. → Tip: O preload mluvím na videu z webináře o metrice LCP. 7) Využijte nové formáty obrázků: WebP a AVIF Formát WebP už můžeme používat ve všech moderních prohlížečích. Jděte do toho. Nejsnadnější způsob nasazení je pomocí značky : Experimentujte také s famózně úsporným AVIF, který ještě ale nemá tak širokou podporu v prohlížečích. AVIF překonal nejen JPEG, ale i WebP a to v každém jednotlivém obrázku. Zdroj Daniel Aleksandersen, Ctrl.blog. Pokud vám metrika LCP ukazuje na obrázky, převodem do WebP, případně do AVIF si můžete hodně pomoci. → Tip: O obrázcích máme video „WebP, AVIF nebo JPEG?“. 8) Držte layout Optimalizace pro metriku Cumulative Layout Shift vyžaduje, abyste asynchronním prvkům jako jsou obrázky nebo externí zdroje drželi prostor v rozvržení. Stahovaný obrázek rozbije layout stránky raz dva. U obrázků je to už poměrně snadné. Prostě vždy vyplňte atributy width a height u značky : Jinde pomůže nová metoda s funkcí aspect-ratio nebo starší triky. → Tip: O metrice CLS mám také video z webináře a lidé říkají, že je bezva. Kam dál? Hledáte ještě další tipy? Na blogu PageSpeed.cz jsme vydali checklist pro optimalizaci rychlosti webu. Je k dispozici jako stránka nebo PDF a obsahuje opravdu, ale opravdu hodně tipů. Sledujte Twitter: @pagespeedcz nebo si na PageSpeed.cz udělejte test rychlosti webu a my vám jednou měsíčně pošleme vaše aktuální čísla a tipy na tři nejdůležitější články. Seznam možností jak zrychlit web je teoreticky nekonečný. Tento seznam proto publikuji s vědomím, že zde najdete jen ty nejdůležitější body, které jsem v posledním roce v klientské praxi řešíval. Budu jej ale průběžně rozšiřovat, takže tipy v komentářích nebo diskuzi nad uvedenými tématy opět vítám. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
03.04.2021 05:30 Container Queries jsou něco jako Media Queries, jen pro konkrétní komponenty, nikoliv pro celou stránku. Jde o něco, co samozřejmě v CSS chceme a při vývoji webů opravdu hodně potřebujeme. Webdesign je totiž stále více o komponentách, nikoliv o stránkách. Container Queries přistály v Chrome Canary. Je fakt mazec, jak jde ten vývoj rychle.https://t.co/pLFKHnBs55— Martin Michálek April 1, 2021 Před lety to ale ještě nevypadalo dobře. Provázely to různé problémy a hlášení o „nemožné implementaci“. Napsal jsem o tom podrobný článek na blog a prohlásil, že to asi nikdy nedostaneme. Jsem rád, že jsem se spletl. Po letech vývoje do Chromia přichází experimentální implementace, která by toto dovolovala. Vezměme tuto krátkou ukázku: main, aside .media-object @container } Stručně vysvětlíme: Vlastnost contain s hodnotou size tvoří zapouzdří prvek do samostatné jednotky, která zde poslouží jako rodič pro container query. Klíčové slovo @container je jako @media, jen necílí na šířku viewportu, ale šířku rodiče. Jak to otestovat? Potřebujete Chromium 91.0.4459.0 . Jděte do vlaječkového nastavení: chrome://flags. Povolte možnost „Enable CSS Container Queries”. Demo: Bram.us: https://cdpn.io/bramus/debug/LYxNpeE Una Kravets: https://codepen.io/una/pen/LYbvKpK?editors=1100 Více informací: Bram.us: Container Queries are coming to Chromium! Piccalil.li: Container Queries are actually coming Jen prosím pozor, implementace je označena jako experimentální a zatím ani není potvrzená od CSS Working Group ze standardizační organizace W3C. Od možnosti takové věci používat jsme ještě pořád daleko. Ale vypadá to velice nadějně! Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
