allan ebdrup bloghoved ny

3. parts JavaScript kan få dit site til at gå i sort

Af 42

Det findes et utal af services på nettet, der fungerer ved, at du inkluderer et script i din HTML. Det mest kendte er nok Google Analytics. Men der er også services som Facebook, Twitter, Google Plus, Uservoice, Typekit, Kissmetrics og New Relic (RUM). Bare for at nævne nogle få.

Async load af script

Det første du skal kigge efter, er om scriptet indlæses async (asynkront). Det gør Google Analytics for eksempel:

<script type="text/javascript">
  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-99999999-9']);
 (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();
</script>

Det er async = true og det at scriptet indsættes med JavaScript, der gør det async

Typekit scriptet indsættes ikke async:

<script type="text/javascript" src="//use.typekit.net/xxxxxx.js"></script>
<script type="text/javascript">try{Typekit.load();}catch(e){}</script>

Når du loader 3. parts script som ovenfor, betyder det, at hvis typekit.net er nede, så risikerer du, at dit website går i sort. Dine brugeres browsere hænger, mens browseren forsøger at downloade scriptet fra typekit.net. Det skete faktisk for mange for nylig, da typekit.net var nede.

Det skal dog siges, at typekit også har en async version af deres script. Men det er uansvarligt, at de overhovedet har den synkrone version, og at den står først.

Opdateringen der gjorde sitet ubrugeligt

En anden udfordring med 3. parts JavaScript på din side er, at udbyderne af disse scripts bare kan opdatere scriptet når de har lyst.

Jeg har oplevet, at dette fik et website til at gå i sort midt om natten, fordi 3. parten havde opgraderet sit script.
De havde forurenet det globale JavaScript-namespace med en variabel, der tilfældigvis havde samme navn som en global variabel i vores minified JavaScript. Det gjorde at sitet ikke virkede.

Det eneste vi kunne gøre var at fjerne scriptet. Når 3. parts scripts ikke er versioneret, har du selvfølgelig ingen kontrol over hvilken version af scriptet, du indsætter på din side. Du kan kun få nyeste version - inklusiv den nye versions fejl.

En løsning kan være at downloade scriptet og selv hoste det på egen server. Det har dog den ulempe, at man selv skal holde øje med hvornår der kommer nye versioner af scriptet.
Når 3. parten ikke har en mere gennemsigtig versionerings-strategi for sit script, kan det være at 3.parts produktet holder op med at virke, når scriptet opdateres og du samtidig ikke får opdateret din version af scriptet. 3. parts backenden og 3. parts scriptet skal fungere sammen.

Selvhosting er som udgangspunkt ikke noget disse services tager i betragtning. Jeg har spurgt flere af dem, om vi selv kunne hoste deres script. Svaret var hver gang, at det understøttede de ikke.

Min egen løsning - versionering

På mit projekt Muscula, der logger JavaScript-fejl i produktion, har jeg også et script, du skal inkludere. Scriptet loades selvfølgelig async, men derudover er det versioneret. Det betyde,r at når der kommer en ny version af scriptet, skal du opdatere alle steder, hvor du bruger det. Men det har nogle fordele:

  • Du har fuld kontrol over, hvornår du opgraderer til en ny version
  • Du kan køre opdatering til en nyere version af scriptet gennem dit normale test-flow, med staging og QA
  • Hvis du finder et problem i opgraderingen, kan du rulle tilbage til forrige version
  • Hvis du vil hente scriptet fra din egen server, og derved have fuld kontrol, over hvad du inkluderer på din side, er dette fuldt understøttet.

Derudover har det den fordel, at jeg kan sætte cache af scriptet i browseren til at være flere år. Det gør, at scriptet loader hurtigere for brugerne af websitet - det skal bare hentes fra browserens cache. Det gør også, at min regning til CDN bliver mindre, da scriptet forespørges færre gange. Det kan faktisk godt betyde noget, når jeg allerede har 40 requests i sekundet og det er stigende.

Hvad synes du? Vil du helst have 3. parts scripts versioneret, eller har du det fint med altid at få nyeste version? Har du selv prøvet, at et site gik i sort på grund af 3. parts scripts?

Kommentarer (42)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Ole Michelsen

Jeg er generelt enig i dine betragtninger, men jeg føler der bør gøres opmærksom på en væsentlig forskel i de forskellige udbydere af 3. parts scripts.

Libraries såsom jQuery, Twitter Bootstrap, Knockout mv. hostes af et bredt udvalg af CDN'er: Google, Microsoft, cdnjs.com osv. De er versioneret, men loades for det meste ikke asynkront, da de er "byggeblokke", som siden ikke kan køre uden. Disse CDN'er har en ekstrem høj oppetid, for det meste bedre end den server man selv har (i hvert fald hos billige hostingsites). Samtidig følger der et kæmpe performance-boost ved at bruge en CDN, da scriptet allerede kan være cachet fordi det er referet på andre sites, og fordi de kan levere filerne fra den server nærmest dig.

De store syndere er firmaer som Facebook, UserReport og div. reklame-agancies, da de ikke er nødvendige for at loade siden, men som du siger sjældent loades asynkront. Samtidig er det min erfaring at de efterfølgende hiver store mængder data ned, som man måske ikke forventer. En Facebook like-knap kan fx resultere i omkring 200 kb ektra data skal downloades til scripts, styles og billeder. Desuden benytter de sjældent en lang (hvis overhovedet nogen) cache, da de som sagt ikke er versioneret, og gerne vil have folk altid har det nyeste script.

Så din pointe er ganske valid. Jeg synes bare at libraries og CDN'er, som ved hvad de laver, skal fremhæves/udpeges.

PS. Jeg har aldrig oplevet en konflikt i det globale namespace, da jeg prøver at udgå dem fuldstændig, og følge best practices omkring indkapsling i funktioner. Det er nemt at gøre med f.eks. jQuery plugins, og heller ikke umuligt at opnå med div. anden funktionalitet på siden, hvis man holder tungen lige i munden.

  • 2
  • 0
#2 Dennis Krøger

Lad være med at loade nødvendige libraries fra andre hosts. Minimized er hastigheden fordelen ved caching minimal med mindre ens målgruppe sidder med modems, og selvom CDN temmelig sikkert har langt bedre oppetid end ens egen host er man pludselig afhængig af at både ens egen opppetid OG CDNens oppetid.

  • 3
  • 1
#3 Robert Larsen

Samme problem gør sig til dels gældende med CSS. Mange reklameudbydere leverer CSS filer som af og til rammer samme navne, som vores egen kode. Især med minificeret CSS, hvor man ikke så nemt kan namespace sig ud af det.

Man kan med JavaScript selv stå for at versionere udbydernes scripts, og automatisk tjekke efter nye versioner...det kan man kode sig ud af ret let. Python, Ruby, curl...og så submitte nye versioner til sit eget versionsstyrings system, hvis det er dét, man vil.

  • 0
  • 0
#5 Alexander Færøy

Det skal dog siges, at typekit også har en async version af deres script. Men det er uansvarligt, at de overhovedet har den synkrone version, og at den står først.

Man skal dog huske at hvis man loader en font asynkront samtidig med at man ønsker at benytte fonten på sin side, kan der opstå et "Flash of Unstyled Text" første gang brugeren besøger siden.

  • 2
  • 0
#7 Allan Ebdrup Blogger

Man kan med JavaScript selv stå for at versionere udbydernes scripts, og automatisk tjekke efter nye versioner...det kan man kode sig ud af ret let. Python, Ruby, curl...og så submitte nye versioner til sit eget versionsstyrings system, hvis det er dét, man vil.

Ja det tænkte jeg også på at man kunne gøre. Gør du det rent faktisk i praksis? Hvis ja, kunne du så fortælle lidt mere om hvordan du gør det?

Der må jo være noget "håndbårent" i det hvor man aktivt tager stilling til i hvilket sprint man vil inkludere eventuelle opdateringer.

Og jeg tænker også at der måske er nogle 3. parts scripts der bliver opdateret så tit, at det bliver temmelig meget arbejde at forholde sig til alle opdateringerne. Tænk hvis de laver A/B splittesting på deres script, så er man fucked.

  • 0
  • 0
#8 Allan Ebdrup Blogger

Libraries såsom jQuery, Twitter Bootstrap, Knockout mv. hostes af et bredt udvalg af CDN'er: Google, Microsoft, cdnjs.com osv. De er versioneret, men loades for det meste ikke asynkront, da de er "byggeblokke", som siden ikke kan køre uden. Disse CDN'er har en ekstrem høj oppetid, for det meste bedre end den server man selv har (i hvert fald hos billige hostingsites). Samtidig følger der et kæmpe performance-boost ved at bruge en CDN, da scriptet allerede kan være cachet fordi det er referet på andre sites, og fordi de kan levere filerne fra den server nærmest dig.

Det er rigtigt at de libraries du skriver om er lidt anderledes, og det er heller ikke dem blogindlæget handler om. Det har jeg tidligere skrevet et blogindlæg om: http://www.version2.dk/blog/lave-en-fallback-loesning-naar-du-loader-jqu...

Hvis dit site ikke er oppe, er det ligegyldigt om dit CDN er oppe.

Og der har været en del undersøgelser der viser, at du stort set ikke opnår den effekt at brugeren allerede har biblioteket i cache, når de rammer din side. Udfaldsrummet er simpelthen for stort. Fx denne:

http://www.root777.com/appdev/does-using-google-libraries-api-cdn-give-y...

  • 0
  • 0
#9 Allan Ebdrup Blogger

Man skal dog huske at hvis man loader en font asynkront samtidig med at man ønsker at benytte fonten på sin side, kan der opstå et "Flash of Unstyled Text" første gang brugeren besøger siden.

Det har de faktisk en guide til hvordan man undgår. Men da det er lidt mere omstændigt, end bare at kaste et synkront script på siden, er det nok grunden til, at det ikke står som eneste eller første mulighed.

  • 0
  • 0
#10 Allan Ebdrup Blogger

PS. Jeg har aldrig oplevet en konflikt i det globale namespace, da jeg prøver at udgå dem fuldstændig, og følge best practices omkring indkapsling i funktioner. Det er nemt at gøre med f.eks. jQuery plugins, og heller ikke umuligt at opnå med div. anden funktionalitet på siden, hvis man holder tungen lige i munden.

Ja vi holder os som regel også væk fra det globale namespace, det her var et eller andet plugin vi brugte der gik i sort.

At pollute de globale namespace skal bare ses som et eksempel på hvordan en opdatering af 3. parts scripts kan gå galt. De kan fucke op på mange andre måder :-)

  • 0
  • 0
