allan ebdrup bloghoved ny

Lav en fallback løsning når du loader jQuery

Efter en lille afstikker ned af vi-lukker-biksen vejen, har jeg nu fuld gang i mit projekt til at logge JavaScript fejl i produktion.

Der er mindst tre store udfordringer i, at logge JavaScript fejl:

  • Støj fra browserplugins, facebook, twitter og google analytics scripts skal filtreres fra
  • Når den samme fejl rapporteres forskelligt, fra forskellige browsere, skal den helst genkendes og grupperes sammen
  • Informationsniveauet i fejlrapporten skal helst være så godt, at det er nemt at se hvordan man kan reproducere og rette fejlen

Med hensyn til det første punkt, så har jeg gjort en opdagelse jeg vil dele.

Det sker meget ofte at en fejl som denne bliver logget:

'$' is undefined

Fejlen opstår fordi jQuery ikke er blevet loadet korrekt. Fejlen opstår på ret mange websites, og den opstår tit.

Hvad kan jeg gøre for at undgå fejlen?

Personligt inkluderer jeg altid jQuery, i det JavaScript som jeg sender fra min egen server. Men du kan også lave en fallback løsning,
som kun henter jQuery fra din server, hvis googles CDN ikke har leveret filen.

Samme udfordring gælder i princippet alle tredieparts scripts, som du bruger på din side.

Bruger du selv en fallback løsning? Er der andre måder, at løse problemet på?

Kommentarer (6)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Palle Simonsen

Tak for links :)

På en 'alm.' webside ville jeg også loade fra CDN. På en webapp kan det være en fordel, at have styr på loadtider m.m. og derfor loade en kopi fra egen server (samt undgå for meget 3.parts snask - ala 'analytics'). På en phonegap/trigger.io hybrid vil du normalt inkluderer 3.parts .js i 'build' processen.

Allan Ebdrup Blogger

Hvis man har et system (som f.eks Drupal) der kan finde ud af at slå JavaScript-filer sammen til en stor fil, er der ikke meget vundet


Ja det er een måde at gøre det på, jeg ligger dog så selv min kombinerede JS-fil på CDN, hvilket man bør gøre hvis man henvender sig internationalt.

Der er lavet flere undersøgelser der viser at effekten af Googles CDN er tvivlsom, fx denne:
http://www.root777.com/appdev/does-using-google-libraries-api-cdn-give-y...

Et andet tredieparts bibliotek jeg ser mange fejl på er FB. Facebooks bibliotek til likes på siden osv. Og der er også fejl fra Twitter og Google+ scripts. Men dem tror jeg de færreste bundler med deres eget JavaScript, da der ikke er et egentligt versionerigssystem til dem. De virker som blackboxes, der sikkert altid kræver nyeste version.

David Konrad

Der er lavet flere undersøgelser der viser at effekten af Googles CDN er tvivlsom, fx denne:

Det er en rigtig interessant debat. I min optik er fordelen primært at man spreder sine kald ud til flere servere, udover det med cache, så det er win-win. Hvis ikke der var CDN tror jeg, at jeg selv ville lægge de tunge scripts andre steder alligevel. Jeg tror jeg måske 3 gange i løbet af 5 år har oplevet at CDN var nede, i måske 25 sekunder, men overvåger jo ikke konstant, max en promille af tiden. Ift fallback bruger jeg selv løsning #2 ift stackoverflow-diskussionen.

Allan Ebdrup Blogger

Det er en rigtig interessant debat. I min optik er fordelen primært at man spreder sine kald ud til flere servere, udover det med cache, så det er win-win.


Men hvis du bundler jQuery sammen med dine egne scripts. Så der kun loades et enkelt script, med et enkelt http request, vil der ikke være nogen fordel i at sprede sine kald over flere servere, tvært imod.

Fordelen ved Googles CDN forsvinder, så snart du bundler jQuery med bare et af dine scripts. Bortset fra hvis dine besøgende allerede har jQuery i deres browser cache. Men alle undersøgelser af dette jeg har set, har konkluderet at sandsynligheden for at en besøgende har jQuery i sin cache, er næste ikke-eksisterende.

Log ind eller Opret konto for at kommentere