Në pothuajse çdo artikull ose mjet për optimizimin e shpejtësisë së faqeve të internetit ka një pikë të thjeshtë "përdorni CDN". CDN, ose rrjeti i shpërndarjes së përmbajtjes, është një strukturë e tillë. Ne në kompaninë "Metod Lab" shpesh hasim pyetje nga klientët rreth kësaj teme, disa e aktivizojnë vetë CDN. Qëllimi i këtij artikulli është të shqyrtohet çfarë mund të ofrojë CDN sa i përket shpejtësisë së ngarkesës së faqes, cilat probleme mund të lindin dhe në cilat raste përdorimi i CDN është i justifikuar.
![[Mos] përdorni CDN](/wp-content/uploads/2019/10/6f32a7973856989f2adac4171a6ef9dd.jpg)
Vonisat e ilustruara në figurë janë të shkaktuara nga përdorimi i CDN.
Pak histori
Siç ndodh me shumë teknologji, CDN-të u shfaqën për shkak të nevojës. Me zhvillimin e kanaleve të internetit për përdoruesit e rrjetit, shërbimet e videove online dolën në pah. Natyrisht, përmbajtja video kërkon një kapacitet shumë më të madh krahasuar me përmbajtjen e zakonshme të faqeve (imazhe, tekst, dhe kodin CSS ose JS).
Kur përpiqeni të transmetoni një video streaming për një numër të madh klientësh nga një server, ngushtica më e mundshme do të jetë linja e internetit të serverit. Zakonisht, disa mijëra transmetime mjaftojnë për të mbushur një linjë tipike serveri. Sigurisht, mund të ketë edhe kufizime të tjera në burime, por tani për tani ato nuk janë të rëndësishme. Po ashtu, është e rëndësishme të kuptohet se zgjerimi i linjës së serverit është shumë i shtrenjtë (dhe ndonjëherë e pamundur), si dhe joefektiv. Ngarkesa në linjë gjatë transmetimeve do të ketë një natyrë ciklike.
Problemi i kufizimit të kanaleve të serverit të veçantë zgjidhet në mënyrë të shkëlqyer me CDN. Klientët lidhen jo direkt me serverin, por me nyjet e rrjetit CDN. Në situatën ideale, serveri përcjell një flux në nyjën CDN, dhe më pas rrjeti përdor burimet e tij për të shpërndarë këtë flux te shumë përdorues. Nga pikëpamja ekonomike, ne paguajmë vetëm për burimet e konsumuar në të vërtetë (kjo mund të jetë kapaciteti ose trafiku) dhe marrim një shkallëzueshmëri të shkëlqyer për shërbimin tonë. Përdorimi i CDN për shpërndarjen e përmbajtjes së rëndë është plotësisht i justifikuar dhe logjik. Megjithatë, është e rëndësishme të theksohet se lojtarët më të mëdhenj në këtë fushë (për shembull, Netflix) krijojnë CDN-të e tyre në vend që të përdorin CDN-të e mëdha tregtare (Akamai, Cloudflare, Fastly, etj.)
Me tĂ« avancimin e web-it, aplikacionet vetĂ« u bĂ«nĂ« mĂ« tĂ« komplikuara dhe mĂ« tĂ« rĂ«nda. Problemi i shpejtĂ«sisĂ« sĂ« ngarkesĂ«s doli nĂ« plan tĂ« parĂ«. EntuziastĂ«t e shpejtĂ«sisĂ« sĂ« faqeve shumĂ« shpejt identifikuan disa probleme tĂ« zakonshme qĂ« çonin nĂ« ngarkesa tĂ« ngadalta. NjĂ« prej tyre ishin vonesat nĂ« rrjet (RTT â round trip time ose koha e pingut). Vonesat ndikojnĂ« nĂ« shumĂ« procese gjatĂ« ngarkesĂ«s sĂ« faqes: vendosjen e lidhjes TCP, nisjen e sesionit TLS, ngarkimin e çdo burimi tĂ« veçantĂ« (imazhe, skedarĂ« JS, dokumente HTML, etj.)
Problemi u përkeqësua nga fakti se me përdorimin e protokollit HTTP/1.1 (para se të shfaqeshin SPDY, QUIC dhe HTTP/2, ky ishte opsioni i vetëm) shfletuesit hapin jo më shumë se 6 lidhje TCP me një host. E gjitha kjo çonte në ndalesa në lidhje dhe në përdorimin joefikas të kapacitetit të kanalit. Problemi u zgjidh pjesërisht duke përdorur sharding të domain-it - krijimin e hosteve shtesë për të kapërcyer kufirin në numrin e lidhjeve.
KĂ«tu shfaqet aftĂ«sia e dytĂ« e CDN â reduktimi i vonesave (RTT) falĂ« numrit tĂ« madh tĂ« pikave dhe afĂ«rsisĂ« sĂ« nyjeve me pĂ«rdoruesin. Distanca luan njĂ« rol tĂ« rĂ«ndĂ«sishĂ«m: shpejtĂ«sia e dritĂ«s Ă«shtĂ« e kufizuar (rreth 200,000 km/s nĂ« fibra optike). KĂ«shtu, çdo 1000 km rrugĂ« shton 5 ms vonesa ose 10 ms nĂ« RTT. KĂ«to janĂ« shpenzimet minimale tĂ« kohĂ«s pĂ«r transferim, pasi ka gjithashtu vonesa nĂ« pajisjet ndĂ«rmjetĂ«se. Duke qenĂ« se CDN zakonisht di tĂ« ruajĂ« objekte nĂ« serverat e veta, ne mund tĂ« pĂ«rfitojmĂ« nga ngarkimi i kĂ«tyre objekteve pĂ«rmes CDN. Kushtet e nevojshme pĂ«r kĂ«tĂ« janĂ«: disponueshmĂ«ria e objektit nĂ« cache, afĂ«rsia e pikĂ«s CDN me pĂ«rdoruesin nĂ« krahasim me serverin e aplikacionit web (origin server). ĂshtĂ« e rĂ«ndĂ«sishme tĂ« kuptohet: afĂ«rsia gjeografike e nyjes sĂ« CDN nuk garanton vonesa tĂ« ulta. RrjetĂ«zimi mes klientit dhe CDN mund tĂ« jetĂ« i tillĂ« qĂ« klienti tĂ« lidhet me njĂ« host nĂ« njĂ« vend tjetĂ«r, ndoshta edhe nĂ« njĂ« kontinent tjetĂ«r. KĂ«tu hyjnĂ« nĂ« lojĂ« marrĂ«dhĂ«niet midis operatorĂ«ve tĂ« komunikimit dhe shĂ«rbimit CDN (peering, disponueshmĂ«ria e lidhjeve, pjesĂ«marrja nĂ« IX etj.) dhe politika e rrjetĂ«zimit tĂ« trafikut nga ana e vetĂ« CDN. PĂ«r shembull, Cloudflare, kur pĂ«rdor dy planet fillestare (falas dhe tĂ« lirĂ«), nuk garanton dorĂ«zimin e pĂ«rmbajtjes nga nyja mĂ« e afĂ«rt â zgjedhja e hostit do tĂ« bĂ«het pĂ«r tĂ« arritur koston mĂ« tĂ« ulĂ«t.
Shumë nga kompanitë kryesore të internetit tërheqin interesin e publikut (ndërmarrjeve të zhvillimit të uebit dhe pronarëve të shërbimeve) në temën e shpejtësisë së ngarkimit dhe funksionimit të faqeve të internetit. Ndër këto kompani janë Yahoo (mjete Yslow), AOL (WebPageTest) dhe Google (shërbimi Page Speed Insights), të cilat zhvillojnë rekomandimet e tyre për përshpejtimin e faqeve (në veçanti, ato lidhen me optimizimin e klientit). Më vonë shfaqen mjete të reja për testimin e shpejtësisë së faqeve, të cilat gjithashtu japin këshilla për rritjen e shpejtësisë. Në secilin nga këto shërbime apo plugins, ka një rekomandim të pandryshueshëm "Përdorni CDN". Si shpjegim për efektin e CDN zakonisht përmendet zvogëlimi i vonesave në rrjet. Fatkeqësisht, nuk të gjithë janë të gatshëm të kuptojnë se si arrihet efekti i përshpejtimit nga CDN dhe si mund të maset, prandaj rekomandimi merret si një e vërtetë dhe përdoret si një postulat. Në të vërtetë, jo të gjitha CDN janë të dobishme njësoj.
PĂ«rdorimi i CDN sot
PĂ«r tĂ« vlerĂ«suar dobishmĂ«rinĂ« e pĂ«rdorimit tĂ« CDN, ato duhet tĂ« klasifikohen. ĂfarĂ« mund tĂ« hasen aktualisht nĂ« praktikĂ« (shembujt nĂ« kllapa natyrisht nuk janĂ« pĂ«rfundimtarĂ«):
- CDN falas për shpërndarjen e bibliotekave JS (MaxCDN, Google, Yandex).
- CDN shërbimesh për optimizimin e klientëve (p.sh. Google Fonts për fontet, Cloudinary, Cloudimage për imazhet).
- CDN për statikën dhe optimizimin e burimeve në CMS (i pranishëm në Bitrix, WordPress dhe të tjerë).
- CDN të përgjithshme (StackPath, CDNVideo, NGENIX, MegaFon).
- CDN për shpërtitjen e faqeve (Cloudflare, Imperva, Airy).
Dallimi kryesor i këtyre tipave është se cila pjesë e trafikut kalon përmes CDN. Tipet 1-3 ofrojnë dorëzim vetëm për një pjesë të përmbajtjes: nga një kërkesë deri në disa dhjetëra (zakonisht imazhe). Tipet 4 dhe 5 ofrojnë proxy të plotë të trafikut përmes CDN.
Në praktikë, kjo do të thotë numri i lidhjeve që përdoren për ngarkimin e faqes. Kur përdorim HTTP/2, ne përdorim një lidhje TCP me hostin për të trajtuar çdo numër kërkesash. Nëse ne ndajmë burimet midis hostit kryesor (origin) dhe CDN, atëherë duhet të shpërndajmë kërkesat në disa domin dhe të krijojmë disa lidhje TCP. Në rastin më të keq, kjo është: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Në këtë formulë nuk janë përfshirë vonesat në rrjetet celulare për aktivizimin e kanalit radios të pajisjes (nëse ai nuk është aktiv) dhe vonesat në kullën celulare.
Këtu është si duket në rrjedhën e ngarkimit të faqes (vonisat për lidhjen me CDN janë theksuar me RTT 150 ms):
![[Mos] përdorni CDN](/wp-content/uploads/2019/10/d0aafcc5aa4dff6c8a97307f39c8c025.jpg)
Nëse CDN mbulon gjithë trafikun e faqes (përveç shërbimeve të jashtme), mund të përdorim një lidhje të vetme TCP, duke kursyer vonisa për lidhjen me hoste të tjera. Sigurisht, kjo vlen për lidhjet HTTP/2.
Dallimet e mĂ«tejshme pĂ«rcaktohen nga funksionaliteti i CDN specifik â pĂ«r llojin e parĂ«, kjo Ă«shtĂ« thjesht hosting njĂ« skedĂ« statike, pĂ«r llojin e pestĂ« Ă«shtĂ« ndryshimi i disa llojeve tĂ« pĂ«rmbajtjes sĂ« faqes me qĂ«llim optimizimin.
Kapacitetet e CDN për të përshpejtuar faqet
Le të përshkruajmë gamën e plotë të mundësive të CDN për të përshpejtuar faqet, pa iu referuar funksionalitetit të llojeve të veçanta të CDN, dhe pastaj do të shikojmë se çfarë është realizuar në secilin prej tyre.
1. Kompresimi i burimeve tekstuale
Mundësia më themelore dhe më e kuptueshme, megjithatë shpesh implementohet keq. Të gjithë CDN e shpallin kompresimin si një tipar të tyre për përshpejtim. Por nëse shikojmë më në detaje, zbulojmë mangësi:
- mund tĂ« pĂ«rdoren shkalla tĂ« ulĂ«ta pĂ«r kompresimin dinamik â 5-6 (pĂ«r shembull, maksimumi pĂ«r gzip Ă«shtĂ« 9);
- në kompresimin statik (skedarët në cache) nuk përdoren mundësi shtesë (siç janë zopfi ose brotli me gradën 11)
- nuk ka mbështetje për kompresim efikas brotli (shpëtim rreth 20% në krahasim me gzip).
Nëse përdorni CDN, vlen të kontrolloni këto disa pika: merrni skedarin që ka ardhur nga CDN, fiksoni madhësinë e tij në formën e kompresuar dhe ribashkoni manualisht për krahasim (mund të përdorni ndonjë shërbim online me mbështetje për brotli, për shembull ).
2. Vendosja e titujve të caching të klientit
Gjithashtu njĂ« veçori e thjeshtĂ« pĂ«r pĂ«rshpejtim: vendosni tituj pĂ«r caching tĂ« pĂ«rmbajtjes nga klienti (shfletuesi). Titulli mĂ« aktual Ă«shtĂ« cache-control, i ekstraktuar â expires. ShtesĂ« mund tĂ« pĂ«rdoret Etag. E rĂ«ndĂ«sishme Ă«shtĂ« qĂ« max-age nĂ« cache-control tĂ« jetĂ« mjaft e madhe (nga njĂ« muaj e mĂ« shumĂ«), nĂ«se jeni tĂ« gatshĂ«m tĂ« cache-oni burimin sa mĂ« rreptĂ«sisht, mund tĂ« shtoni opsionin immutable.
CDN mund tĂ« ulĂ« vlerĂ«n e max-age, duke e detyruar pĂ«rdoruesin tĂ« ngarkojĂ« mĂ« shpesh statikĂ«n. Pse ndodh kjo: pĂ«r tĂ« rritur trafikun nĂ« rrjet ose pĂ«r tĂ« pĂ«rmirĂ«suar pĂ«rputhshmĂ«rinĂ« me faqet qĂ« nuk dinĂ« tĂ« pastrijuarnĂ« cache â nuk Ă«shtĂ« e qartĂ«. PĂ«r shembull, vlera e kohĂ«s sĂ« caching nĂ« headers Cloudflare nĂ« mĂ«nyrĂ« default Ă«shtĂ« 1 orĂ«, qĂ« Ă«shtĂ« shumĂ« pak pĂ«r statikĂ«n e pandryshueshme.
3. Optimizimi i imazheve
Duke pasur parasysh se CDN merr përsipër funksionet e caching dhe shpërndarjes së imazheve, do të ishte logjike t'i optimizojmë ato në anën e CDN dhe ta japim kështu në përdorim për përdoruesit. Të bëjmë një sqarim, kjo mundësi është e disponueshme vetëm për llojet e CDN 2, 3 dhe 5.
Imazhet mund të optimizohen në mënyra të ndryshme: duke përdorur formate të avancuara kompresimi (për shembull, WebP), kodues më efektivë (MozJPEG) ose thjesht duke pastruar metadatat e tepërta.
NĂ« pĂ«rgjithĂ«si, ekzistojnĂ« dy lloje tĂ« tillĂ« optimizimesh: me humbje cilĂ«sie dhe pa humbje cilĂ«sie. CDN zakonisht pĂ«rpiqen tĂ« pĂ«rdorin optimizimin pa humbje â pĂ«r tĂ« shmangur ankesat e mundshme nga klientĂ«t mbi ndryshimin e cilĂ«sisĂ« sĂ« imazheve. NĂ« kĂ«to kushte, fitimi do tĂ« jetĂ« minimal. NĂ« realitet, niveli i cilĂ«sisĂ« JPEG shpesh tejkalon atĂ« qĂ« Ă«shtĂ« e nevojshme, dhe Ă«shtĂ« e mundur tĂ« bĂ«het rikompresimi me njĂ« nivel mĂ« tĂ« ulĂ«t cilĂ«sie, pa cĂ«nuar perceptimin e pĂ«rdoruesve. Nga ana tjetĂ«r, tĂ« pĂ«rcaktosh nivelin e cilĂ«sisĂ« dhe konfigurimet univerzale pĂ«r tĂ« gjitha aplikacionet e mundshme web Ă«shtĂ« e vĂ«shtirĂ«, ndaj CDN pĂ«rdorin konfigurime mĂ« konservatore nĂ« krahasim me ato qĂ« mund tĂ« aplikohen duke marrĂ« parasysh kontekstin (qĂ«llimi i imazheve, lloji i aplikacionit web, etj.)
4. Optimizimi i lidhjes TLS
Shumica e trafikut sot transmetohet përmes lidhjeve TLS, që do të thotë se harxhojmë kohë të shtuar për negociimin TLS. Këto kohët e fundit janë zhvilluar teknologji të reja për të përshpejtuar këtë proces. Për shembull, kjo përfshin kriptografinë EC, TLS 1.3, caching të sesioneve dhe tickete (session tickets), përshpejtimin harduerik të enkriptimit (AES-NI), etj. Konfigurimi i duhur i TLS mund të reduktojë kohën e lidhjes në 0-1 RTT (pa përfshirë DNS dhe TCP).
Me softin modern, implementimi i këtyre praktika nuk është i vështirë në burimet tona.
Jo tĂ« gjitha CDN-tĂ« zbatojnĂ« praktikat mĂ« tĂ« mira pĂ«r TLS, dhe kjo mund tĂ« verifikohet pĂ«rmes matjes sĂ« kohĂ«s sĂ« lidhjes TLS (pĂ«r shembull nĂ« Webpagetest). Ideale pĂ«r njĂ« lidhje tĂ« re Ă«shtĂ« 1RTT, 2RTT Ă«shtĂ« nivel mesatar, 3RTT dhe mĂ« shumĂ« â Ă«shtĂ« e keqe.
Gjithashtu duhet të theksohet se edhe kur përdoret TLS në nivelin e CDN-së, serveri me aplikacionin tonë web gjithashtu duhet të përballojë TLS, por nga ana e CDN-së, sepse trafiku midis serverit dhe CDN-së kalon në rrjetin publik. Në rastin më të keq, mund të kemi vonesa dyfish të lidhjes TLS (e para me hostin e CDN-së, e dyta midis tij dhe serverit tonë).
Për disa aplikacione, është e rëndësishme të shqyrtohen çështjet e sigurisë: zakonisht trafiku dekriptohet në nyjet e CDN, dhe kjo paraqet një mundësi potenciale për kapjen e trafikut. Një opsion për të punuar pa zbuluar trafikun zakonisht ofrohet në planet kryesore me një kosto shtesë.
5. Reduktimi i vonesave të lidhjes
Avantazhi kryesor i CDN, për të cilin të gjithë flasin: vonesa të ulëta (shkalla më e vogël) midis hostit CDN dhe përdoruesit. Kjo arrihet përmes krijimit të një arkitekture rrjeti gjeografikisht të shpërndarë, në të cilën hostet ndodhen në pikë përqendrimi të përdoruesve (qytete, pika shkëmbimi trafiku, etj.)
NĂ« praktikĂ«, prioritetet pĂ«r rrjete tĂ« ndryshme mund tĂ« ndodhen nĂ« regione specifike. PĂ«r shembull, CDN-tĂ« ruse do tĂ« kenĂ« mĂ« shumĂ« pika pranie nĂ« Rusi. Amerikane do tĂ« zhvillojnĂ« kryesisht rrjetin nĂ« SHBA. PĂ«r shembull, njĂ« nga CDN-tĂ« mĂ« tĂ« mĂ«dha Cloudflare ka vetĂ«m 2 pika nĂ« Rusi â MoskĂ« dhe ShĂ«n Petersburg. Pra, maksimalisht mund tĂ« kursejmĂ« rreth 10 ms vonesĂ« krahasuar me vendosjen direkte nĂ« MoskĂ«.
Shumica e CDN-ve perëndimore nuk kanë pikë lidhje në Rusi. Kur lidheni me to, mund të rrisni vetëm vonesat për audiencën tuaj ruse.
6. Optimizimi i përmbajtjes (miniifikimi, ndryshimet strukturore)
Pika mĂ« e komplikuar dhe teknologjikisht e avancuar. Ndryshimi i pĂ«rmbajtjes gjatĂ« dorĂ«zimit mund tĂ« jetĂ« shumĂ« i rrezikshĂ«m. Edhe kur flasim pĂ«r miniifikimin: reduktimi i kodit burimor (nĂ«pĂ«rmjet heqjes sĂ« hapĂ«sirave tĂ« panevojshme, konstruktave tĂ« parĂ«ndĂ«sishme, etj.) mund tĂ« ndikohet nĂ« funksionalitetin e tij. NĂ«se flasim pĂ«r ndryshime mĂ« tĂ« rĂ«ndĂ«sishme â siç janĂ« zhvendosja e kodit JS nĂ« fund tĂ« HTML-sĂ«, bashkimi i skedarĂ«ve dhe tĂ« ngjashme â rreziku pĂ«r tĂ« prishur funksionalitetin e uebfaqes Ă«shtĂ« akoma mĂ« i lartĂ«.
Prandaj, vetĂ«m disa CDN nga tipi 5 merren me kĂ«tĂ«. Sigurisht, nuk do tĂ« jetĂ« e mundur tĂ« automatizoni tĂ« gjitha ndryshimet e nevojshme pĂ«r pĂ«rshpejtim â kĂ«rkohet analiza dhe optimizimi manual. PĂ«r shembull, heqja e kodit tĂ« pa pĂ«rdorur ose tĂ« dyfishtĂ« i pĂ«rket pikĂ«risht detyrave manuale.
Si rregull, të gjitha optimizime të tilla menaxhohen nga cilësimet dhe ato më të rrezikshme janë të çaktivizuara në mënyrë të parazgjedhur.
Mbështetje për mundësitë e përshpejtimit sipas tipeve të CDN
Pra të fillojmë, le të shqyrtojmë se cilat mundësi potenciale për përsppejtimin ofrojnë llojet e ndryshme të CDN.
Për lehtësi, le të riaftësojmë klasifikimin.
- CDN falas për shpërndarjen e bibliotekave JS (MaxCDN, Google, Yandex).
- CDN shërbimesh për optimizimin e klientëve (p.sh. Google Fonts për fontet, Cloudinary, Cloudimage për imazhet).
- CDN për statikën dhe optimizimin e burimeve në CMS (i pranishëm në Bitrix, WordPress dhe të tjerë).
- CDN të përgjithshme (StackPath, CDNVideo, NGENIX, MegaFon).
- CDN për shpërtitjen e faqeve (Cloudflare, Imperva, Airy).
Tani do të lidhim karakteristikat dhe llojet e CDN.
Mundësia
Tipi 1
Tipi 2
Tipi 3
Tipi 4
Tipi 5
Kompressimi i tekstit
+â
â
+â
+â
+
Koka e caches
+
+
+
+
+
Imazhe
â
+â
+â
â
+
TLS
â
â
â
+â
+
TĂ« vonuar
â
â
â
+
+
PĂ«rmbajtje
â
â
â
â
+
NĂ« kĂ«tĂ« tabelĂ«, â+â pĂ«rdoret pĂ«r tĂ« treguar mbĂ«shtetje tĂ« plotĂ«, âââ pĂ«r mungesĂ« dhe â+ââ pĂ«r mbĂ«shtetje tĂ« pjesshme. Sigurisht, ndodhin devijime nga kjo tabelĂ« nĂ« realitet (pĂ«r shembull, ndonjĂ« CDN i pĂ«rgjithshĂ«m mund tĂ« implementojĂ« karakteristika pĂ«r optimizimin e imazheve), por ajo Ă«shtĂ« e dobishme pĂ«r njĂ« pĂ«rmbledhje tĂ« pĂ«rgjithshme.
PĂ«rfundimet
Shpresoj se pas leximit të këtij artikulli do të keni një pamje më të qartë në lidhje me rekomandimin "përdorni CDN" për përsppejtimin e faqeve.
Si nĂ« çdo gjĂ« tjetĂ«r, nuk duhet tâi besoni premtimeve tĂ« marketingut tĂ« ndonjĂ« shĂ«rbimi. Efekti duhet tĂ« matet dhe tĂ« verifikohet nĂ« kushte reale. NĂ«se tashmĂ« po pĂ«rdorni ndonjĂ« CDN, kontrolloni pĂ«r efikasitetin e tij sipas kritereve tĂ« pĂ«rshkruara nĂ« artikull.
Ndoshta përdorimi i CDN tani po ngadalëson ngarkimin e faqes suaj.
Si si rekomandim tĂ« pĂ«rgjithshme mund tĂ« ndaloni nĂ« kĂ«tĂ«: studioni audiencĂ«n tuaj, pĂ«rcaktoni kufijtĂ« e saj gjeografikĂ«. NĂ«se audienca juaj kryesore Ă«shtĂ« e pĂ«rqendruar brenda njĂ« rrethi prej 1-2 mijĂ« kilometrash, nuk keni nevojĂ« pĂ«r CDN me qĂ«llim kryesor â uljen e vonesave. NĂ« vend tĂ« kĂ«saj, mund tĂ« vendosni serverin tuaj mĂ« afĂ«r pĂ«rdoruesve dhe ta konfigurosh siç duhet, duke marrĂ« shumicĂ«n e optimizimeve tĂ« pĂ«rshkruara nĂ« artikull (falas dhe pĂ«rherĂ«).
Në rast se audienca juaj është vërtet gjeografikisht e shpërndarë (rrethi më shumë se 3000 kilometrash), përdorimi i një CDN cilësor do të jetë me të vërtetë i dobishëm. Megjithatë, duhet të kuptoni paraprakisht se çfarë saktësisht do të mund të përshpejtojë CDN juaj (shihni tabelën e mundësive dhe përshkrimin e tyre). Përshpejtimi i faqes mbetet gjithsesi një detyrë komplekse, e cila nuk zgjidhet duke u lidhur me CDN. Përveç optimizimeve të përmendura, jashtë CDN mbeten mjetet më efektive për përshpejtim: optimizimi i pjesës serverike, ndryshime të avancuara në pjesën klientike (heqja e kodit të papërdorur, optimizimi i procesit të renderimit, puna me përmbajtjen, fontet, adaptivitetin etj.)
Burimi: habr.com