#11 Kai Birger Nielsen

Jeg bruger noscript udvidelsen til firefox og studser jævnt tit over mængden af sites som folk forventer at man stoler på bare fordi man er gået ind på deres site. Et hurtigt blik på listen for den her side,.... , siger 16 forskellige domæner. Hvordan harmonerer det med denne artikel? :-)

  • 2
  • 0
#13 Allan Ebdrup Blogger

Hvordan sikrer i at jeres brugere ikke bliver hængende på en version som i ønsker at udfase?

Godt spørgsmål. Der er jeg ikke kommet til endnu.Det bliver noget med først, at gøre opmærksom på de fordele der er ved at opgradere. Det er faktisk en god ting i min bog, at man skal overbevise folk om det fornuftige i at opgradede.

Så være bagud kompatibel i meget lang tid, flere versioner tilbage.

Og HVIS et script til sidst skal udfases - så er det nok noget med at advare i meget god tid, og gentagende gange om at hvis man ikke snart opgraderer så vil ens fejl ikke blive logget længere.

  • 0
  • 0
#17 Mark S. Rasmussen

Og der har været en del undersøgelser der viser, at du stort set ikke opnår den effekt at brugeren allerede har biblioteket i cache, når de rammer din side. Udfaldsrummet er simpelthen for stort. Fx denne:

