En la lastaj jaroj, pli kaj pli da platformoj por optimumigi antaŭfinajn projektojn ofertas ŝancojn por mem-gastigado aŭ prokurado de triaj rimedoj. Akamai permesas al vi agordi por memgeneritaj URL-oj. Cloudflare havas Edge Workers-teknologion. Fasterzine povas URL-oj sur paĝoj por ke ili montras al triaj rimedoj situantaj sur la ĉefa domajno de la retejo.
Se vi scias, ke la triaj servoj uzataj en via projekto ne tre ofte ŝanĝiĝas, kaj ke la procezo de liverado de ili al klientoj povus esti plibonigita, tiam vi verŝajne pensas pri prokurado de tiaj servoj. Kun ĉi tiu aliro, vi povas tre bone alproksimigi ĉi tiujn rimedojn al viaj uzantoj kaj akiri pli kompletan kontrolon pri ilia kaŝmemoro ĉe la klienta flanko. Ĉi tio, krome, ebligas al vi protekti uzantojn kontraŭ problemoj kaŭzitaj de la "kraŝo" de triaparta servo aŭ malboniĝo de ĝia agado.
Bona: Plibonigita rendimento
Memgastigado de alies rimedoj plibonigas rendimenton en tre evidenta maniero. La retumilo ne bezonas denove aliri DNS, ĝi ne bezonas establi TCP-konekton kaj fari TLS-manpremon sur triaparta domajno. Vi povas vidi kiel mem-gastigado de alies rimedoj influas rendimenton komparante la sekvajn du figurojn.
Triaj rimedoj estas elŝutitaj de eksteraj fontoj (prenitaj de )
Triaj rimedoj estas konservitaj en la sama loko kiel la resto de la retejo-materialoj (prenitaj de )
La situacio ankaŭ estas plibonigita pro la fakto, ke la retumilo uzos la kapablon multipleksi kaj prioritati datumojn de la HTTP/2-konekto, kiu jam estis establita kun la ĉefa domajno.
Se vi ne gastigas triajn rimedojn, ĉar ili estos ŝarĝitaj de regado malsama ol la ĉefa, ili ne povas esti prioritatitaj. Ĉi tio igos ilin konkuri unu kun la alia por la bendolarĝo de la kliento. Ĉi tio povas rezultigi ŝarĝajn tempojn por enhavo kritika por konstrui paĝon, kiu estas multe pli longa ol tio, kio estus atingebla en idealaj cirkonstancoj. parolu pri HTTP/2 prioritatigo kiu klarigas ĉion ĉi tre bone.
Oni povas supozi, ke la uzo de atributoj en ligiloj al eksteraj rimedoj preconnect helpos solvi la problemon. Tamen, se estas tro multaj el ĉi tiuj ligiloj al malsamaj domajnoj, ĝi efektive povas troŝarĝi la komunikadlinion en la plej decida momento.
Se vi mem gastigas triajn rimedojn, vi povas kontroli kiel ĝuste ĉi tiuj rimedoj estas donitaj al la kliento. Nome, ni parolas pri la jenaj:
- Vi povas certigi, ke la datumkunprema algoritmo, kiu plej taŭgas por ĉiu retumilo, estas uzata (Brotli/gzip).
- Vi povas pliigi la kaŝmemortempon por rimedoj, kiuj kutime ne estas precipe longaj, eĉ kun la plej konataj provizantoj (ekzemple, la responda valoro por la GA-etikedo estas agordita al 30 minutoj).
Vi eĉ povas etendi la TTL por rimedo al, ekzemple, jaro korpigante koncernan enhavon en vian kaŝan administradstrategion (URL-hashes, versioning, ktp.). Pri ĉi tio ni parolos sube.
▍ Protekto kontraŭ interrompoj en funkciado de triaj servoj aŭ ilia ĉesigo
Alia interesa aspekto de mem-gastigado de triaj rimedoj estas, ke ĝi ebligas al vi mildigi la riskojn asociitajn kun malfunkcioj de triaj servoj. Ni supozu, ke la triaparta A/B-testa solvo, kiun vi uzas, estas efektivigita kiel bloka skripto, kiu ŝarĝas en la ĉefsekcio de la paĝo. Ĉi tiu skripto ŝarĝas malrapide. Se la responda skripto malsukcesas ŝargi, la paĝo estos malplena. Se necesas tre longa tempo por ŝargi, la paĝo aperos kun longa prokrasto. Aŭ, supozu, ke la projekto uzas bibliotekon elŝutitan de triaparta CDN-rimedo. Ni imagu, ke ĉi tiu rimedo spertis fiaskon aŭ estis blokita en certa lando. Tia situacio kondukos al malobservo de la logiko de la retejo.
Por ekscii kiel via retejo funkcias kiam iu ekstera servo ne disponeblas, vi povas uzi la sekcion SPOF .
SPOF-sekcio en webpagetest.org
▍Kion pri problemoj kun kaŝmemoro de materialoj en retumiloj? (sugesto: ĝi estas mito)
Vi povus pensi, ke uzado de publikaj CDN-oj aŭtomate kondukus al pli bona resursa rendimento, ĉar ĉi tiuj servoj havas sufiĉe altkvalitajn retojn kaj estas distribuitaj tra la mondo. Sed ĉio estas fakte iom pli komplika.
Ni diru, ke ni havas plurajn malsamajn retejojn: retejo1.com, retejo2.com, retejo3.com. Ĉiuj ĉi tiuj retejoj uzas la bibliotekon jQuery. Ni ligas ĝin al ili uzante CDN, ekzemple - googleapis.com. Vi povas atendi, ke la retumilo elŝutos kaj kaŝmemoros la bibliotekon unufoje, kaj poste uzu ĝin tra ĉiuj tri retejoj. Ĉi tio povus redukti la ŝarĝon en la reto. Eble ĉi tio permesos al vi ŝpari monon ie kaj helpi plibonigi la rendimenton de la rimedoj. El praktika vidpunkto, ĉio aspektas alie. Ekzemple, Safaro havas funkcion nomitan : La kaŝmemoro uzas duoblajn ŝlosilojn bazitajn sur la fonto de la dokumento kaj la fonto de la triaparta rimedo. bona artikolo pri ĉi tiu temo.
malnovaj studoj и , same kiel pli freŝaj Paul Calvano, montru ke resursoj ne estas stokitaj en retumilo-kaŝmemoroj tiom longe kiom ni povus atendi: "Estas serioza interspaco inter la kaŝmemortempo de la propraj kaj triaj rimedoj de projekto. Ni parolas pri CSS kaj rettiparoj. Nome, 95% de indiĝenaj tiparoj havas kaŝmemorvivon de pli ol semajno, dum 50% de triaj tiparoj havas kaŝmemorvivon de malpli ol semajno! Ĉi tio donas al retaj programistoj devigan kialon gastigi tipardosierojn mem!"
Kiel rezulto, se vi gastigas enhavon de aliaj homoj, vi ne rimarkos ajnajn rendimentajn problemojn kaŭzitajn de retumila kaŝmemoro.
Nun kiam ni kovris la fortojn de triaj memgastigado, ni parolu pri kiel distingi bonan efektivigon de ĉi tiu aliro de malbona.
La Malbona: La diablo estas en la detaloj
Movi triajn rimedojn al via propra domajno ne povas esti farita aŭtomate sen certigi, ke tiaj rimedoj estas konvene konservitaj.
Unu el la ĉefaj problemoj ĉi tie estas kaŝmemoro. Ekzemple, versiinformoj estas inkluzivitaj en la nomoj de triaj skriptoj kiel ĉi tio: jquery-3.4.1.js. Tia dosiero ne ŝanĝos estonte, kaj kiel rezulto ĉi tio ne kaŭzos problemojn kun ĝia kaŝmemoro.
Sed se iu versio-skemo ne estas uzata kiam oni laboras kun dosieroj, kaŝmemoritaj skriptoj, kies enhavo ŝanĝiĝas dum la dosiernomo restas senŝanĝa, povas malnoviĝi. Ĉi tio povas esti grava problemo, ĉar ĝi, ekzemple, ne ebligas aldoni aŭtomatigitajn sekurecajn flikaĵojn al skriptoj, kiujn klientoj bezonas ricevi kiel eble plej rapide. La programisto devos klopodi ĝisdatigi tiajn skriptojn en la kaŝmemoro. Krome, ĉi tio povas kaŭzi misfunkciadon de aplikaĵo pro la fakto, ke la kodo uzata ĉe la kliento de la kaŝmemoro diferencas de la plej nova versio de la kodo, por kiu la servila parto de la projekto estas desegnita.
Vere, se ni parolas pri materialoj, kiuj estas ofte ĝisdatigitaj (etikedmanaĝeroj, solvoj por A/B-testado), tiam konservi ilin per CDN-iloj estas tasko solvebla, sed estas multe pli kompleksa. Servoj kiel Commanders Act, etikedadministradsolvo, uzas rethokojn dum publikigado de novaj versioj. Ĉi tio donas al vi la kapablon devigi kaŝmemoron flui sur la CDN, aŭ, pli bone, la kapablon devigi hash aŭ URL-ĝisdatigo.
▍Adaptiva livero de materialoj al klientoj
Krome, kiam ni parolas pri kaŝmemoro, ni devas konsideri la fakton, ke la kaŝmemoro-agordoj uzataj sur la CDN eble ne taŭgas por iuj triaj rimedoj. Ekzemple, tiaj rimedoj povas uzi uzantan agenton flaranta (adapta servado) teknologio por servi specifajn retumiloj kun versioj de enhavo optimumigita specife por tiuj retumiloj. Ĉi tiuj teknologioj dependas de regulaj esprimoj, aŭ datumbazo de HTTP-kapa informo, por eltrovi retumilkapablojn. User-Agent. Post kiam ili scias kun kiu retumilo ili traktas, ili donas al ĝi materialojn desegnitajn por ĝi.
Ĉi tie vi povas memori du servojn. La unua estas googlefonts.com. La dua estas polyfill.io. La servo de Google Fonts provizas, por certa rimedo, diversajn CSS-kodojn, depende de la kapabloj de la retumilo (donante ligilojn al woff2-resursoj uzante unicode-range).
Jen la rezultoj de kelkaj demandoj pri Google Tiparoj faritaj de malsamaj retumiloj.
Demando de Google Tiparoj rezulto de Chrome
Rezulto de Google Tipa-demando efektivigita de IE10
Polyfill.io donas al la retumilo nur la poliplenigojn, kiujn ĝi bezonas. Ĉi tio estas farita pro rendimentaj kialoj.
Ekzemple, ni rigardu kio okazas se vi rulas la jenan peton de malsamaj retumiloj:
En respondo al tia peto efektivigita de IE10, 34 KB da datumoj estos ricevitaj. Kaj la respondo al ĝi, ekzekutita de Chrome, estos malplena.
Kolera: Kelkaj privatecaj konsideroj
Ĉi tiu punkto estas la lasta en ordo, sed ne laste grava. La punkto estas, ke memgastigado de triaj rimedoj sur la ĉefa domajno de la projekto aŭ sur ĝia subdomajno povas endanĝerigi la privatecon de uzantoj kaj negative influi la ĉefan retprojekton.
Se via CDN-sistemo ne estas agordita ĝuste, vi eble finfine sendos la kuketojn de via domajno al triaparta servo. Se taŭga filtrado ne estas organizita ĉe la CDN-nivelo, tiam viaj seancaj kuketoj, kiuj normale ne povas esti uzataj en JavaScript (kun la httponly), povas esti sendita al eksterlanda gastiganto.
Ĝuste tio povas okazi kun spuriloj kiel Eulerian aŭ Criteo. Triaj spuristoj eble starigis unikan identigilon en la kuketo. Se ili estus parto de retejo-materialoj, ili povus legi la identigilon laŭ sia bontrovo dum la uzanto laboris kun malsamaj retaj rimedoj.
Nuntempe, plej multaj retumiloj inkluzivas protekton kontraŭ ĉi tiu tipo de spura konduto. Kiel rezulto, spuristoj nun uzas teknologion , maskante kiel siaj propraj manuskriptoj por diversaj projektoj. Nome, spuristoj ofertas retejposedantojn aldoni CNAME al siaj agordoj por certa domajno, kies adreso kutime aspektas kiel hazarda aro de signoj.
Kvankam ne rekomendas disponigi retejo-kuketojn al ĉiuj subdomajnoj (ekzemple - *.website.com), multaj retejoj faras tion. En ĉi tiu kazo, tiaj kuketoj estas aŭtomate senditaj al kaŝvestita triaparta spuristo. Rezulte, ni ne plu povas paroli pri ia privateco.
Ankaŭ, la sama afero okazas kun HTTP-kapoj , kiuj estas senditaj nur al la ĉefa domajno, ĉar ili povas esti uzataj por krei uzanto. Certiĝu, ke la CDN-servo, kiun vi uzas, filtras ĉi tiujn kapliniojn ĝuste.
Rezultoj
Se vi planas efektivigi mem-gastigadon de triaj rimedoj baldaŭ, lasu min doni al vi kelkajn konsiletojn:
- Gastigu viajn plej gravajn JS-bibliotekojn, tiparojn kaj CSS-dosierojn. Ĉi tio reduktos la riskon de malsukceso de retejo aŭ degenero de rendimento pro rimedo esenca por la retejo neatingebla pro la kulpo de triaparta servo.
- Antaŭ ol vi konservas triajn rimedojn en CDN, certigu, ke ia versio de sistemo estas uzata dum la nomo de iliaj dosieroj, aŭ ke vi povas administri la vivociklon de ĉi tiuj rimedoj permane aŭ aŭtomate rekomencigante la CDN-kaŝmemoron dum publikigado de nova versio de. la skripto.
- Estu tre singarda pri via CDN, prokura servilo kaj kaŝmemoro agordoj. Ĉi tio permesos al vi malhelpi vian projekton aŭ kapliniojn sendi kuketojn
Client-Hintstriaj servoj.
Karaj legantoj! Ĉu vi gastigas aliulajn materialojn en viaj serviloj, kiuj estas ege gravaj por la funkciado de viaj projektoj?
fonto: www.habr.com