Kdy použít a nepoužívat ETag
Právě jsem se díval na naše stránky na WebPageTest.org a jedním z jejich doporučení pro zrychlení webu je:
Záhlaví ETag by se obecně neměla používat, pokud nemáte výslovný důvod, proč je potřebujete
Přemýšlel jsem, co to znamená. Znamená to, že statický obsah, o kterém víte, že se nezmění, by ho neměl mít, nebo to znamená, že obsah, o kterém víte, že se bude pravidelně měnit, by ho neměl mít, nebo to znamená, že byste jej neměli používat obecně , pokud nemáte konkrétní potřebu.
Pokud je to ten druhý, kdy je ten pravý čas je použít? Díky za pomoc.
ETag jsou alternativou k (ale mohou být použity v kombinaci s) „Last-Modified-Time“, aby se určilo ověření mezipaměti.
Klient může na základě ETag odeslat předběžnou podmínku, jako jsou if-zápasy nebo if-none-zápasy. Nejde jen o požadavky GET (což je to, co webpagetest.org dělá), můžete použít „příležitostnou aktualizaci“, takže požadavek PUT má předběžnou podmínku a nebude provádět aktualizaci, pokud byl zdroj aktualizován od doby, kdy byl ETag naposledy získané.
Jednoduše řečeno: kliknete na úpravy na stránce v CMS, váš přítel zasáhne úpravy na stránce v CMS, váš přítel provede jejich úpravy a zásahy se uloží a nakonec stisknete uložit - bez záhlaví HTTP ETag nebo Content-MD5, které byste potřebovali Aby se zabránilo objevování problémů (jako je stírání přes změny přátel), řešení je již součástí protokolu HTTP, a proto má smysl jej pouze používat.
Obecně souhlasím s AOL (který provozuje webpagetest.org) s jejich radou „jedna velikost padne všem“ - je lepší nezatahovat záhlaví HTTP kryptickými řetězci (ETags obecně nejsou hezké nebo lidské čitelné), když je sekunda rozdílu ( který dokáže detekovat Last-Modified-Time) pro danou úlohu.
Pokud je stránka aktualizována několikrát za sekundu a absolutně potřebujete k zobrazení nejnovější nejpřesnější verzi, možná budete chtít experimentovat s jinými řešeními než HTTP GET nebo použít pouze ETagy.
Dávejte pozor, aby vaše ETagy neobsahovaly informace o souborovém systému, o změně konfigurace serveru atd. (Např. Inodes, které je v Apache výchozí), jinak budete mít problémy, pokud existují dva servery (ETagy z každého se neshodují).
Chcete-li parafrázovat vynikající kódování Hororu vyhodnocení pluginu YSlow Firebug (což se zdá, WebPageTest.org používá jako základ pro jejich hodnocení):
"Yahoo je jedním z nejrušnějších webových stránek na světě - jeho problémy pravděpodobně nejsou vaše problémy."
Pokud se ve vaší síti s vyrovnáváním zatížení každý den nezabýváte miliony unikátů, existuje velká šance, že poskytnuté návrhy nejsou v pořádku při optimalizaci webu.