http://www.root777.com/appdev/does-using-google-libraries-api-cdn-give-y...

Det er helt rigtigt at cachingen har en begrænset effekt. Den helt store gevinst ved at loade fra et CDN kommer dog når man har besøgende fra forskellige verdensdele.

Fordelen ved at have lokal hosting er gigantisk. Bare enkelte ekstra requests der skal gå fra f.eks. Kina til Danmark forårsager adskillige sekunders ekstra load. Omend latency burde forsvare en lavere load tid så har praktisk erfaring vist mig at hvert ekstra synkront request der foretages tager omtrent 5 sekunder før first byte ankommer - og det er vel at mærke per request. Ved at have disse filer hosted fra et CDN med en lokal præsens, eller blot fra et naboland, så øges hastigheden væsentligt.

  • 0
  • 0
#18 Sascha Dibbern

Hej Allan, du har med din beskrivelse i artiklen lige lagt grundlaget til måske en ny DDOS angrebs-form, som jeg her nok vil døbe "cross site massive indirekte DDOS", hvor en DDOS-angrib retter sig efter en single point of failure (javascript-hosteren) for at nedlægge websiderne på alle 'brugere' af java-scripterne... nej hvor diabolsk.

}:-)

Så må man bare håbe, at visse af disse java-script hostere har brugt mere kraft og IQ i deres grej end i designet/arkitekturen af provisioneringen af scriptene.

  • 0
  • 0
#19 Allan Ebdrup Blogger

Hej Allan, du har med din beskrivelse i artiklen lige lagt grundlaget til måske en ny DDOS angrebs-form, som jeg her nok vil døbe "cross site massive indirekte DDOS", hvor en DDOS-angrib retter sig efter en single point of failure (javascript-hosteren) for at nedlægge websiderne på alle 'brugere' af java-scripterne... nej hvor diabolsk.

Ny og ny, det svarer da temmeligt godt til det DDoS angreb der var på NemID, hvor serveren der leverer NemID appletten blev lagt ned :-)

