Senast ändrade HTTP-huvudet talar om för klienten tiden sista ändring sida (objekt). Om klienten (webbläsare, sökrobot) fick rubriken Last-Modified, och nästa gång adressen öppnas, förutsatt att sidan (objektet) finns i den lokala cachen, kommer den att lägga till en If-Modified-Since-fråga (om sidan har ändrats sedan mottagningsdatumet i Senast ändrad). I sin tur måste servern, efter att ha tagit emot en If-Modified-Since-förfrågan, kontrollera den mottagna tidsstämpeln med den tidpunkt då sidan senast ändrades och, om sidan inte har ändrats, svara med 304 Not Modified.
Om sidan inte har ändrats kommer servern att sluta sända data efter att ha skickat rubriker med koden 304 Ej ändrad, sidans kropp, bilder och andra objekt kommer inte att överföras.
Den korrekta implementeringen av att kontrollera tiden för den senaste ändringen av sidan kan avsevärt (upp till 30% eller mer) minska belastningen på servern. Korrekt implementering innebär att kontrollera tiden innan sidgenereringen startar på en dynamisk webbplats. I det här fallet kommer inte alla åtgärder för att generera sidan (begära innehåll från databasen, tolka mallar, ta emot kommentarer etc.) att utföras. Detta gäller särskilt för webbplatser med hög trafik och lång varaktighet av användarens besök. Exempel: Användaren är på en sportnyhetssajt och uppdaterar ständigt startsida i väntan på publicering av matchresultatet. På några minuter kan en sida begäras och tas emot dussintals gånger. Om rubriken Last-Modified ges och If-Modified-Since-förfrågan behandlas korrekt, kommer sidan faktiskt att skickas en gång, och alla efterföljande förfrågningar kommer att få ett 304 Ej ändrat svar.
Sökmotorer rekommenderar att du skickar rubriken Last-Modified och hanterar If-Modified-Since korrekt genom riktlinjerna för webbansvariga.
Anteckningen: den adaptiva versionen av webbplatsen aktiveras, som automatiskt anpassar sig till din webbläsares lilla storlek och döljer vissa detaljer om webbplatsen för att underlätta läsningen. Njut av att titta!
Hej kära läsare av bloggen Vi fortsätter ämnet, en av de viktigaste SEO-faktorerna. Den här artikeln kommer att beröra vad som kan kallas inveckladheten med intern optimering, eftersom den kommer att fokusera på svarskoden som sökmotorer och besökare kommer att få som svar på deras tillgång till sidan.
Trots att detta är en ganska liten detalj när man bygger och optimerar sajten som helhet är det dock väldigt viktigt! Det är nämligen viktigt att en sida som det inte har skett några förändringar på sedan det senaste besöket av en robot eller en person ger en 304-kod, vilket betyder att sidan har förblivit oförändrad. När servern skickar denna kod till klienten startar inte ens exekveringen av alla PHP-skript på sidan, istället laddas sidan från cachen, vilket avsevärt minskar belastningen på servern och snabbar upp sidladdningen för användaren .
Genom att ställa in de korrekta svaren på vår server slår vi alltså minst fem flugor i en smäll:
Av någon anledning, för mig, verkar den sista punkten vara den sötaste (eftersom den påverkar SEO och ökar trovärdigheten för din webbplats med sökmotorer), även om de andra punkterna utan tvekan också är extremt viktiga.
Vi har redan sagt att som svar på en begäran till oförändrade sidor bör servern återvända 304 Ej modifierad, och vilken kod ska servern returnera om klienten kommer åt sidan för första gången eller kommer åt en sida som har ändrats? I sådana fall bör servern returnera statusen 200 okej. Speciellt given kod det är inte nödvändigt att skicka, om allt är i sin ordning med sidan så ger den alltid ut 200.
Därför behöver vi bara ta hand om 304-koden, eftersom servern inte kommer att skicka den utan vår inblandning. För att göra detta kommer det att hjälpa oss, liksom titeln Senast ändrad och begära.
Senast ändradär rubriken vi skickar med använder PHP, den här rubriken innehåller den exakta tidpunkten då sidan senast ändrades (i sekunder). För att göra detta används det allmänt accepterade måttet på tidsmätning: Unix Time Stamp.
Unix tidsstämpelär antalet sekunder sedan början av Unix-epoken: 1 januari 1970. När detta skrivs är Unix tidsstämpel 1370597447 sekunder, vilket är 06/07/2013 09:30:47 GMT (+00:00).
Det vill säga, allt vi behöver göra är att bara skicka en PHP-header med instruktionen Senast ändrad och önskat datum:
Header("Last-Modified: ".gmdate("D, d M Y H:i:s", $last_modified_time)." GMT");
Där header är en konstruktion för att skicka en HTTP-header, Senast ändrad- vad vi skickar och direkt efter kolon kommer dess värde:
Gmdate("D, d M Y H:i:s", $last_modified_time)." GMT".
Det senast ändrade värdet är funktionen gmdate(), som innehåller variabeln jag uppfann $last_modified_time(man kan kalla det vad som helst). I en variabel $last_modified_time och innehåller tidpunkten för den senaste ändringen i formatet Unix tidsstämpel, och funktionen gmdate() tjänar oss för att få datumet i rätt form (Greenwich Mean Time).
För tydlighetens skull, här är ett exempel för dig: om vi är i en funktion gmdate() sätt värdet 1365003142 , då blir utgången: ons 3 april 2013 15:32:22.
Nu när vi har lärt oss hur hela processen fungerar kan frågan uppstå: "Behöver vi manuellt ange tidpunkten för den senaste ändringen för varje sida?". Svar: "Ja!" Personligen gör jag just det - manuellt, det mest pålitliga alternativet. Men specifikt för den här bloggen gav jag allt, till exempel om ny kommentar på sidan och sedan till en variabel $last_modified_time tiden när denna kommentar lades till registreras, detta görs så att sökmotorer kan indexera nya kommentarer och veta att sajten är "live". Varje sida är annorlunda och du måste komma med din egen algoritm för att ange datumet för den senaste ändringen av sidan, eller alltid ange det manuellt.
Än en gång betonar jag att min algoritm är följande:
1) Jag anger datumet för skapandet av materialet manuellt, om jag ändrar något i artikeln (stavfel eller lägger till), så anger jag manuellt den nya tiden för den senaste uppdateringen.
2) Om besökaren lägger till en kommentar, då i variabeln $last_modified_time automatiskt, utan min vetskap, läggs tiden in när kommentaren lades till, eftersom detta i själva verket kommer att vara det datum då sidan senast ändrades.
Vad jag inte tog hänsyn till: i högerspalten på webbplatsen jag har färska artiklar, rekommenderad Och topp 10. De ändras konstant och samtidigt för alla sidor. Om jag ändrade (automatiskt eller manuellt - det spelar ingen roll) det datum då sidan senast ändrades varje gång jag ändrade den högra kolumnen på webbplatsen, skulle hela poängen med denna åtgärd gå förlorad. Jag bestämde mig för att dessa ändringar skulle spåras och beaktas när de specificerades $last_modified_time inte värt det, eftersom de inte är till någon fördel för SEO.
Som jag skrev kan jag inte berätta exakt hur man automatiserar det senaste ändringsdatumet för en sida, men jag ska berätta hur man INTE gör det!
Det första som kan komma att tänka på för de flesta är att skicka datumet för den senaste ändringen av filen med sidans innehåll i rubriken. Personligen finns mina artikeltexter i filer, inte i en databas, så för mig kan den här metoden tyckas vara en bra väg ut för att inte komma in varje gång Unix tidsstämpel manuellt. Men nej! De flesta värdar, och kanske till och med alla, tar datumet för dess skapande som datumet för den senaste ändringen av filen, de tar inte hänsyn till efterföljande ändringar av den.
Jag tror att du förstår konsekvenserna i sådana fall. En populär ukrainsk värdleverantör (och jag tror att han inte är den enda) i sin FAQ skriver något i stil med: "Istället för datumet för den senaste ändringen av filen, använd funktionen tid(), som returnerar den aktuella tiden i Unix-tidsstämpelformat." Det är så absurt! Det skjuts bara på plats! Och denna värdleverantör anses vara "en av de bästa", efter att jag läst detta ville jag omedelbart inte bli deras kund.
Det är bara anti-SEO, tänk själv, kommer till din sökmotorsida och ser ut: ”Wow! Senaste sidbytet var just nu, så jag gissade när jag skulle komma, klass! Ett par dagar senare kommer han till samma sida: "Titta, det ändrades bara igen, det här är en slump ... Vänta, varför ser jag inga förändringar? Okej, jag kommer tillbaka en annan gång." Han kommer igen: "Nå, nej, killar, det här är inte längre roligt, ni kan definitivt inte lita på." Här är en saga :)
Och sedan undrar folk varför resultaten i sökresultaten inte är som de skulle vilja, utan för att det banala går förlorat för din webbplats förtroende(förtroende). Precis som i liknelsen "Om herden och vargarna".
Så vi räknade ut de största misstagen: du kan inte ange den aktuella tiden och jag rekommenderar dig inte att ange filändringstiden. Låt oss nu fortsätta att förstå hur det hela fungerar.
Ställ in sändningshuvuden Senast ändrad detta är exakt 1/3 av fallet, vi måste fortfarande: svara på begäran och slå på cachelagring av sidan. Båda dessa åtgärder kommer inte att ta mycket tid och rader kod.
är en klientförfrågan till din server, där klienten frågar: "har sidan ändrats sedan mitt senaste besök?". Om sidan inte har ändrats måste vi stoppa utförandet av ytterligare laddning av sidan med kommandot:
Samtidigt bör inte sidans brödtext börja ritas, allt detta händer INNAN den första utmatningen av något på sidan! Tillsammans med detta är det nödvändigt att returnera serversvaret till klienten 304 Ej modifierad, vilket säger att sidan måste tas från cachen. Låt oss gå direkt till saken:
If (isset($_SERVER["HTTP_IF_MODIFIED_SINCE") && strtotime($_SERVER["HTTP_IF_MODIFIED_SINCE"]) >= $last_modified_time)( header("HTTP/1.1 304 Not Modified"); die; ) header("Last-Modified : ".gmdate("D, d M Y H:i:s", $last_modified_time)." GMT");
Så på den första raden kontrollerar vi med hjälp om HTTP_IF_MODIFIED_SINCE-förfrågan kom till vår server, och kontrollerar också omedelbart antalet sekunder i den inkommande HTTP_IF_MODIFIED_SINCE är större än i $last_modified_time eller inte? Om fler, så är datumet för det senaste besöket av klienten senare än datumet för den senaste ändringen av sidan, härifrån drar vi en rent logisk slutsats att sidan inte har ändrats, vilket innebär att vi skickar serversvaret in den andra raden 304 Ej modifierad och rad 3 dödar vi (stoppar) exekveringen av alla skript på sidan. Med andra ord, vi slutar ladda ner det.
Om klienten inte skickade en HTTP_IF_MODIFIED_SINCE-förfrågan till oss eller om hans senaste besök var tidigare än det datum då sidan senast ändrades, returnerar vi (som standard) koden 200 okej och på den femte raden skickar vi honom det FAKTISKA datumet för sidbytet, istället för det han hade.
Om IF_MODIFIED_SINCE och hur koden är ordnad berättade han allt du behöver, förutom vad strtotime ()-funktionen gör:
Strtotime($_SERVER["HTTP_IF_MODIFIED_SINCE"])
En uppmärksam och kunnig läsare kunde redan gissa att den här funktionen omvandlar ett vanligt datum till en Unix-tidsstämpel, eftersom vi ställer in variabeln $last_modified_time i den, och därför, för jämförelse, måste vi föra allt till en gemensam nämnare gemensamt system mätningar.
Och slutligen måste vi bara aktivera cachning, detta görs med hjälp av följande rader:
Header("CacheControl: public"); header("Upphör: ". date("r", tid()+10800));
Där siffran 10800 är tiden (i sekunder) som vi vill cachelagra sidan, det vill säga i detta exempel i 3 timmar.
Och som alltid, för de som inte förstår någonting så lägger jag upp allt i sin helhet, som det är ordnat på min blogg:
= $last_modified_time)( header("HTTP/1.1 304 Not Modified"); die; /* döda allt nedanför */) header("Last-Modified: ".gmdate("D, d M Y H:i:s", $last_modified_time)." GMT"); ?> Och resten av sidan gickJag tror att du kanske har märkt att hela den här historien med Last-modified är en analog till taggen i - . Så lastmod är av bekantskaps- och rådgivande karaktär, och ingen kommer att argumentera med svaren från din server. Naturligtvis är det inte ovanligt att lastmoden i webbplatskartan skiljer sig från LastModified-huvudet, men från och med nu bör de vara samma för dig! Nu har vi trots allt studerat någon form av vetenskap, inte för att bli som olyckliga webbansvariga som inte kommit längre än sitemap.xml.
Personligen är jag med det här ögonblicket Jag använder inte lastmod-taggen alls i mina webbplatskartor, jag kanske ska tänka om senare, men för tillfället ser jag inte poängen med att vara så noggrann med korrekta titlar Senast ändrad :)
Och slutligen, kontrollera korrektheten Senast ändrad och du kan med den här tjänsten: klicka på .
Tack för din uppmärksamhet, och särskilt tack till det ständigt växande antalet prenumeranter, för mig är detta det största incitamentet att skriva oftare på bloggen. Så om du inte har registrerat dig för nya artiklar än, välkommen!
Rubriker Last-Modified och If-Modified-Since för WordPress
Få uppmärksammar HTTP-rubriker Senast ändrad Och Om-Ändrad-Sedan när du optimerar din webbplats, men förgäves! Det är viktigt att sidan, vars innehåll inte har ändrats sedan sökrobotens senaste besök, ger en 304-kod, som faktiskt indikerar att just denna sida inte kompletterats med något - du har inte redigerat eller kompletterat texten, kommentarer lades inte till detta inlägg, etc. P.
Om denna http-rubrik saknas, då i Yandex, när du sorterar resultaten efter datum, kommer webbplatsen inte att vara synlig för de flesta användare.
Därför är det viktigt att du inte bara ställer in det korrekt, utan varje gång du redigerar ett inlägg uppdaterar datumet till det aktuella. Detta kommer att behöva göras manuellt.
Det är enklare med kommentarer: när en besökare lägger till en kommentar, då i en variabel $last_modified_time tidpunkten när kommentaren lades till skrivs in automatiskt - detta kommer att vara det datum då sidan senast ändrades.
1. När servern returnerar sådan kod startas inte ens exekveringen av alla PHP-skript på sidan. Sidan laddas från sökcachen, och detta minskar, som du förstår, belastningen avsevärt på servern till stor glädje för din värd och snabbar upp sidladdningen för besökaren, som inte heller kan annat än att jubla.
Hur går det till?
När du skannar på Internet lagrar Google och Yandex spindlar en kopia av varje webbplats i sin databas. Denna kopia fungerar som en sorts modell för jämförelse: om allt är sig likt eller om det har skett förändringar. Och om rubrikerna Last-Modified och If-Modified-Since inte är konfigurerade eller felaktigt konfigurerade, indexeras nya sidor på webbplatsen och huvudsidan i sökmotorns cache uppdateras inte på länge, precis som kommentarflödet är inte uppdaterad.
Men för ofta uppdaterade sidor ( nyhetsflöden, uppdateras många gånger om dagen, aktivt kommenterade bloggar, etc.) det har en nackdel: informationen i cachen blir för snabbt föråldrad och en person, som till och med laddar om sidan, ser inte de senaste nyheterna, ser inga nya kommentarer. Men det är fortfarande halva besväret. Problemet är att roboten inte ser detta heller, såvida inte rätt Last-Modified header ingår.
header("Last-Modified: ".gmdate("D, d M Y H:i:s ")."GMT");
Om din webbplats uppdateras ofta (till exempel dina inlägg kommenteras ofta) kan du inaktivera cachelagring med följande uppsättning rubriker:
header("Upphör: ".gmdate("D, d M Y H:i:s", tid() + 7200)." GMT");
Detta innebär att giltigheten av den lagrade kopian måste kontrolleras på nytt vid varje begäran.
Om den inte inaktiveras genom att anropa no_cache-funktionen, lagras sidan i Firefox och IE i cachen, och det är sidan som returneras vid alla efterföljande förfrågningar.
För att uppdatera sidan och få den senaste versionen måste du trycka på tangentkombinationen Ctrl+F5, den vanliga uppdateringsknappen (F5) fungerar inte. Och jag måste säga att dokument i IE-cachen kan lagras väldigt, väldigt länge.
I Opera rensas cachesidan genom att trycka på knappen Uppdatera eller trycka på F5. CRTL + F5 i Opera - starta om alla öppna flikar Som du förstår, om du har öppnat många av dem - i väntan kan du växa ett skägg.
Om du inaktiverar sidcache med no_cache-funktionen använder Opera och Firefox en mekanism med rubriken If-Modified-Since när de kommer åt en sådan sida. Således uppstår cachning, men webbläsaren frågar servern om sidan faktiskt har ändrats eller inte - detta är den korrekta frågan.
Därför måste du också ansluta bearbetningen av denna parameter. Jag kommer inte att beskriva vad och vad funktionen betyder, jag kommer helt enkelt att ge koden som korrekt returnerar rubrikerna och inte orsakar konflikter på de flesta hostingar som jag var tvungen att arbeta med. Denna design fungerar för sweb.ru, eomy.net, timeweb.ru, fastvps.ru, startlogic.com
header("Upphör: ".gmdate("D, d M Y H:i:s", tid() + 7200)." GMT");
header("Cache-kontroll: ingen cache, måste omvalideras");
$mt = filtid($filnamn);
$mt_str = gmdate("D, d M Y H:i:s ")."GMT";
if (isset($_SERVER["HTTP_IF_MODIFIED_SINCE") &&
strtotime($_SERVER["HTTP_IF_MODIFIED_SINCE") >= $mt)
(header("HTTP/1.1 304 Inte modifierad");
dö;
}
header("Last-Modified: ".$mt_str);
echo $text;
header("Vary: Acceptera-kodning");
header("Acceptera-Encoding:gzip,deflate,sdch");
?>
Så allt du behöver göra är att kopiera den här koden och lägga till den i filen header.php Ditt tema OVAN . De där. denna kod är högst upp i filen FÖRE resten av koden
Uppmärksamhet! Innan du lägger till något, spara den här filen på din dator så att du kan återställa den ursprungliga versionen om din inte tillåter en sådan rubrikkonfiguration.
Vi kontrollerar resultatet på tjänsten för att kontrollera rubrikerna Last-Modified och If-Modified-Since http://last-modified.com/ru/if-modified-since.html
Voila! Genom att korrekt ställa in rubrikerna Last-Modified och If-Modified-Since fick vi en massa bonusar:
Greenwich Mean Time. HTTP-datum uttrycks alltid i GMT, aldrig i lokal tid.
| Specifikation | Titel |
|---|---|
| RFC 7232, avsnitt 3.3: Om-Ändrad-sedan | Hypertext Transfer Protocol (HTTP/1.1): Villkorliga förfrågningar |
Kompatibilitetstabellen på den här sidan genereras från strukturerad data. Om du vill bidra till datan, kolla in https://github.com/mdn/browser-compat-data och skicka oss en pull-förfrågan.
Uppdatera kompatibilitetsdata på GitHub
| Skrivbord | Mobil | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Krom | kant | Firefox | Internet Explorer | Opera | safari | android webbvy | Chrome för Android | Firefox för Android | Opera för Android | Safari på iOS | Samsung Internet | |
| Om-Ändrad-Sedan | Chrome Fullt stödJa | Edge Fullständigt stöd 12 | Firefox Fullt stöd Ja | IE Fullt stöd Ja | Opera Fullständigt stödJa | Safari Fullt stöd Ja | WebView Android Fullt stöd Ja | Chrome Android Fullt stöd Ja | Firefox Android Fullständigt stödJa | Opera Android Fullt stöd Ja | Safari iOS Fullständigt stöd Ja | Samsung Internet Android Fullt stöd Ja |
Senast modifierade HTTP-huvudet talar om för klienten när sidan (objektet) senast ändrades. Om klienten (webbläsare, sökrobot) fick rubriken Last-Modified, så kommer nästa gång den kommer åt adressen, förutsatt att sidan (objektet) finns i den lokala cachen, lägga till frågan If-Modified-Since (om sidan har ändrats sedan datumet mottogs i Last-Modified). I sin tur måste servern, efter att ha tagit emot en If-Modified-Since-förfrågan, kontrollera den mottagna tidsstämpeln med den tidpunkt då sidan senast ändrades och, om sidan inte har ändrats, svara med 304 Not Modified.
Om sidan inte har ändrats kommer servern att sluta sända data efter att ha skickat rubriker med koden 304 Ej ändrad, sidans kropp, bilder och andra objekt kommer inte att överföras.
Den korrekta implementeringen av att kontrollera tiden för den senaste ändringen av sidan kan avsevärt (upp till 30% eller mer) minska belastningen på servern. Korrekt implementering innebär att kontrollera tiden innan sidgenereringen startar på en dynamisk webbplats. I det här fallet kommer inte alla åtgärder för att generera sidan (begära innehåll från databasen, tolka mallar, ta emot kommentarer etc.) att utföras. Detta gäller särskilt för webbplatser med hög trafik och lång varaktighet av användarens besök. Exempel: En användare är på en sportnyhetssajt och uppdaterar ständigt hemsidan i väntan på att ett matchresultat publiceras. På några minuter kan en sida begäras och tas emot dussintals gånger. Om rubriken Last-Modified ges och If-Modified-Since-förfrågan behandlas korrekt, kommer sidan faktiskt att skickas en gång, och alla efterföljande förfrågningar kommer att få ett 304 Ej ändrat svar.
Sökmotorer rekommenderar att du skickar rubriken Last-Modified och hanterar If-Modified-Since korrekt genom riktlinjerna för webbansvariga.
Se till att din webbserver stöder HTTP-huvudet If-Modified-Since. Den här rubriken låter webbservern tala om för Google om webbplatsens innehåll har ändrats sedan den senaste gången den genomsöktes. Stöd för denna funktion kommer att minska belastningen på genomströmning och kostnader.
Google: Webmaster Guide
Se till att dina HTTP-rubriker är korrekta. I synnerhet är innehållet i svaret som servern ger på begäran om If-Modified-Since viktigt. Rubriken Last-Modified måste returnera det korrekta datumet då dokumentet senast ändrades. Även om servern inte anger datumet för den senaste ändringen av dokumentet (senast ändrad), kommer din webbplats att indexeras. Men i detta fall bör följande beaktas:
- sökresultaten visar inte datumet bredvid sidorna på din webbplats;
- när den sorteras efter datum kommer webbplatsen inte att vara synlig för de flesta användare;
- roboten kommer inte att kunna få information om huruvida webbplatssidan har uppdaterats sedan den senaste indexeringen. Och eftersom antalet sidor som roboten får från sajten vid ett besök är begränsat, kommer ändrade sidor att återindexeras mer sällan.
