We leven in een wereld waar mensen steeds meer en hogere snelheden verwachten. In fracties van een seconde kan uw website waardevolle bezoekers en op hun beurt geld verliezen. Hoewel de meeste mensen denken dat CDN's voor de "grote honden" zijn, zijn ze eigenlijk super goedkoop en ongelooflijk gemakkelijk te gebruiken tegenwoordig.
In deze zelfstudie laat ik u zien hoe u Web Services S3 en CloudFront van Amazon installeert en gebruikt om de laadtijd van websites te verminderen en de verschillen in prestaties te tonen..
Een CDN is een Content Delivery (of Distributie) netwerk. Het is een netwerk van computers met elk systeem op verschillende punten met dezelfde gegevens op elk systeem. Wanneer iemand toegang krijgt tot het netwerk, kan deze toegang krijgen tot het bestand op het systeem dat zich het dichtst bij hen bevindt of degene met minder stroombelasting. Dit resulteert in een betere lagere latentie en duur van het downloaden van bestanden. Zie "Content delivery network" op Wikipedia voor meer informatie over CDN's.
In het bovenstaande voorbeeld hebben bezoekers toegang tot de server die zich het dichtst bij hen bevindt en die de best mogelijke prestaties levert. Het netwerk van servers zou het CDN zijn. Een gewone webhost zou één centrale server hebben waar al die bezoekers toegang tot zouden moeten hebben. Die ene server zou zich alleen in de VS of Europa kunnen bevinden en zou leiden tot langere latentie en laadtijden voor bezoekers die verder weg waren.
Het gebruik van meer dan één server, zelfs op slechts één continent, maakt een verschil in prestaties.
Ik heb nogal wat mensen gevraagd waarom een CDN belangrijk is, zelfs voor kleinere websites, en waarom ze zouden moeten betalen voor nog een andere webservice. Het eenvoudige antwoord is dat hoe sneller, hoe beter. En waarom biedt u uw klanten (bezoekers) niet het beste wat u kunt doen?
Hoe kleiner de website, hoe minder impact een CDN zal hebben. Hoewel, als uw bezoekers geld voor u vertalen, helpt elk klein beetje.
Het is goedkoop. Het is makkelijk. En het kan zich vertalen in meer geld in termen van klanten en besparing op uw normale webhost-uitgaven.
Amazon biedt een hele reeks fantastische webservices. We zullen Amazon's Simple Storage Service (S3) en CloudFront gebruiken. S3 is een oplossing voor gegevensopslag in de cloud die kan worden gekoppeld aan CloudFront, Amazon's CDN.
Als u op zoek bent naar een iets eenvoudiger, alles-in-één oplossing, is Rackspace Cloud Files een andere geweldige optie. Ze werken samen met het CDN van Limelight Network, dat op dit moment iets beter presteert dan Amazon's CDN. Hun service heeft echter een aantal nadelen die u bij Amazon niet zult vinden. Ik zal niet ingaan op al deze, maar een van de grotere voor mij was het gebrek aan aangepaste CNAME-ondersteuning die vermoedelijk op een bepaald moment in de toekomst komt. Met CNAME-ondersteuning kunt u een aangepast subdomein instellen om toegang te krijgen tot uw bestanden, zoals "cdn.uwdomein.com".
Ga naar http://www.cloudclimate.com/cdns/ voor recente prestatievergelijkingen.
Dit zijn Amazon's S3-prijzen voor de VS. Klik in andere gebieden op de afbeelding voor de volledige prijs.
Dit zijn Amazon's CloudFront-prijzen voor de VS. Klik in andere gebieden op de afbeelding voor de volledige prijs.
Gebruik de maandelijkse calculator van Amazon om een beter beeld te krijgen van uw eindafrekening. Vorige maand was mijn totale factuur minder dan $ 5, met het grootste deel van die van 20 GB + aan gegevensopslag. Zoals je ziet, is het heel, heel goedkoop, vooral als je rekening houdt met de voordelen voor prestaties en flexibiliteit.
Om te beginnen, moeten we ons aanmelden voor de S3- en CloudFront-services van Amazon. Als u al een account bij Amazon heeft, hoeft u alleen maar in te loggen en de aanmelding af te ronden. Als dat niet het geval is, moet u een account maken en vervolgens aanmelden voor S3 en CloudFront. Het aanmelden is simpelweg het toevoegen van de service aan uw account. Er is niets ingewikkelds aan de hand.
Klik op elke afbeelding om naar de informatie en aanmeldingspagina van de service te gaan.
Zodra u zich hebt aangemeld, ontvangt u een toegangssleutel-ID en geheime toegangssleutel die u kunt vinden onder 'Uw account'> 'Beveiligingslegitimatie'. Dit is in feite uw gebruikersnaam en wachtwoord voor toegang tot S3.
Eerst moeten we een bucket maken om al onze bestanden in op te slaan. Voor meer informatie over "buckets", lees "Amazon S3-buckets beschreven in gewoon Engels".
Om dit te doen, loggen we eerst in op ons S3-account met behulp van de toegangssleutel-ID en de geheime toegangssleutel met een toepassing zoals Transmit (OS X), wat ik zal gebruiken. Als u meer apps of browser-uitbreidingen voor toegang tot S3 wilt zien, raadpleegt u "Amazon S3 Simple Storage Service - Alles wat u wilde weten".
Nadat we zijn ingelogd, maken we een bucket om onze bestanden in te plaatsen. Ik heb mijn "files.jremick.com" genoemd. Emmers moeten unieke namen hebben, tussen 3 en 63 tekens lang zijn en letters, cijfers en streepjes bevatten (maar niet eindigen met een streepje).
Met uniek bedoelen ze uniek op het AWS-netwerk. Het is dus een goed idee om iets als een URL of iets dergelijks te gebruiken.
De bestanden die we in deze emmer plaatsen, zijn nu toegankelijk op "files.jremick.com.s3.amazonaws.com". Deze URL is echter vrij lang en we kunnen snel een kortere URL instellen. We zullen een nieuw CNAME-item instellen op onze webhost om dit te doen.
Om de standaard-URL in te korten, maken we een CNAME-item zoals ik hieronder heb gedaan (dit is bij uw webhost). Ik heb "bestanden" als mijn subdomein gekozen, maar je kunt alles gebruiken wat je maar wilt.
Nu hebben we toegang tot deze bucket-bestanden op "files.jremick.com". Veel beter! Upload vervolgens de gewenste bestanden in de bucket "files.jremick.com".
Nadat uw bestanden zijn geüpload, moet u de ACL (Access Control List) instellen zodat iedereen de bestanden kan lezen (als u deze openbaar wilt). In Transmit klikt u gewoon met de rechtermuisknop, selecteert u info ophalen, onder machtigingen stelt u "Lezen" in op "Wereld" en klikt u op "Toepassen op ingesloten items ...". Dit geeft alle bestanden binnen deze emmer leestoegang tot de wereld.
Bestanden die zijn geüpload naar uw S3-account, staan standaard alleen lees- en schrijftoegang tot de eigenaar toe. Dus als u later nieuwe bestanden uploadt, moet u deze stappen opnieuw uitvoeren of verschillende rechten toepassen voor alleen die bestanden.
Nu we S3 hebben ingesteld, een kortere URL hebben gemaakt en onze bestanden hebben geüpload, willen we die bestanden toegankelijk maken via CloudFront voor een supersnelle latentie om onze laadtijden te verkorten. Om dit te doen, moeten we een CloudFront-distributie maken.
Log in op uw AWS-account en navigeer naar uw Amazon CloudFront-beheerconsole (onder het vervolgkeuzemenu "Uw account"). Klik vervolgens op de knop "Distributie maken".
We selecteren de origin bucket (de bucket die we eerder hebben gemaakt), zetten loggen aan als je dat wilt, geef een CNAME en opmerkingen op en schakel tenslotte de distributie in of uit. U hoeft geen CNAME of opmerkingen in te voeren, maar we willen later een kortere URL instellen zoals bij S3. Ik zou "cdn.jremick.com" willen gebruiken, dus dat is wat ik hier aan het instellen ben.
Zoals u kunt zien, is de standaard-URL behoorlijk lelijk. Dat is niet iets dat je wilt proberen te onthouden. Laten we nu een CNAME instellen voor de mooie, korte URL.
Om het aangepaste CloudFiles-subdomein in te stellen, zullen we hetzelfde proces doorlopen als voor S3.
Nu hebben we toegang tot bestanden via CloudFront met behulp van "cdn.jremick.com".
Wanneer iemand een bestand opent via uw S3-bucket, werkt het net als een gewone bestandshost. Wanneer iemand echter via CloudFiles een bestand opent, vraagt het het bestand aan vanuit uw S3-bucket (de oorsprong) en slaat het voor de volgende aanvragen op de CDN-server op die het dichtst bij het origniële verzoek ligt. Het is iets ingewikkelder dan dat, maar dat is het algemene idee.
Beschouw een CDN als een slim netwerk dat in staat is om de snelst mogelijke route voor het afleveren van aanvragen te bepalen. Een ander voorbeeld is als de server die het dichtst in de buurt is verzandt met verkeer, kan het sneller zijn om het bestand van een server een beetje verder weg te krijgen, maar met minder verkeer. Dus CloudFront zal het gevraagde bestand van die locatie afleveren.
Zodra een bestand in de cache is opgeslagen op de CloudFront-netwerkservers, wordt het niet vervangen totdat het verloopt en automatisch wordt verwijderd (standaard na 24 uur inactiviteit). Dit kan een groot probleem zijn als u updates onmiddellijk wilt pushen. Om dit te omzeilen, moet je je bestanden een versie geven. "My-stylesheet.css" kan bijvoorbeeld "my-stylesheet-v1.0.css" zijn. Wanneer u vervolgens een update uitvoert die onmiddellijk moet worden uitgeschakeld, wijzigt u de naam in "my-stylesheet-v1.1.css" of iets dergelijks.
Onze inhoud wordt geüpload naar onze S3-bucket, onze CloudFront-distributie wordt geïmplementeerd en onze aangepaste subdomeinen zijn ingesteld voor eenvoudige toegang. Het is tijd om het op de proef te stellen om te zien welk soort prestatievoordelen we kunnen verwachten.
Ik heb 44 voorbeeldafbeeldingen ingesteld van ongeveer 2 KB tot 45 KB. U denkt misschien dat dit meer afbeeldingen zijn dan de meeste websites op één pagina laden. Dat kan waar zijn, maar er zijn veel websites zoals portefeuilles, e-commercesites, blogs, enz. Die evenveel en mogelijk meer afbeeldingen laden..
Hoewel ik alleen afbeeldingen voor dit voorbeeld gebruik, is de bestandsgrootte en de hoeveelheid voor de vergelijking belangrijk. De websites van vandaag laden verschillende javascript-, CSS-, HTML- en afbeeldingsbestanden op elke pagina. 44 bestandsverzoeken zijn waarschijnlijk minder dan de meeste websites daadwerkelijk maken, dus een CDN kan een nog grotere impact hebben op uw website dan we in deze vergelijking zullen zien.
Ik gebruik Safari's Web Inspector om prestatieresultaten te bekijken, ik heb caches uitgeschakeld en shift + 10-15 keer vernieuwd (ongeveer elke 2-3 seconden) voor elke test om een behoorlijk gemiddelde te krijgen van de totale laadtijd, latentie en duur.
Dit zijn de prestatieresultaten wanneer deze worden gehost via mijn gewone webhost. Gesorteerd op latentie.
Gesorteerd op duur.
Exact dezelfde bestanden werden gebruikt voor het testen van S3. Gesorteerd op latentie.
Gesorteerd op duur.
S3 is sneller dan mijn gewone webhost, maar slechts marginaal. Als je geen zin hebt om te rommelen met een CDN, is S3 nog steeds een geweldige optie om je website een behoorlijke snelheidsboost te geven. Ik raad echter nog steeds aan om een CDN te gebruiken en we zullen zien waarom in deze volgende test.
Exact dezelfde bestanden werden gebruikt voor het testen van CloudFront.
Gesorteerd op duur.
Hier is een kort overzicht van de prestatievergelijking tussen mijn gewone webhost en dezelfde bestanden op de CloudFront-service van Amazon.
Duur vergelijking
50ms of zelfs 100ms klinkt niet als een erg lange tijd om te wachten (0.1 seconden), maar als je dat voor 30, 40, 50 of meer bestanden herhaalt, kun je zien hoe het snel seconden oplevert.
Hier is een korte video om te laten zien hoe opvallend de toename van de laadtijd is. Ik heb caches uitgeschakeld en een geforceerde verversing uitgevoerd (shift + refresh) om ervoor te zorgen dat afbeeldingen niet in de cache worden opgeslagen.
Er zijn verschillende andere manieren om de website-prestaties te verbeteren bij het gebruik van een CDN.
Raadpleeg de praktische tips voor het versnellen van uw website voor meer informatie.
Een van de bovenstaande opties om de prestaties nog verder te verbeteren, was het leveren van gzipped-bestanden. Jammer genoeg kan CloudFront niet automatisch bepalen of een bezoeker gzipped-bestanden kan accepteren of niet en de juiste server kan serveren. Gelukkig ondersteunen alle moderne browsers tegenwoordig gzipped-bestanden.
Om gzipped-bestanden van CloudFront te kunnen bedienen, kunnen we onze website wat logica geven om de juiste bestanden te serveren of kunnen we Content-Encoding en Content-Type instellen op een paar specifieke bestanden om de zaken een beetje eenvoudiger te houden. Gzip de gewenste bestanden en hernoem ze zodat het niet eindigt. Gz. Bijvoorbeeld, "filename.css.gz" zou "filename.css" worden of om jezelf eraan te herinneren dat het een gzipped bestand is, noem het "filename.gz.css". Upload nu het gzipped-bestand naar de locatie in uw S3-bucket die u wilt (vergeet niet de ACL / machtigingen in te stellen).
Als u niet zeker weet hoe u een bestand moet gzippen, gaat u naar http://www.gzip.org (OS X kan dit in terminal doen)
We moeten de inhoudcodering en het inhoudstype (als dit nog niet is ingesteld) in onze bestanden instellen, zodat wanneer het via de browser wordt aangevraagd, het weet dat de inhoud is gzipped en in staat zal zijn om het op de juiste manier te decomprimeren. Anders ziet het er zo uit.
We kunnen dit eenvoudig doen met Bucket Explorer. Nadat u het hebt gedownload, voert u uw AWS-toegangssleutel en geheime sleutel in om u aan te melden bij uw S3-account. Zoek het gzipped-bestand dat je eerder hebt geüpload, klik met de rechtermuisknop en selecteer "Update MetaData".
Zoals je ziet, heeft het Content-Type al ingesteld op text / css, dus dat hoeven we niet in te stellen (javascript zou text / javascript zijn). We hoeven alleen de juiste Content-Encoding toe te voegen. Klik op "Toevoegen" en voer in het pop-upvenster "Contentcodering" in het veld Sleutel in en "gzip" in het veld Waarde. Klik op OK en vervolgens op Opslaan en u bent klaar! Nu zal de browser het bestand correct bekijken.
Gzipping een bestand kan de bestandsgrootte sterk verminderen. Deze teststijl is bijvoorbeeld ongeveer 22 kB en is teruggebracht tot ongeveer 5 kB. Voor mijn blog heb ik al mijn jQuery-plug-ins gecombineerd met jQuery UI-tabbladen. Na het mineren werd het teruggebracht tot 26,49 KB, na te zijn gzipped werd het teruggebracht tot 8,17 kB.
Er zijn veel manieren om de prestaties van uw website te verbeteren en naar mijn mening zijn ze het proberen waard. Als bezoekers slechts 0,5 seconde of zelfs 1 seconde verwijderd zijn van het verlaten van uw website, kan een CDN voorkomen dat dit gebeurt. Bovendien zijn de meesten van ons toch speed freaks, dus waarom zou u de prestaties van uw website niet opkrikken als u dat kunt? Vooral als het je tijdens het proces geld kan besparen.
Als u vragen heeft, kunt u me dit laten weten in de opmerkingen en ik zal proberen ze te beantwoorden. Bedankt!