Og hust at det kun er hvis 3. parts scriptet loades synkront at det har effekt. De fleste 3.parts script-udbydere lader deres script loade asynkront.

Men jeg tror faktisk du kunne ligge en stor del af nettet ned hvis du fik lagt et af de CDNs ned som hoster jQuery. Den bliver loaded synkront af ret mange.

En anden mulighed ville være at ligge CDNet der leverer google analytics scriptet ned. Selvom de fleste nok loader det asynkront efterhånden. Men der er nok mange der ville bliver frustrerede hvis deres google analytics ikke loggede besøg.

Det ville nok kræve nogle voldsomme kræfter, da den trafik det håndtere af begge til hverdag, allerede ville svare til et massivt DDos angreb for andre sites.

Så må man bare håbe, at visse af disse java-script hostere har brugt mere kraft og IQ i deres grej end i designet/arkitekturen af provisioneringen af scriptene.

Det er rigtigt. De fleste er fornuftige nok til at bruge et CDN. Og der står serverene spredt i hele verden, så dit DDOS skal være ret stort og spredt over hele verden for at det rigtigt skal batte.

Personligt bruger jeg googles CDN, jeg ved ikke hvor mange tæsk det kan holde til, men jeg håber de har styr på deres infrastruktur. Og hvis det skulle være nede, betyder det ikke andet for mine brugere end at de ikke får logget deres JavaScript-fejl i en periode.

  • 0
  • 0
#20 Allan Ebdrup Blogger

Fordelen ved at have lokal hosting er gigantisk. Bare enkelte ekstra requests der skal gå fra f.eks. Kina til Danmark forårsager adskillige sekunders ekstra load. Omend latency burde forsvare en lavere load tid så har praktisk erfaring vist mig at hvert ekstra synkront request der foretages tager omtrent 5 sekunder før first byte ankommer - og det er vel at mærke per request. Ved at have disse filer hosted fra et CDN med en lokal præsens, eller blot fra et naboland, så øges hastigheden væsentligt.

Det er rigtigt. Det jeg gør er at minifie alt mit JavaScript, både mit eget og jQuery osv i een eneste JavaScript fil (og i min app, inliner jeg faktisk også mit CSS og smider i samme fil). Og så levere den fra mit "eget" CDN. Og hvis man går med livrem og seler, kan så lave en fallback til at levere det samme script fra egen server. Hvis CDN'et skulle være nede.

  • 1
  • 1
#21 Philip Andersen

Vil det sige at det script du indlejrer afhænger af jQuery? Generelt bør 3-parts scripts ikke afhænge af andre frameworks, da det kan give nogle nasty fejl, hvis du inkludere andre versioner af jQuery end brugerne selv har (taler af bitter erfaring).

  • 1
  • 0
#22 Allan Ebdrup Blogger

Vil det sige at det script du indlejrer afhænger af jQuery? Generelt bør 3-parts scripts ikke afhænge af andre frameworks, da det kan give nogle nasty fejl, hvis du inkludere andre versioner af jQuery end brugerne selv har (taler af bitter erfaring).

Nej, mit logger-script er 100% håndkodet og lille (8KB gzipped), hele scriptet ligger i en funktion der kaldes med det samme, så der ingen mulighed er for at pollute det globale namespace, og jeg kører også striks JSHint på det.

jQuery er et kæmpe library - det ville aldrig gå at bruge det i et logger-script som mit (en konkurrent inkluderer jQuery i sit logger-script, bare for at bruge det til at lave en post - man må tage sig til hovedet).

Der hvor jeg inkluderer jQuery i mit script, er i den applikation der hører til Muscula, hvor du kan sidde og analysere de beskeder du har fået logget. Denne applikation har JavaScript der gør brug af jQuery.

  • 3
  • 0
#23 Tobias Borg Petersen

Patrick Meenan fra Google har lavet et virkeligt cool plug-in til Chrome, som netop identificerer 3. parts JavaScript filer som kan blokere for indholdet på siden.

Det er desuden i stand til at beregne hvor stor procentdelen af indholdet der bliver blokeret, samt et link over til WebPageTest.org, hvor man kan lave en video-optagelse der sammenligne scenarier hvor et 3. part script er tilgængeligt og et andet hvor det ikke er.

Et perfekt tool til at identificere og præsentere problemet. Prøv det! :-)

Link: https://chrome.google.com/webstore/detail/spof-o-matic/plikhggfbplemddob...

PS. Version2 burde måske kigge nærmere på resultatet af deres eget site!

  • 1
  • 0
#25 David Konrad

