CDN-konfiguration låter som en snabb lösning, men felaktiga regler, SSL-handskakningsöverhead och svaga ursprungsresurser kan öka laddningstiden utan att det märks. Jag ska visa dig hur små konfigurationsdetaljer kan skapa stora problem och hur du kan minska dessa problem på ett mätbart och permanent sätt.
Centrala punkter
- Cache-regler avgöra om edge-servrar levererar innehåll eller ständigt belastar Origin.
- SSL/TLS och protokollval ökar antalet tur- och returresor om handskakningar och återanvändning inte passar in.
- Resurser för ursprung och I/O begränsar genomströmningen trots globala kanter.
- DNS/Routing generera latens när anycast och peering är ogynnsamma.
- TTL/spolning kontrollera färskhet, konsistens och belastningstoppar efter förändringar.
Varför CDN:er kan göra dig långsammare
Jag ser ofta att en Kant är särskilt effektivt när det levererar så många objekt som möjligt från en ren cache och endast sällan ställer frågor om ursprunget. Om det inte finns någon tydlig åtskillnad mellan statiska och dynamiska tillgångar genererar CDN otaliga förbikopplingar till Origin och späder ut fördelen. Varje ytterligare DNS-upplösning, varje ny TCP-handskakning och varje missad keep-alive kostar millisekunder. Om datavägen går via avlägsna PoP:er ackumuleras latensen över flera hopp. Användaren märker av dessa summor som långsamhet under startrendering och tid till första byte.
Dolda stötestenar i cache och routing
Fel Cache-kontroll-headers, cookie-inställningar för faktiskt statiska filer eller frågesträngar utan relevans tvingar Edges till origin-fetch. Jag kontrollerar först om cookies, auktoriseringsrubriker eller ändrade frågeparametrar för CSS/JS/bilder verkligen är nödvändiga. Om Vary-reglerna är korrekta ökar träfffrekvensen i cacheminnet märkbart. Om du vill gå djupare kan du ta en titt på några korta exempel HTTP cache-rubrik på. Lika viktigt: routningspolicyer som oavsiktligt styr förfrågningar till överbelastade PoP:er och därmed slösar bort bråkdelar av en sekund. Fördröjning Lägg till.
SSL/TLS: korrekt användning av handskakningar och protokoll
En ytterligare TLS-handskakning kostar två tur- och returresor och multiplicerar den märkbara Fördröjning. Om den enkla RTT:n mellan klient och edge är 95 ms, så lägger en ny handskakning till nästan 200 ms innan den första bytena flödar. Jag förlitar mig på TLS 1.3, återupptagande av sessioner och 0-RTT så att återbesökare inte startar några dyra ombyggnader. HTTP/2 buntar ihop strömmar på en anslutning, HTTP/3/QUIC minskar blockering av huvudlinjen på skakiga nätverk; detta ger mer synliga resultat, särskilt på mobila radiolänkar. Stabilitet i genomströmning utan att använda det förbjudna ordet. Återanvändning av anslutningar mellan Edge och Origin är fortfarande viktigt, annars äter backend-handskakningen upp hela vinsten.
Ursprungsserver som flaskhals
En svag Ursprung begränsar alla CDN-fördelar eftersom missar och revalideringar väntar där. Om det inte finns tillräckligt med CPU, PHP eller nodprocesser backar upp och timeouts ackumuleras. Om det finns brist på RAM och IOPS saktar databasen ner och varje varmfas för cache slutar i en märkbar kö. Jag kontrollerar mätvärden som CPU-steal, iowait och öppna anslutningar innan jag justerar CDN. Först när ursprunget svarar med hög prestanda plockar CDN upp den stora Vinster från kanten.
Design av nätverk, latens och DNS
Jag mäter RTT mellan användare, Edge och Origin separat, annars jagar jag fantomorsaker. Jag övervakar också DNS-upplösningstider och återanvändningsgrad för anslutningar. Ogynnsam peering mellan CDN-backbone och ursprungsdatacentret gör varje miss dyrare. Anycast hjälper ofta, men i enskilda fall leder det till en överfull PoP; en analys av Anycast DNS. Jag testar därför från målregioner med verkliga spår innan jag skapar en global Distribution beräkna.
Cache-rensning och TTL-strategier som fungerar
Utan ren TTL-logik, kanter levererar innehåll som är för gammalt eller bombarderar källan med onödiga revalideringar. Jag använder s-maxage för proxies, age headers för mätbarhet och ETags endast där If-None-Match verkligen är meningsfullt. Jag avfyrar rensningar specifikt efter tagg eller sökväg, aldrig som en fullständig rensning under högtrafiktider. Diff-baserade rensningar efter driftsättningar sparar resurser och förhindrar kallchocker i cacheminnet. Följande tabell ger en snabb Riktlinjer för startvärden:
| Innehållstyp | Rekommenderad TTL | Utlösare för rensning | Risk om TTL är för hög/låg | CDN-regel anmärkning |
|---|---|---|---|---|
| CSS/JS versionerad (t.ex. app.v123.js) | 7-30 dagar | Ny version | För hög: knappast någon risk; för låg: ofta missar | Cache-nyckel utan cookies, ignorera frågor |
| Bilder/teckensnitt oförändrade | 30-365 dagar | Swap av tillgångar | För hög: föråldrad tillgång; för låg: ursprungslast | Ställ in Immutable, kontrollera Gzip/Brotli |
| HTML statisk (marknadsföringssidor) | 15-120 minuter | Uppdatering av innehåll | För hög: gammalt innehåll; för låg: revalideringar | s-maxage, stagnera under omprövning |
| Dynamisk HTML (butik, inloggning) | 0-1 minut | Användarevenemang | För hög: felaktig personalisering; för låg: missar | BYPASS per cookie/auktorisation |
| API:er (GET) | 30-300 sekunder | Förändring av data | För högt: föråldrad data; för lågt: dånande spishäll | Stale-If-fel, negativ cachning |
Statiskt vs. dynamiskt - den överraskande effekten
Webbservrar levererar statisk Filer extremt snabbt, ofta flera storleksordningar snabbare än dynamiska sidor. Men om ett insticksprogram ställer in cookies för bilder eller CSS markerar CDN dessa tillgångar som privata och kringgår cacheminnet. Edge och webbläsaren fortsätter sedan att återvända till källan - med motsvarande långa kedjor. Jag kontrollerar därför cookie-flaggor för alla statiska rutter och separerar statiska domäner så att inga sessionscookies inkluderas. Detta håller Träfffrekvens hög och ursprunget har plats för riktig logik.
Värm upp och använd prefetch på ett klokt sätt
Döda kalla cacher Prestanda efter lanseringar, eftersom alla träffar blir missar och Origin glöder. Jag förvärmer specifikt viktiga sökvägar, prioriterar startsidor, bästsäljare och kritiska API-slutpunkter. Prefetch- och preload-headers förbereder uppföljningstillgångar och minskar lanseringsfasen avsevärt. Om du ställer in detta metodiskt hittar du kompakta instruktioner på CDN-uppvärmning användbara impulser. Kombinerat med Stale-While-Revalidate förblir kanterna leveransdugliga, även om ursprunget är kort. stammar.
Checklista för konfiguration steg för steg
Jag börjar med Cache-nyckelinga cookies, inga onödiga frågeparametrar för statiska objekt. Sedan verifierar jag Cache-Control, s-maxage, Stale-While-Revalidate och Stale-If-Error direkt i sidhuvudet. För det tredje kontrollerar jag cookie-policyn och auktoriseringen för dynamiska sökvägar så att personaliseringen förblir korrekt. För det fjärde mäter jag latens, DNS-tider och TLS-handskakningar separat för Client→Edge och Edge→Origin från målregionerna. För det femte kontrollerar jag rensningsautomatiseringen efter driftsättningar så att nytt innehåll snabbt blir tillgängligt på alla Kanter lögn.
Typiska anti-mönster och hur jag undviker dem
Jag klarar mig utan globala Fullständiga upptryckningar vid topptider, för då träffar alla användare en miss. Jag ställer inte in mycket låga TTL för bilder bara för att vara „på den säkra sidan“. Jag skapar inte överdrivna Vary-regler som får antalet objekt i cacheminnet att explodera. Jag kör inte cookies på statiska domäner, även om det verkar „bekvämt“. Och jag använder inte aggressiv revalidate på HTML när stale-while-revalidate ger samma intryck av färskhet med mycket mindre Last uppnått.
Beslut om arkitektur: Multi-CDN, regional peering
En Multi-CDN med latensstyrd routing distribuerar förfrågningar till den plats där rutten för närvarande är snabbast. Jag använder origin shield eller tiered caching för att hålla ursprunget skyddat i händelse av missstormar. Regional peering med stora internetleverantörer minskar ofta RTT och paketförlust mer än någon kodjustering. Negativ cachelagring för 404/410 begränsar upprepade missar som bara returnerar fel. Med rena hälsokontroller fungerar failover utan synliga Avhoppare för användare.
Funktioner på kanten: Arbetare, ESI och fragmenterad cachelagring
Många CDN erbjuder Kantberäkningsmå funktioner som skriver om rubriker, bestämmer vägar eller dynamiskt monterar HTML. Jag använder detta för att kapsla in personalisering i kanten och hålla majoriteten av HTML cachbar (fragment/ESI-strategi). Fallgropar: kallstarter av långsamma funktioner, alltför generösa CPU/tidsgränser och tillstånd som inte är reproducerbara. Jag håller funktioner deterministiska, mäter deras p95-körtid och loggar uttryckligen om de aktiverar eller förhindrar en cache-träff.
Ren kontroll över bilder, format och komprimering
Brödpinne för text (HTML, CSS, JS) ger mätbart bättre komprimering än Gzip, men får inte användas två gånger. Jag avaktiverar Origin-komprimering om Edge redan komprimerar rent och är uppmärksam på innehållslängd/överföringskodning. WebP/AVIF-varianter är värdefulla för bilder - men endast med kontrollerad komprimering. Varierande-strategi. Jag normaliserar Accept-headers för att inte skapa en cache-explosion och håller versionshantering via filnamn, inte via frågesträngar.
Normalisering av cache-nycklar och vitlistor för parametrar
Onödigt Parametrar för förfrågan som UTM/Campaign genererar lågfakta varianter. Jag vitlistar bara ett fåtal parametrar som verkligen ändrar rendering eller data och ignorerar allt annat i cache-nyckeln. För statiska tillgångar tar jag konsekvent bort cookies från nyckeln. Jag plattar också till rubriker som sällan är relevanta (t.ex. Accept-Language) och minskar därmed antalet objekt utan att förlora funktionen. Detta ökar ofta träfffrekvensen med tvåsiffriga tal.
Autentisering, signaturer och privat innehåll
Personliga områden behöver skyddas, men de behöver inte vara helt omöjliga att cachelagra. Jag separerar privat Användardata (BYPASS) från offentliga fragment (kan cachas) och använd signerade URL:er eller cookies för nedladdningsbara objekt med kort TTL. Säkerhetsflaggor som Authorisation/Cookie får inte oavsiktligt cachelagras vid kanten; jag kontrollerar därför uttryckligen vilka headers som påverkar cache-nyckeln. För API:er ställer jag bara in „public, s-maxage“ för GET och bara om svaren verkligen är idempotenta.
Prioritering, tidiga tips och förhandskoppling
HTTP/2-prioritering fungerar bara om Edge inte gör en blind omordning. Jag definierar prioriteringar för Crit-vägar (CSS före bilder) och använda 103 Early Hints för att skicka länkar före den faktiska HTML-filen. Förkoppla hjälper till med domäner som säkert kommer att följa; överdriven dns prefetch skapar å andra sidan tomgångsarbete. Jag mäter om dessa ledtrådar verkligen ändrar nedladdningsordningen - om inte korrigerar jag prioriteringarna eller sparar överflödiga ledtrådar.
Timeouts, omförsök och skydd av ursprunget
För aggressiv Försök på nytt för missar multiplicera ursprungsbelastningen och förlänga TTFB om många arbetare väntar på samma resurs samtidigt. Jag ställer in korta timeouts, exponentiell backoff och collapse revalidations („request collapsing“) så att bara en hämtning når ursprunget. En kretsbrytare, som aktiveras för felfrekvenser på stale-om-fel kommer att ta emot leveransen istället för att träffa användare med 5xx. Viktigt: Håll liv och anslutningspooler mellan Edge och Origin stabila, annars kommer ombyggnaden att äta upp alla fördelar.
WAF, bot-trafik och hastighetsbegränsningar
WAF:s regler kontrollerar ofta varje begäran synkront och kan öka latensen avsevärt. Jag kör statiska sökvägar förbi WAF där det är säkert att göra det och ställer in regler till „endast logg“ innan jag aktiverar dem. För felvänliga bots eller scrapers begränsar jag hastighetsgränserna på kanten och använder negativ cachelagring för kända 404-vägar. Detta gör att kanten förblir smidig, ursprunget skyddat och legitim trafik ostörd.
Mätvärden, loggar och spårning som verkligen hjälper
Att vara blind utan övre percentiler är det största misstaget. Jag spårar p95/p99 TTFB, edge hit rate, reuse rates, TLS handskakningstider och ursprungets hämtningstid separat. Svarshuvuden med cachestatus (HIT/MISS/STALE/BYPASS), ålder och serverings-PoP hamnar i loggar och korreleras med spår-ID:n från applikationen. Detta gör att jag kan se om en avvikelse härrör från routing, TLS, CPU-väntan eller WAF. Jag gör också ett urval av RUM-data per region och enhet för att kunna identifiera mobila edges separat.
Utrullning, testning och versionering av reglerna
CDN:s regler är Produktion. Jag förseglar ändringar bakom funktionsflaggor, rullar ut dem per region/procent och jämför mätvärden mot en kontrollgrupp. Varje regel får en version, en biljett och mätbara mål (t.ex. +8 % hit rate, -40 ms p95 TTFB). Rollbacks är förberedda och automatiserade. Syntetiska tester kontrollerar i förväg om cacheheaders, cookies och Vary fungerar som planerat innan verklig trafik träffar ändringen.
Använda streaming- och räckviddsförfrågningar korrekt
Video, stora nedladdningar och PDF-filer drar nytta av Begäran om räckvidd och 206 svar. Jag ser till att edge tillåts cacha underintervall, att segmenten namnges konsekvent och att ursprungsservrarna levererar byteintervall effektivt. Prefetching av efterföljande segment jämnar ut bithastighetsförändringar, stale if error håller strömmar igång i händelse av ett kort ursprungsfel. Viktigt: inga förfrågningar om parallella intervall som inte stryps, annars blir bandbredden en flaskhals.
Kortfattat sammanfattad: Dina nästa steg
Börja med en ärlig Mätning från användarregioner och separera Client→Edge från Edge→Origin. Öka träfffrekvensen i cacheminnet med rena headers, cookie diet och lämpliga TTL. Avlasta origin med förvärmning, stale-strategier och en ekonomisk rensningsplan. Optimera TLS, HTTP/2/3 och återanvändning av anslutningar så att handskakningar inte dominerar stoppuret. Kontrollera peering, anycast-mappning och PoP-användning innan du justerar kod eller hårdvara, och säkerställ framgång med ihållande Övervakning.
