Když mám WP uvodní stránku nastavenou jako výpis příspěvků, tak ji nikde tu stránku nevidím abych na ní mohludělat SEO (hlavně asi description) kde se to ovládat ? Dá se to vůbec ? (mam Yoast) a nebo musim rucne pro celý web ?

btw ja snad vsechno provozuju s superpwa pluginem takze to bezi komplet na http2 pres serviceworkera, resp ty klienti co to podporuji.. no.. btw je to dulezity, cim min requestu, tim rychlejsi odbaveni, tim mensi zatez, tim vice pameti, tim vice klientu, vice stejnych requestu, vetsi vyuziti cache.. ono se to posklada a rozdil v kapacite serveru byva radove jinde.. btw takhle to vypada v admin z pohledu "tam se nic necachuje"..

MRTVY_KENNY: jej to je odpoved na otazku :))
no, primo ve w3tc jsou ukazkovy implementace pro pluginy a pro jejich admistrativni cast, tedy ono se i na backendu cachuje, jen ne v tech oblastech kde to muze vadit.. jsem linej to hloubeji hledat, nicmene vidim ze mi memcache i redis tika kdyz hejbu jen v adminu..

THEODORT: ja to chapu tak, ze v adminu se nic necachuje. ale tim, ze ulevis serveru dik zapnute cachi na frontendu, muzes pocitit zrychleni i na backendu, pokud mas velke mnozstvi navstevniku

W3 Total Cache – Plugin WordPressu | WordPress.org Česko
https://cs.wordpress.org/plugins/w3-total-cache/#will%20this%20plugin%20speed%20up%20wp%20admin%3F

jenze kdyz ten caching jede i v administracni casti, ono 99% requestu do db je na nejaky zbytecnosti jako jestli mas mit listu schovanou nebo ne..

MRTVY_KENNY: nevim jestli je to pro tebe uzitecna informace, ale ja nedavno resil presne to samy. WC shop, nijak preplacenej, ani moc objednavek/produktu, frontend sviznej, ale backend trval desitky vterin kazdej klik. zkousel jsem vypinat/zapinat, profilovat, nic nepomohlo.

bylo to na WP Enginu, napsal jsem na support, nejdriv se cukali, pak uznali ze je chyba u nich na serveru, presunuli me nekam jinam a zacalo se to chovat normalne.

THEODORT: a "navazis se"... mi je forpsi opravdu uplne volne. jestli si myslis, ze se mi chtelo plytvat casem na to, ze budu klientovi testovat a migrovat eshop, tak fakt mam jine prace dost.

oni meli problem (shodnem se, ze pri kliku na tabulku objednavek je odezva 11s problem?), ja se snazil to zkonzultovat se supportem, ten prakticky navrhl, ze si mam vypnout zabezpeceni, zalohy atd. (shodnem se, ze toto je presny opak good practices pro WP?) a tudiz jsem bez jakekoliv upravy web premigroval na jiny server a jede to ok.

ale jestli je to navazeni, tak se navazim.

THEODORT: nerozumime si.
me nezajima caching pro nakupujici, tam ten web jede samozrejme dobre dik cachovacimu pluginu. me zajima performance administrace, na kterou tyhle cache pluginy nemaji vliv, anebo neco nevim.

skara, spatnej link :)
The Importance of Caching in WordPress
https://themeisle.com/blog/caching-in-wordpress/

namatkou sauce https://www.keycdn.com/support/setting-up-woocommerce-cache

btw jinak ted nejakej ten hosting kterej jsem mel moznost otukat mel RTT na db server pres 4s.. takova americka tragedie nebo jak to nazvat, osobne abych jim nekrivdil jsem si pro sebe rekl ze to treba bylo zrovna limitovany kvuli vytizeni serveru, dvakrat to kontrolovat nehodlam.. dlouho jsem db pristupy wp nemeril ale bez cache to fakt nelze rozumne provozovat pod zatezi vice nez jednotek lidi za minutu jakmile to trosku preroste pres par zakladnich stranek..

MRTVY_KENNY:jo tos mel napsat zes tam chtel provozovat woocommerce. tam se zrovna doporucuje mit db cache zaplou za veskerych okolnosti a vypinani cache pro prihlaseny odskrtnout, urcite si to nekde najdes. btw v konfiguraci tam jsou retezce ktery se tabulkam co se tykaj woocommerce zamerne vyhybaji tak aby i pres cachovani web daval stale aktualni vysledky.

jako tohle me trosku nasralo kdyz si vezmu ze kvuli tomuhle se navazis do hostingu kterej za nic nemuze.

THEODORT: no, ale ja resim admina, tam zadny cache plugin predpokladam nedela nic..
= muj problem byl, ze clovek na cokoliv v adminu cekal cca 11s. s tim se neda pracovat (500 produktu, cca 10obj/den)

(resp. w3tc jeste dela par veci mimo .htacces, treba jejich reseni lazy-load je pomerne inspirativni, a naopak ukladani transients pro page cache do databaze pomerne odstrasujici..)

hele ono to je fakt kus od kusu, tim ze jste "na hostingu" - ted nebudu stourat v tom do jake miry do toho vidite, nicmene to lze zjednodusit na kombo disk-pamet-procesor-sit-databaze, a optimalizace vyuziti.
na hostingu se optimalizace bez znalosti praktikuje tezko protoze zpravidla nevidite metriky ktere by se vam k tomu hodily.
u wp to obnasi trebas to ze ruzne kombinace cache vytezuji ruzne ruzne vrstvy, a to serveru muze nekdy i vic ublizit nez pomoct, typicky to je vetsi zatez jiz tak zatizeneho kanalu, tedy snazim se napr. ukladat v databazi data pro cachovani cimz jen vice zpomalim pripojeni k db.. a tak.

jinak namatkou k one nenavidene w3tc davam dva obrazky.. (ja pro advanced users doporucuju vykopirovat si ty upravy co w3tc pouziva pro nastaveni danych cachi ve wp a pak clovek nemusi vubec plejtvat casem s nejakym pluginem, jsou to jen upravy .htaccess)

JOHNBOY: mas nastavene content security policy na hostingu a na svem webu je porusujes

Hlavicka co posila server
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' 'unsafe-inline'; script-src-elem 'self'; style-src 'self' 'unsafe-inline'; style-src-elem 'self' 'unsafe-inline'; report-uri https://igldesign.com/wp-json/rsssl/v1/csp?rsssl_apitoken=1612564540

Jsou nastavene na report = realne ten obsah nezakazou

CYBERWOLF: to bude asi obecný příklad toho, co by mohlo web zpomalovat dle supportu...