Der er jo ikke noget generelt som hedder "async". Det er en proprietær ga-variabel. Man kan ikke se vilkårligt på om noget loades asynkront ved at studere på koden. Det er ikke engang sikkert ga.async har den betydning du tildeler flaget. Har du prøvet at sætte det til false? Der sker nøjagtig det samme.

Tværtimod, hvis du vil have asynkron Google Analytics, og kun guderne ved hvorfor nogen skulle ønske dette, er her en guide https://developers.google.com/speed/pagespeed/module/filter-make-google-... Du er vel klar over, at browsere loader scripts på nøjagtig samme måde uafhængig af, om de scripts de loader besidder et flag der hedder async?

Hvordan skulle man instruere en browser i at loade asynkront, hvis det eller dele af det man vil loade ikke allerede er loadet?

Hvis "De havde forurenet det globale JavaScript-namespace med en variabel", hvordan skulle dette kunne lade sig gøre? Findes der overhovedet et "globalt javascript-namespace"? Der findes dårlig koder javascript, rigtig nok.

Ift CDN-problematikken, og den kan jeg følge lidt. Jeg mener blot at man aldrig skal hoste eksterne scripts på sin egen server, altså minhjemmeside.dk - det skal lægges på andre selvejede domæner som minimum. Årsag loadtid. if (!jQuery) osv bør hente fra en ekstern alternativ ressource, og ikke domænet selv. Og så er det jo heldigvis sådan, at alting efterhånden ligger på google, github osv, en løkke der tager de 2-3 væsentligste burde kunne klare det. Og hvis ikke, så er hele nettet nok nede og det kan være lige meget.

  • 0
  • 0
#26 David Konrad

"men som du siger sjældent loades asynkront"

Hallo! De loades som udgangspunkt aldrig asynkront. Men hvis man henter dem fra et CDN, så opnår man den asynkrone effekt, fordi browseren i sig selv er asynkron og ikke skal vente på minhjemmeside.dk

  • 0
  • 1
#27 David Konrad

Det er helt rigtigt at cachingen har en begrænset effekt. Den helt store gevinst ved at loade fra et CDN kommer dog når man har besøgende fra forskellige verdensdele.

Ikke korrekt. Den største fordel består i, at brugeren sandsynligvis tidligere har besøgt en side som også brugte de samme biblioteker / scripts og hentede dem via et CDN, så det allerede er i cache. Den næststørste fordel er, at browseren skal hente filer ned fra flere forskellige servere og ikke blot en enkelt. Uddistribuering af filer vil altid vinde over alt samlet på minhjemmeside.dk, uanset hvilke typer scripts vi taler om, fejlbehæftede eller ej.

  • 0
  • 0
#28 David Konrad

jQuery er et kæmpe library - det ville aldrig gå at bruge det i et logger-script som mit (en konkurrent inkluderer jQuery i sit logger-script, bare for at bruge det til at lave en post - man må tage sig til hovedet).

Fuldkommen enig. Der hvor jQuery kommer til sin ret er hvor man har seriøst brug for et jQuery-plugin. Ala datatables osv. Altså noget andet der benytter sig af jQuery. Hvis ikke det er tilfældet er det langsomt, tungt osv. Dokumentation helt hen i vejret. Hvis man er forfalden til $-notationen kan man bare lave sin egen funktion function $(element) { return document.getElementById(element); } eller noget i den stil.

  • 0
  • 0
#29 Allan Ebdrup Blogger

Der er jo ikke noget generelt som hedder "async". Det er en proprietær ga-variabel. Man kan ikke se vilkårligt på om noget loades asynkront ved at studere på koden. Det er ikke engang sikkert ga.async har den betydning du tildeler flaget. Har du prøvet at sætte det til false? Der sker nøjagtig det samme.

async er i HTML5 spec'en for script tags.

Tværtimod, hvis du vil have asynkron Google Analytics, og kun guderne ved hvorfor nogen skulle ønske dette, er her en guide https://developers.google.com/speed/pagespeed/module/filter-make-google-... Du er vel klar over, at browsere loader scripts på nøjagtig samme måde uafhængig af, om de scripts de loader besidder et flag der hedder async?

Du kan se google selv forklare hvorfor da de lancerede deres async script i 2009 her: http://googlecode.blogspot.dk/2009/12/google-analytics-launches-asynchro...

Hvis "De havde forurenet det globale JavaScript-namespace med en variabel", hvordan skulle dette kunne lade sig gøre? Findes der overhovedet et "globalt javascript-namespace"? Der findes dårlig koder javascript, rigtig nok.

Nu skal jeg goole det for dig: http://stackoverflow.com/questions/8862665/what-does-it-mean-global-name...

