Aktualizace komponent a WordPressu je v principu poměrně jednoduchá věc, ale na pár problémů po nich určitě narazíte. Třeba v případě Elementoru. A hlavní roli hraje cache.
Jak zjistit datum, kdy proběhla poslední automatická aktualizace
Samotný WordPress tyto informace neukládá, ale to bychom museli být zklamaní také z absence mnoha jiných funkcí, které nemá. Prostě je to úkol pluginů. Dobré zkušenosti mám s pluginem Activity Log, který ukládá všechny změny uvnitř systému. Pokud tedy kdokoliv změní cokoliv v systému nebo provede jinou akci, jako například přihlášení, vše se uloží do logů a lze to později vyhledat podle různých kritérií.
Z logiky věci ale tento plugin neumí zachytit změny, které někdo provede přímo na serveru nebo na ftp. Tyto změny v souborovém systému dokáže svým skenem zachytit bezpečnostní plugin jako například Wordfence. Ale samozřejmě nepozná, kdo změnu provedl, jen ví, že změna proběhla.
Poslední aktualizace lze tedy v archivu logu najít vyfiltrováním podle uživatelské role (admin) a a aktualizace jádra (core). Kromě toho WordPress samotný posílá e-maily o tom, že proběhly aktualizace jádra nebo pluginu. Jádro, tedy samotný WordPress, je aktualizováno v případě bezpečnostních záplat automaticky.
Po aktualizaci Elementoru se nenačítá editor
Když aktualizujete Elementor a vydáte se upravovat článek, docela často uvidíte pouze bílou obrazovku. Někdy vám Elementor nabídne ladicí režim, ale potvrdilo se mi, že je to zbytečný krok. Řešení je jednodušší: ve většině případů stačí vyprázdnit cache prohlížeče. Elementor je totiž aplikace napsaná v JavaScriptu, tudíž běží přímo v prohlížeči. Pokud plugin aktualizujete, je potřeba se ujistit, že také v prohlížeči je jeho aktuální verze. Ono by se to mělo stát automaticky, ale jednak to chvilku trvá, a jednak to trvá moc dlouho. 🙂 Proto je lepší cache vyprázdnit ručně – a hlavně o tom poučit uživatele.
Podotýkám, že se nebavíme o „historii prohlížeče“ nebo vyplněných formulářích, nýbrž o skriptech, stylech a obrázcích, které má prohlížeč z navštívených webů uložené. Není to položka Vymazat údaje o prohlížení nebo podobná.
Zobrazte si pomocí F12 DevTools a zde na kartě Network zatrhněte Disable cache. Stránku několikrát načtěte a možná se podivíte, co se změnilo. 🙂 tato volba je aktivní, pouze pokud máte otevřené DevTools.
Na webu je jiný obsah než v Elementoru
Prozradím to rovnou: cache. Pokud intenzivně editujete článek v Elementoru a používáte přitom třeba i CSS, tak se může stát, že výsledek, tedy frontend, vypadá jinak než v editoru nebo je takzvaně rozbitý. Příčinou bývá nekonzistence cache, kterou Elementor používá. Pravděpodobně máte nastavenou cache do souborů. Pokud intenzivně pracujete s editorem, soubory se nestačí korektně přegenerovávat a cachuje také samotný prohlížeč. Proto jednou za čas dojde k nekonzistenci a chvíli trvá, než se stav srovná.
Řešení jsou dvě:
- Nastavte, aby během vaší práce Elementor používal inline styly a nevytvářel soubory na disku. Ty nastavte, až budete s prací hotoví, protože jejich používání bude rychlejší.
- Druhá možnost je ručně tyto soubory smazat a nechat je znovu vytvořit. Elementor na to má příkaz v sekci Nástroje (ale budete to dělat opakovaně).
Proč stránky nesplňují core web vitals
Samozřejmě, že nejsem vševědoucí a ani nemám skleněné koule. 😎 Ale poměrně často vidím pomalé weby. A příčina pomalého načítání se také často opakuje: velký obrázek na začátku stránky, případně video. Toto bývá příčina nesplnění core web vitals, zejména LCP, a také příčina celkově pomalého načítání stránky.
Donedávna to byl Elementor, který vytvářel příliš složitý DOM a přesně tyto prvky načítání stránky brzdily. Ale on se fakt zlepšil! Zavedli totiž použití display modelu flex a ten nepotřebuje ty nekonečné kontejnery, řádky a sloupce.
Ale v principu se to týká každého vizuálního editoru a vlastně i nevhodně napsané šablony. Metrika Googlu je taková, že pokud je hero image velký a rozměrný, velmi často porušuje některý z core web vitals. Lékem na to mohou být některé z následujících zásahů:
- Uvedení rozměrů pro obrázek. Pokud nejsou uvedeny, prohlížeč je nezná včas a až je zjistí, musí celou stránku překreslit. Obsah pak poskakuje a vyskočí vám vysoké hodnoty u CLS.
- Přednačtení obrázků, a to nikoliv pomocí CSS, ale parametrem pro prioritu, který zpracuje prohlížeč.
- Optimalizovaný obrázek, který se načítá postupně a zobrazí se nejprve v nižší kvalitě. Tím se zabrání poskakování obsahu, protože rozměr obrázku je známý velmi rychle. Optimalizace obrázků pro web vám taky pomůže.
- Pokud se nejedná o obrázek, ale jiný obsah, například přehrávač videa nebo mapu, vstupují nám do toho ještě ne/schválené cookies. I z toho důvodu je lepší používat placeholder neboli zástupný obrázek.
- Další bloky, třeba slider, už jsou poměrně výzvou a nelze k nim dát univerzální radu. Je vhodné data načítat později, ale rozměry bloků znát co nejdříve.
