Utmaningar

Nedan finns fyra frågor om HTTP-kommunikation och om hur webbläsaren laddar och kör skript. De bygger på artikeln Webbläsaren som körmiljö.

Varje fråga har ett antal alternativ att välja bland för att göra det lite lättare att resonera. Klicka på “Visa lösning” för att se svaret och förklaringen.

Om du är osäker kan du alltid testa i webbläsaren själv eller ta upp frågan på en handledning.

Fråga 08-01: Vad stämmer om kommunikation över HTTP? (flervalsfråga)

Servern skickar en förfrågan till klienten.
Servern skickar ett svar på klientens förfrågan.
Klienten skickar ett svar på serverns förfrågan.
Klienten skickar en förfrågan till servern.

Tips

Lösningsförslag

Alternativ 2 och 4 är korrekta. Klienten, till exempel webbläsaren, skickar en förfrågan (request) till servern, som sedan skickar ett svar (response) på förfrågan. Det är också så webbläsaren hämtar dina moduler: en förfrågan per fil.

Fråga 08-02: I vilken ordning körs skripten i en modern webbläsare?

<!DOCTYPE html>
<html lang="sv">
  <head>
    ....
    <script type="module" src="./js/script1.js"></script>
    <script type="module" src="./js/script2.js"></script>
  </head>

  <body>
    <script type="text/javascript">
      // script3
    </script>

    <script src="./js/script4.js"></script>
    <script nomodule src="./js/script5.js"></script>
  </body>
</html>

script1, script2, script3, script4
script3, script4, script5, script1, script2
script3, script4, script1, script2
script1, script2, script4, script3

Tips

Lösningsförslag

Svaret är alternativ 3, script3, script4, script1, script2.

HTML-tolken tolkar sidan uppifrån och ner. Modulerna i <head> laddas ner direkt, men körs först när hela sidan är tolkad. Den vanliga skripttaggen i <body> tvingar tolken att stanna och köra skriptet (script3). Samma sak händer vid script4.

script5 ignoreras, eftersom attributet nomodule säger åt webbläsare som förstår moduler att hoppa över skriptet. Det fanns till för äldre webbläsare utan stöd för moduler. När tolken är klar körs script1 följt av script2.

Fråga 08-03: Varför avråds man från inline-skript?

Koden kan inte cachas på ett optimalt sätt.
De är mindre säkra.
Skriptet blockerar DOM-tolkningen.
Koden blir svårare att underhålla.
Visual Studio Code har ingen färgmarkering av kod i inline-skript.
De fungerar ofta inte.

Tips

Lösningsförslag

Alternativ 1, 2 och 4 är korrekta.

1: Ett inline-skript skickas med HTML-sidan varje gång. En extern fil kan webbläsaren cacha och återanvända mellan sidor.
2: Många webbplatser använder en Content Security Policy (CSP) för att skydda sig mot attacker där någon lyckas smyga in egen kod i sidan (XSS). En CSP blockerar som standard alla inline-skript, eftersom webbläsaren inte kan skilja ett inline-skript du har skrivit från ett som en angripare har lagt dit.
4: JavaScript och HTML blandas i samma fil, vilket gör båda svårare att underhålla.

Alternativ 3 är delvis sant. Ett klassiskt inline-skript blockerar DOM-tolkningen, men det gör ett externt klassiskt skript också, så det är inget skäl som gäller just inline-skript. Ett inline-skript med type="module" blockerar inte alls.

Fråga 08-04: Vad innebär det att ett skript är uppskjutet? (<script defer>)

Skriptet körs så fort HTML-tolken hittar skripttaggen.
Körningen av skriptet skjuts upp tills DOM-tolkningen är klar.
Nedladdningen av skriptet skjuts upp tills DOM-tolkningen är klar.
Skriptet laddas ner direkt och körs så fort det är nedladdat.

Tips

Lösningsförslag

Svaret är alternativ 2. Ett defer-skript laddas ner parallellt med att HTML-tolken fortsätter tolka sidan, men körningen skjuts upp tills DOM-tolkningen är klar. Alternativ 4 beskriver i stället async.