Ift CDN-problematikken, og den kan jeg følge lidt. Jeg mener blot at man aldrig skal hoste eksterne scripts på sin egen server, altså minhjemmeside.dk - det skal lægges på andre selvejede domæner som minimum. Årsag loadtid. if (!jQuery) osv bør hente fra en ekstern alternativ ressource, og ikke domænet selv. Og så er det jo heldigvis sådan, at alting efterhånden ligger på google, github osv, en løkke der tager de 2-3 væsentligste burde kunne klare det. Og hvis ikke, så er hele nettet nok nede og det kan være lige meget.

For mig er selvhosting af scripts, og alt andet statisk, altid CDN.

jQuery var ikke det der var pointen med selvhosting i blogindlæget, det var versionering af de services der står eksempler på i starten. Services der ikke versionerer deres scripts, men bare opdaterer dem når de har lyst.

  • 1
  • 0
#30 David Konrad

async er i HTML5 spec'en for script tags.

Men nu er det jo ikke HTML5 du adresserer, men variabler i google analytics. Hvor nævner du HTML5's <script async ..?

Du kan se google selv forklare hvorfor da de lancerede deres async script i 2009 her: http://googlecode.blogspot.dk/2009/12/google-analytics-launches-asynchro...

Som i sagens natur dårligt kan have noget med HTML5 at gøre, eftersom det ikke fandtes i 2009, og altså stemmer dårligt overens med dit første argument. Men du holder altså på, at google leverer asynkron download baseret på en værdi i et objekt, som readerne/browserne fortolker positivt og forholder sig til?

Nu skal jeg goole det for dig: http://stackoverflow.com/questions/8862665/what-does-it-mean-global-name...

Du kan google frem, at hvis man koder dårligt risikerer man at komme i konflikt med andre javascript-biblioteker, der bruges på samme site? Som jeg implicerede. Hvad blev der af det globale? Det er jo ikke nogen nyhed, at der ikke vil blive ryddet op, garbagecollection, hvis du har to scripts som eksponerer to variabler eller funktioner med det samme navn, men det var måske det du mente med global? Det er derfor ordentlig javascriptkodning ender på } (window) og deslige.

For mig er selvhosting af scripts, og alt andet statisk, altid CDN.

Netop enig, men åbenbart af andre grunde end dig. Og her burde jeg vil indskyde, at det faktiak er underordnet om det ligger på google eller et andet sted. Det væsentlige er, at det ligger et andet sted. Det giver loadfordelene.

jQuery var ikke det der var pointen med selvhosting i blogindlæget, det var versionering af de services der står eksempler på i starten. Services der ikke versionerer deres scripts, men bare opdaterer dem når de har lyst.

Den slags kode skal man aldrig bruge, og hvis man bruger det netop holde en lokal kopi hos sig selv. Og her ikke bruge CDN.

Når jeg finder et inferiørt jQuery-component jeg kan bruge, og det er sjældnere og sjældnere, for der er i virkeligheden ikke grund til det, så lægger jeg dem lokalt og i min EGEN 100% sikre validerede version. Man er tåbelig hvis man stoler på fremmede mennesker og deres versionering. Jeg styrer nogle statslige sites hvis oppetid er ret væsentlig for de involverede parter, og jeg er netop aldrig blevet plaffet ned af nogle 3partshoveder, fordi jeg ganske enkelt ikke stoler på dem. Den risiko har jeg barberet væk. Du mener man skal leve et spændende liv.

Nå, men beklager jeg blandede mig i debatten. Det var vistnok dit fjerde forsøg på at "sælge" dit Muscula. Kan virkelig ikke se hvad man skulle bruge det til.

  • 0
  • 2
#32 David Konrad

Fordelen ved at have lokal hosting er gigantisk. Bare enkelte ekstra requests der skal gå fra f.eks. Kina til Danmark forårsager adskillige sekunders ekstra load. Omend latency burde forsvare en lavere load tid så har praktisk erfaring vist mig at hvert ekstra synkront request der foretages tager omtrent 5 sekunder før first byte ankommer - og det er vel at mærke per request. Ved at have disse filer hosted fra et CDN med en lokal præsens, eller blot fra et naboland, så øges hastigheden væsentligt.

Dine erfaringer må være ret begrænsede, eller baseret på hvad du selv oplever, som bruger, og ikke hvad dine brugere i Kina oplever. Jeg gad godt se de analytiske tal bag påstanden "Ved at have disse filer hosted fra et CDN med en lokal præsens, eller blot fra et naboland, så øges hastigheden væsentligt". I mine øjne himmelråbende. "Blot fra et naboland"...? Man er jo helt målløs. Så det går langsommere hvis man placerer en server i Schweiz?

  • 0
  • 0
#33 Allan Ebdrup Blogger

