Share
Vi lever i en värld där människor alltmer väntar på mer och snabbare hastigheter. I fraktioner av en sekund kan din webbplats förlora värdefulla besökare och i sin tur pengar. Även om de flesta tycker att CDN är för de "stora hundarna", är de faktiskt super billiga och otroligt lätta att använda dessa dagar.
I den här handledningen visar jag hur du installerar och använder Amazons webbtjänster S3 och CloudFront för att minska webbplatsens laddningstid samt visa prestandakurserna.
En CDN är ett Content Delivery (eller Distribution) Network. Det är ett nätverk av datorer med varje system placerat på olika punkter med samma data på var och en. När någon har tillgång till nätverket, kan de komma åt filen på det närmaste systemet eller den med mindre strömbelastning. Detta resulterar i bättre lägre latens och filnedladdningstid. För att lära dig mer om CDN, se "Content Delivery Network" på Wikipedia.
I exemplet bilden ovan får besökare tillgång till den närmaste servern som ger bästa möjliga prestanda. Nätverket av servrar skulle vara CDN. En vanlig webbhotell skulle ha en central server där alla besökare skulle behöva komma åt. Den ena servern kunde vara lokaliserad endast i USA eller kanske Europa och skulle leda till längre latens och belastningstider för besökare längre bort.
Att använda mer än en server, även på en kontinent, kommer att göra skillnad i prestanda.
Jag har haft ganska många personer frågar mig varför en CDN är viktig, även för mindre webbplatser, och varför de borde störa betala för ännu en webbtjänst. Det enkla svaret är ju snabbare desto bättre. Och varför inte erbjuda dina kunder (besökare) det bästa du kan?
Ju mindre webbplatsen desto mindre påverkar en CDN. Även om dina besökare översätter till pengar för dig så hjälper varje liten bit.
Det är billigt. Det är lätt. Och det kan översättas till mer pengar när det gäller kunder och spara på dina vanliga webbhotellskostnader.
Amazon erbjuder en hel del fantastiska webbtjänster. Vi använder Amazons enkla lagringsservice (S3) och CloudFront. S3 är en datalagringslösning i molnet som kan kopplas till CloudFront, Amazans CDN.
Om du letar efter en något enklare, allt-i-ett-lösning, är Rackspace Cloud Files ett annat bra alternativ. De har samarbetat med Limelight Network's CDN, som har lite bättre prestanda än Amazonas CDN för närvarande. Men deras service har några nackdelar som du inte hittar med Amazon. Jag kommer inte att komma in i alla dessa men en av de större för mig var bristen på anpassat CNAME-stöd som förmodligen kommer någon gång i framtiden. Med CNAME-support kan du konfigurera en anpassad subdomän för att komma åt dina filer, till exempel "cdn.yourdomain.com".
För att se senaste prestanda jämförelser, besök http://www.cloudclimate.com/cdns/
Här är Amazonas S3-prissättning för USA. För andra områden, klicka på bilden för att se hela prissättningen.
Här är Amazonas CloudFront-prissättning för USA. För andra områden, klicka på bilden för att se hela prissättningen.
Använd Amazons månadsräknare för att få en bättre bild av din sluträkning. Förra månaden var min totala faktura mindre än $ 5, med majoriteten av det som uppkommit från 20 GB + data lagring. Som du kan se är det väldigt mycket billigt, särskilt när du tar hänsyn till prestanda och flexibilitet.
För att komma igång måste vi registrera sig för Amazons S3 och CloudFront-tjänster. Om du redan har ett konto hos Amazon behöver du bara logga in och avsluta registreringen. Om inte, måste du skapa ett konto och fortsätt sedan för att anmäla sig till S3 och CloudFront. Registreringen är helt enkelt att lägga till tjänsten till ditt konto. Det är inget komplicerat involverat.
Klicka på varje bild för att gå till tjänstens informations- och anmälningssida.
När du har registrerat dig får du ett Access Key ID och Secret Access-nyckel som du hittar under "Ditt konto"> "Security Credentials". Detta är i grund och botten ditt användarnamn och lösenord för åtkomst till S3.
Först måste vi skapa en hink för att lagra alla våra filer. För mer information om "hinkar" läs "Amazon S3 Skopor beskrivna på vanlig engelska".
För att göra detta loggar vi först in på vårt S3-konto med hjälp av Access Key ID och Secret Access Key med ett program som Transmit (OS X), vilket är vad jag ska använda. För att se fler appar eller tilläggsprogram för att komma åt S3, se "Amazon S3 Simple Storage Service - Allt du ville veta".
När du är inloggad skapar vi en hink för att lägga in våra filer. Jag har namngivit min "files.jremick.com". Skopor måste ha unika namn, måste vara mellan 3 och 63 tecken och kan innehålla bokstäver, siffror och bindestreck (men kan inte sluta med ett streck).
Unikt betyder de unika på AWS-nätverket. Så det är en bra idé att använda något som en URL eller något liknande.
Filerna som vi lägger in i denna hink kan nu nås på "files.jremick.com.s3.amazonaws.com". Denna webbadress är dock ganska lång och vi kan snabbt konfigurera en kortare. Vi ställer in en ny CNAME-post på vår webbhotell för att göra det här.
För att förkorta standardadressen skapar vi en CNAME-post som jag har gjort nedan (det här är på din webbhotell). Jag har valt "filer" som min underdomän men du kan använda vad du vill.
Nu kan vi komma åt dessa hinkfiler på "files.jremick.com". Mycket bättre! Ladda sedan enkelt de filer du vill ha inom "files.jremick.com" -hinken.
När dina filer har laddats upp, vill du ställa in ACL (Access Control List) så att alla kan läsa filerna (om du vill ha dem offentliga). I Överför du högerklickar du, välj info, under behörigheter som "Läs" till "Världen" och klicka på "Applicera på bifogade objekt ...". Detta kommer att ge alla filer inom den här skopläsans åtkomst till världen.
Som standard tillåter filer som laddas upp till ditt S3-konto endast läs och skrivåtkomst till ägaren. Så om du laddar upp nya filer senare behöver du gå igenom dessa steg igen eller tillämpa olika behörigheter för bara de filerna.
Nu när vi har inställning S3, skapade vi en kortare URL och laddade upp våra filer, vi vill göra dessa filer tillgängliga via CloudFront för att få super låg latens för att minska våra belastningstider. För att göra detta behöver vi skapa en CloudFront-distribution.
Logga in på ditt AWS-konto och navigera till din Amazon CloudFront-hanteringskonsol (under rullgardinsmenyn "Ditt konto"). Klicka sedan på "Skapa distribution" -knappen.
Vi väljer ursprungsskopa (skopan vi skapade tidigare), aktivera loggning om du vill, ange en CNAME och kommentarer och slutligen antingen aktivera eller inaktivera distributionen. Du behöver inte ange en CNAME eller kommentarer, men vi vill konfigurera en kortare URL senare som vi gjorde för S3. Jag skulle vilja använda "cdn.jremick.com" så det är vad jag ställer in här.
Som du kan se är standardadressen ganska ful. Det är inte något du kommer att vilja försöka komma ihåg. Så nu låt oss konfigurera en CNAME för den fina, korta URL-adressen.
För att konfigurera den egna CloudFiles-underdomänen, går vi igenom samma process som vi gjorde för S3.
Nu kan vi komma åt filer via CloudFront med "cdn.jremick.com".
När någon får tillgång till en fil via din S3-hink, fungerar den som en vanlig fil värd. När någon åtkomst till en fil via CloudFiles begär den dock filen från din S3-skopa (ursprung) och cachar den på CDN-servern närmast orignial request för alla efterföljande förfrågningar. Det är lite mer komplicerat än det, men det är den allmänna tanken.
Tänk på en CDN som ett smart nätverk som kan bestämma den snabbaste möjliga vägen för begäran om leverans. Ett annat exempel skulle vara om servern närmast är boggad med trafik, kan det vara snabbare att få filen från en server lite längre bort men med mindre trafik. Så CloudFront kommer istället att leverera den begärda filen från den platsen.
När en fil har cachats i CloudFront-nätverksservrarna, ersätts den inte innan den upphör och tas bort automatiskt (efter 24 timmars inaktivitet som standard). Det kan vara en stor smärta om du försöker skicka uppdateringar omedelbart. För att komma runt detta måste du versiona dina filer. Till exempel kan "my-stylesheet.css" vara "my-stylesheet-v1.0.css". Då när du gör en uppdatering som måste gå ut omedelbart skulle du ändra namnet till "my-stylesheet-v1.1.css" eller något liknande.
Vårt innehåll laddas upp till vår S3-hink, vår CloudFront-distribution distribueras och våra anpassade underdomäner är inställda för enkel åtkomst. Det är dags att ta provet för att se vilka prestationsfördelar vi kan förvänta oss.
Jag har setup 44 exempel bilder som sträcker sig i storlek från ca 2KB upp till 45KB. Du kanske tror att det här är fler bilder än de flesta webbplatser laddar på en enda sida. Det kan vara sant men det finns många webbplatser som portföljer, e-handelswebbplatser, bloggar etc. som laddar lika många bilder och eventuellt fler bilder.
Även om jag bara använder bilder för det här exemplet, vad är viktigt är filstorleken och kvantiteten för jämförelsen. Dagens webbplatser laddar flera javascript, CSS, HTML och bildfiler på varje sida. 44 filförfrågningar är förmodligen färre än de flesta webbplatser faktiskt gör så att en CDN kan ha en ännu större inverkan på din webbplats än vi ser i denna jämförelse.
Jag använder Safaris webbinspektör för att visa resultat, jag har avaktiverat cachar och skift + uppdatera 10-15 gånger (ungefär var 2-3 sekunder) för varje test för att få ett anständigt medelvärde av total laddningstid, latens och varaktighet.
Här är resultatresultaten när du är värd via min vanliga webbhotell. Sorterat efter latens.
Sorterat efter varaktighet.
Exakt samma filer användes för att testa S3. Sorterat efter latens.
Sorterat efter varaktighet.
S3 är snabbare än min vanliga webbhotell men endast marginellt. Om du inte känner för att kasta runt med en CDN, är S3 fortfarande ett bra alternativ för att ge din webbplats en anständig hastighetsökning. Jag rekommenderar fortfarande att använda en CDN och vi kommer att se varför i det här nästa testet.
Exakt samma filer användes för testning CloudFront.
Sorterat efter varaktighet.
Här är en snabb sammanfattning av prestationsjämförelsen mellan min vanliga webbhotell och samma filer på Amazons CloudFront-tjänst.
Varaktighetsjämförelse
50ms eller till och med 100ms låter inte som mycket lång tid att vänta (0,1 sekunder) men när du upprepar det för 30, 40, 50 eller flera filer så kan du se hur det snabbt lägger till upp till sekunder.
Här är en snabb video för att visa hur märkbar ökningen av laddningstiden är. Jag har avaktiverat cacher och gör en tvungen uppdatering (shift + refresh) för att se till att bilder inte cachas.
Det finns flera andra sätt att öka webbplatsens prestanda när du använder en CDN.
Se bästa praxis för att påskynda din webbplats för mer.
Ett av alternativen ovan för att öka prestanda ännu mer gav gzipped-filer. Tyvärr kan CloudFront inte automatiskt avgöra om en besökare kan acceptera gzipped-filer eller inte och servera den rätta. Lyckligtvis, alla moderna webbläsare stöder gzipped filer dessa dagar.
För att kunna betjäna gzipped-filer från CloudFront kan vi ge vår hemsida lite logik för att servera rätt filer, eller vi kan ställa in innehålls-kodning och innehållstyp på några specifika filer för att hålla sakerna lite enklare. Gzip de filer du vill ha och byt namn på dem så det slutar inte .gz. Till exempel, "filename.css.gz" skulle bli "filename.css" eller för att påminna dig om att det är en gzipped-fil, namnge den "filename.gz.css". Ladda upp gzipped-filen till den plats i din S3-hink som du vill ha (glöm inte att ställa in ACL / behörigheterna).
Om du inte är säker på hur du gzipar en fil, se http://www.gzip.org (OS X kan göra detta i terminal)
Vi måste ange Content-Encoding och Content-Type (om det inte redan är inställt) på våra filer så att när det begärs via webbläsaren vet det att innehållet är gzipped och kommer att kunna dekomprimera det ordentligt. Annars kommer det att se ut så här.
Vi kan enkelt göra det med Bucket Explorer. När du har laddat ner den, ange din AWS Access Key och Secret-nyckel för att logga in på ditt S3-konto. Hitta den gzipped-filen du laddade upp tidigare, högerklicka och välj "Uppdatera MetaData".
Som du kan se har det redan innehållstypen satt till text / css så vi behöver inte ställa in det (javascript skulle vara text / javascript). Vi behöver bara lägga till rätt innehålls-kodning. Klicka på "Lägg till" och i popup-dialogrutan skriv "Content-Encoding" i fältet Key och "gzip" i fältet Value. Klicka på OK, Spara sedan och du är klar! Nu läser webbläsaren filen korrekt.
Gzipping en fil kan avsevärt minska filstorleken. Till exempel var det här teststilarket runt 22KB och reducerades till cirka 5KB. För min blogg har jag kombinerat alla mina jQuery-plugins med jQuery UI-flikar. Efter minifiering reducerades den till 26,49KB, efter att den var gzipped, reducerades den till 8,17 KB.
Det finns många sätt att öka prestandan på din webbplats och enligt min mening är de värda att försöka. Om besökare är bara 0,5 sekunder eller till och med 1 sekund bort från att lämna din webbplats, kan en CDN hända att det händer. Plus, de flesta av oss är snabbt freaks i alla fall så varför inte vrida upp prestanda på din webbplats om du kan? Särskilt om det skulle kunna spara pengar i processen.
Om du har några frågor, vänligen meddela mig i kommentarerna och jag försöker svara på dem. Tack!
Accentsconagua