Innehåll
- Blygsam användarbas
- Extremt lokaliserad användarbas
- Inga buggar, ingen stress - din steg-för-steg-guide för att skapa livsförändrad programvara utan att förstöra ditt liv
- Reglerande och komplexa krav på styrning
- Slutsats
Källa: Nmedia / Dreamstime.com
Hämtmat:
Innehållsleveransnätverk (CDN) kan vara ett snabbt och effektivt sätt att leverera ditt innehåll till användare. Men de är inte alltid det bästa alternativet.
Innehållsleveransnätverk (CDN: er) är ett utmärkt sätt att påskynda åtkomst till ditt innehåll till användarens skärm eller enhet genom att leverera data som är cachade på servrar i närheten. När användare går in på en CDN-aktiverad webbplats kan de få en betydande förbättring av laddningshastigheten, vilket också förbättrar användarupplevelsen.
För arkitekter för datainfrastrukturer som särskilt försöker minska bandbreddsavfall och säkerställa en effektiv resursanvändning är CDN: er en perfekt lösning. Bästa CDN: er har skalbarhet i realtid och förmågan att minimera nätverksfördröjning. Detta innebär att användarna får informationen på minsta möjliga tid, med minimipaketförluster och dina resurser förbrukas på ett optimalt sätt. (För mer information om nätverkseffektivitet, se KPI: s roll i nätverkshantering.)
Vanligtvis tros det att CDN: er är oerhört hjälpsamma i alla innehållssituationer genom att säkerställa en snabbare responstid genom caching och front-end-optimering. CDN: er är inte nödvändigtvis det bästa sättet att optimera för prestanda i alla fall.
En typisk CDN förlitar sig på flera noder distribuerade över hela världen. Cachelagrat innehåll från din webbplats lagras på dessa noder. När användare från en viss geografisk region kommer åt din webbplats levereras de med cache-innehåll från närmaste nod. Minskat avstånd innebär reducerad rundturstid och användaren tar emot innehållet på minst möjliga tid. På samma sätt, om din webbplats är benägen att ta emot stora trafikbelastningar eller spikar, kan en distribuerad nätverkstopologi fungera som en skydd mot överdriven bandbreddförbrukning.
I synnerhet verkar ett CDN vara ett mycket användbart verktyg för alla slags innehåll. Men det är inte alltid fördelaktigt, särskilt om du har specifika behov som utesluter en distribuerad infrastruktur. Här är några exempel.
Blygsam användarbas
Att distribuera ett CDN är mycket meningsfullt om du har en enorm och mångsidig användarbas. Men om du har en liten, målinriktad och specifik användarbas, kan du vara bättre på att använda andra sätt att förbättra användarupplevelsen. Detta är särskilt tillämpligt om din infrastruktur endast tillhandahåller ett litet antal användare, till exempel ett intranät för din organisations interna användning, eller om din användarbas är mycket minimal.
Ett alternativ här är att implementera lat laddning, som laddar ner minsta mängd innehåll till användarens skärm, vilket därför ger användaren omedelbar åtkomst till detta innehåll. I stället för resten av innehållet behålls tillfälliga platshållare. När användaren flyttar till resten av innehållet fylls platshållarna med det faktiska innehållet. Denna teknik säkerställer att det väsentliga tillhandahålls till användaren direkt och att resten av innehållet laddas per behov. Resultatet är smart bandbreddförbrukning, lägsta sidhastighet och en förbättrad användarupplevelse på grund av hastighetsförbättringar.
Extremt lokaliserad användarbas
En av de mest utmärkta fördelarna med ett CDN är att det kan påskynda leverans av innehåll till användare över hela världen. Men om du riktar ditt innehåll till användare som befinner sig inom en viss geografisk region, är det kanske inte mycket meningsfullt att använda ett CDN. Sådana exempel skulle vara om du driver en skola- eller universitetswebbplats - du kanske är bättre på att tillhandahålla tillgång från lokal infrastruktur, särskilt om användare kommer att komma åt från närheten.
Inga buggar, ingen stress - din steg-för-steg-guide för att skapa livsförändrad programvara utan att förstöra ditt liv
Du kan inte förbättra dina programmeringsfärdigheter när ingen bryr sig om mjukvarukvalitet.
För en sådan koncentrerad användarbas kan du experimentera med andra sätt att förbättra användarupplevelsen. Du kan till exempel prova att implementera förhämtning på din webbplats. Förhämtning hämtar i huvudsak komponenter som användaren förväntas komma åt nästa. Om du till exempel visar en bild i ett galleri är det mycket troligt att användaren klickar till nästa. Så förhämtning laddar nästa bild på användaränden innan användaren har klickat på den och därmed återges den direkt så snart användaren når den. Detta förbättrar oerhört den upplevda lasttiden vid slutet av användaren.
Reglerande och komplexa krav på styrning
Om din organisation hanterar känslig användardata är det uppenbart att du har ett komplext styrningsprotokoll på plats, som är tänkt att skydda användardata till varje pris. Detta kan inkludera suveränitetskrav, som föreskriver att data ska hålla sig inom ett visst lands fysiska jurisdiktion. I ett sådant fall kan det inte nödvändigtvis vara bra att använda en CDN, eftersom det innebär att data kan cachelagras på servrar i länder utanför jurisdiktion, vilket kan strida mot suveränitetskraven. (För mer information om de som ansvarar för datastyring, se Chief Data Officer: The Next Hot Tech Job?)
Slutsats
Fortfarande är CDN: er ett bra sätt att förbättra webbplatsens hastighet och pålitlighet i de flesta fall. Moderna molnbaserade CDN: er kommer också att tillhandahålla ett lager av säkerhetsfunktioner, inklusive att fungera som en frontlinje av försvar mot trafikbaserade attacker och lastbalansering genom att fungera som en omvänd proxy.
Även om du kanske inte åtnjuter de viktigaste fördelarna med ett CDN i ett extremt lokaliserat scenario, kommer att distribuera den här typen av tjänster att ge betydande förbättringar i många andra fall.