Men nu er det jo ikke HTML5 du adresserer, men variabler i google analytics. Hvor nævner du HTML5's <script async ..?

Jeg tror du skal læse blogindlæget og kommentarerne igen. Jeg er ikke sikker på at jeg kan forklare det for dig.

Som i sagens natur dårligt kan have noget med HTML5 at gøre, eftersom det ikke fandtes i 2009, og altså stemmer dårligt overens med dit første argument. Men du holder altså på, at google leverer asynkron download baseret på en værdi i et objekt, som readerne/browserne fortolker positivt og forholder sig til?

Du skulle tage og læse hvad jeg linker til inden du drager konklusioner. Citat fra artiklen som jeg linkede til (fra 2009):

Note here the forward-looking use of the new HTML5 "async" attribute in this part of the snippet.

Derudover kan du læse dette om hvorfor async atributten bruges: http://stackoverflow.com/questions/1834077/which-browsers-support-script...

Som jeg implicerede. Hvad blev der af det globale?

http://en.wikipedia.org/wiki/Global_variable

Når jeg finder et inferiørt jQuery-component jeg kan bruge, og det er sjældnere og sjældnere, for der er i virkeligheden ikke grund til det, så lægger jeg dem lokalt og i min EGEN 100% sikre validerede version. Man er tåbelig hvis man stoler på fremmede mennesker og deres versionering.

Du har misset pointen, de services jeg nævner, er næsten allesammen en kombination at en backend og et script man skal sætte ind på siden. Og de understøtter ikke selvhosting af scriptet, som giver de problemer jeg beskriver. Hvis du ikke bruger services som dem, så har du ikke problemet. Men det er der altså andre der gør.

Jeg styrer nogle statslige sites hvis oppetid er ret væsentlig for de involverede parter, og jeg er netop aldrig blevet plaffet ned af nogle 3partshoveder, fordi jeg ganske enkelt ikke stoler på dem. Den risiko har jeg barberet væk. Du mener man skal leve et spændende liv.

Jeg tror at alle der har et website er optaget af en høj oppetid. Det er derfor jeg forsøger at give nogle råd til ting man skal være opmærksom på, så ens oppetid ikke bliver ødelagt.

Nå, men beklager jeg blandede mig i debatten. Det var vistnok dit fjerde forsøg på at "sælge" dit Muscula.

Muscula er et fritidsprojekt, som giver mig en masse læring, mens jeg arbejder på det. Jeg forsøger at dele det med andre. De gange hvor jeg syens at den læring jeg har fået, lige så godt kan deles uden at nævne Muscula så gør jeg det.

Hvis du har en masse erfaringer, så skulle du overveje også at dele hvad du har lært, måske på din egen blog.

Kan virkelig ikke se hvad man skulle bruge det til.

Så lad være :-) Blogindlæget handler meget lidt om Muscula, og meget mere om services som dem jeg nævner i starten. Desværre kom debatten til at handle meget mere om Muscula, hvilket slet ikke var hensigten. (Se spørgsmålene til sidst i blogindlæget)

Næste gang vil jeg gøre hvad jeg kan for at "skjule", at det er noget jeg har lært mens jeg arbejde på Muscula.

  • 0
  • 0
#36 Allan Ebdrup Blogger

Du mener vel bortforklare. Nej, heri er vi enige.

Det jeg mener er, at jeg ikke forstår hvad du stiller spørgsmålstegn ved. Hvis du du mener jeg bortforklarer noget, bliver du nød til at prøve at formulere dit spørgsmål på en anden måde. Ellers virker det som om du troller, og med vilje misforstår hvad jeg skriver.

Hvad er det du mener jeg skriver, og hvorfor er det forkert?

  • 2
  • 0
#38 Allan Ebdrup Blogger

Hallo! De loades som udgangspunkt aldrig asynkront. Men hvis man henter dem fra et CDN, så opnår man den asynkrone effekt, fordi browseren i sig selv er asynkron og ikke skal vente på minhjemmeside.dk

Et script bliver ikke loadet asynkront af at ligge på et andet domæne. Du skal indsætte scriptet med JavaScript som i GA eksemplet.

Eller du kan bruge nogle af de andre metoder, hvis du bare vil downloade flere ting parallelt, men stadig have dit script bliver eksekveret in-order.

Steve Sounders undersøger alternativerne her: http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-bloc...

Siden da er der kommet en mange JavaScript loaders der kan hjælpe med dette. Som fx http://requirejs.org/ og yepnope som Peter Stricker nævner.

Hvis man ligger sit script på et andet domæne kan flere ting downloades parralelt, da forskellige browsere kun tillader en begrænset mængde downloads parallet fra samme domæne (se målinger af dette her: http://www.browserscope.org/?category=network&v=1 det er den kolonne der hedder "Connections per Hostname")

Men at sprede ud på flere domæner hjælper altså ikke på at scriptet blokerer, browseren bliver nød til at vente på at scriptet er downloadet og eksekveret, før den kan komme videre. For at undgå dette, skal scriptet loades async som i GA eksemplet.

Man skal desuden heller ikke bare sprede sine statiske filer ud på rigtigt mange domæner, da DNS-lookups så begynder at koste. Et plugin som YSlow kan analysere dette på din side for dig. Den har både en advarsel om at man bør bruge flere domæner, hvis man bruger for få, og en advarsel hvis man bruger for mange.

  • 0
  • 0
#39 Mark S. Rasmussen

Dine erfaringer må være ret begrænsede, eller baseret på hvad du selv oplever, som bruger, og ikke hvad dine brugere i Kina oplever. Jeg gad godt se de analytiske tal bag påstanden "Ved at have disse filer hosted fra et CDN med en lokal præsens, eller blot fra et naboland, så øges hastigheden væsentligt". I mine øjne himmelråbende. "Blot fra et naboland"...? Man er jo helt målløs. Så det går langsommere hvis man placerer en server i Schweiz?

Mine erfaringer, i dette tilfælde, er baseret på driften at et system med ikke helt uvæsentlige mængder global trafik.

Vores kerne er hosted i Danmark og forskellen, for en besøgende i Kina, på at skulle hente kernen + et par ekstra filer fra Danmark, imod at hente kernen fra Danmark og de ekstra filer enten fra Kina eller en nærliggende POP er voldsom.

Jeg ved ikke helt hvordan Schweiz blev blandet ind i snakken. Jeg taler om forskellen på, fra Kina, at hente filer fra Danmark og så f.eks. Tokyo eller Singapore - to typiske CDN POP lokationer.

  • 1
  • 0
#40 Mark S. Rasmussen

Ikke korrekt. Den største fordel består i, at brugeren sandsynligvis tidligere har besøgt en side som også brugte de samme biblioteker / scripts og hentede dem via et CDN, så det allerede er i cache. Den næststørste fordel er, at browseren skal hente filer ned fra flere forskellige servere og ikke blot en enkelt. Uddistribuering af filer vil altid vinde over alt samlet på minhjemmeside.dk, uanset hvilke typer scripts vi taler om, fejlbehæftede eller ej.

Okay, tillad mig at nuancere. Den største fordel ved et CDN afhænger naturligvis i de konkrete brugsscenarie. Har du et typisk website der benytter jQuery version X, med besøgende fra alverdens verdensdele - så jo, så er én af de største fordele at brugerne måske har det cached, sekundært at de kan hente det fra en nær lokation.

Men har du et system med dine egne scripts, som brugerne næppe har cached andre steder fra, så er den vigtigste parameter at de hurtigt kan hente disse scripts ned - og her er den nære lokation alfa omega.

  • 0
  • 0
#41 Mark S. Rasmussen

Det er rigtigt. Det jeg gør er at minifie alt mit JavaScript, både mit eget og jQuery osv i een eneste JavaScript fil (og i min app, inliner jeg faktisk også mit CSS og smider i samme fil). Og så levere den fra mit "eget" CDN. Og hvis man går med livrem og seler, kan så lave en fallback til at levere det samme script fra egen server. Hvis CDN'et skulle være nede.

Lige præcis inlining er netop en genial taktik som desværre er meget undervurderet. Værdien af caching er fin, men kan vi helt undgå requests i worst-case scenariet, så er prisen for 30 ekstra KB i ét request sjældent dyrere end prisen for at hente bare én byte ved et ekstra request.

Af interesse, når du nævner "eget" CDN, så antager jeg ikke at du rent faktisk har opsat dit eget CDN, men at du benytter en eksisterende udbyder?

  • 1
  • 0
#42 Allan Ebdrup Blogger

Af interesse, når du nævner "eget" CDN, så antager jeg ikke at du rent faktisk har opsat dit eget CDN, men at du benytter en eksisterende udbyder?

Ja, gåseøjnene om "eget" CDN, betyder bare at jeg bruger en CDN udbyger (Google) men indholdet jeg leverer er mit eget. Alle mine egne scripts, jQuery osv. Alt sammen i et eneste GET.

For mig er det klart den simpleste måde at sikre sig at alting downloades hurtigt. Simpelt er godt. Og du sparer et (eller flere) http requests som du nævner.

Jeg versionerer mit script i filnavnet og sætter en meget lang cache-expiration. Så besøgende der kommer igen, har alt i cache.

  • 1
  • 0
Log ind eller Opret konto for at kommentere
Job fra Jobfinder
Tip redaktionen