Sider med YouTube indlejringer er en almindelig kilde til langsomme indlæsningstider, mest fordi hvert indlejret iframe henter afspillerens egne scripts og forhåndsvisningsmateriale, i det øjeblik det dukker op i sidens markup. Her er ni konkrete måder at gøre sider med YouTube indlejringer hurtigere uden at give afkald på indlejret video.
1. Tilføj native lazy-loading
Den enkelt mest effektive ændring er også den enkleste: tilføj loading=”lazy” attributten til hvert indlejret iframe.
<iframe src="..." loading="lazy"></iframe>Dette fortæller browseren, at den skal udskyde at hente iframe’ets indhold, indtil det er ved at rulle ind i syne, så indlejringer under skærmkanten intet koster ved den indledende indlæsning. Alle moderne browsere understøtter dette nativt, ingen JavaScript nødvendig.
2. Brug et klik-for-at-indlæse mønster på sider med mange videoer
På sider der viser flere videoer på én gang (for eksempel en “årets bedste videoer” oversigt), kan du overveje slet ikke at indlæse noget rigtigt iframe, før en besøgende klikker. Vis et statisk miniaturebillede med en afspilningsknap ovenpå, og udskift kun til den rigtige indlejring ved klik. Dette kræver mere arbejde at implementere, men eliminerer stort set YouTube-relaterede forespørgsler for videoer, en besøgende aldrig afspiller.
3. Brug det privatlivsvenlige domæne
At skifte til youtube-nocookie.com i stedet for youtube.com ændrer ikke direkte indlæsningstiden, men det reducerer antallet af tredjeparts cookie-relaterede scripts, der kører før afspilning, hvilket indirekte reducerer det arbejde, browseren skal udføre ved sideindlæsning.
https://www.youtube-nocookie.com/embed/VIDEO_ID4. Undgå autoplay på indlejringer, der indlæses med siden
En autoplayende indlejring skal begynde at buffere videodata med det samme, hvilket konkurrerer om båndbredde med resten af din sides ressourcer under det kritiske indledende indlæsningsvindue. Reservér autoplay til indlejringer, en besøgende bevidst har udløst, som en lightbox åbnet ved klik.
5. Størrelsestilpas indlejringen korrekt i stedet for at gøre den for stor og skalere
At servere en indlejring i en meget større størrelse end den faktisk vises i (og stole på CSS til at formindske den) sparer ikke båndbredde, da det er selve iframe’et, ikke et billede, der indlæses; men at få width og height (eller din responsive indpaknings billedformat) rigtige undgår layoutforskydning, hvilket direkte påvirker Core Web Vitals-scorer som CLS.
6. Reservér plads med en responsiv indpakning
En indlejring uden defineret størrelse, før den indlæses, får resten af siden til at hoppe rundt, mens den dukker op, en dårlig oplevelse og en Core Web Vitals straf. En responsiv indpakning med en procentbaseret padding-bottom reserverer den korrekte plads med det samme:
<div style="position:relative;width:100%;padding-bottom:56.25%;height:0;overflow:hidden;">
<iframe src="..." style="position:absolute;top:0;left:0;width:100%;height:100%;border:0;" loading="lazy"></iframe>
</div>7. Begræns antallet af indlejringer per side
Selv med lazy-loading kræver en side med femten eller tyve indlejrede videoer meget af en besøgendes forbindelse, mens de scroller. Hvor det er muligt, kan du overveje at paginere lange videooversigter, eller bruge statiske miniaturebilleder, der linker ud til individuelle videosider, i stedet for at indlejre alt på én side.
8. Forbind på forhånd til YouTubes domæner for indlejringer, du ved vil indlæse
Til en side hvor du ved, at en indlejring nær toppen vil indlæse med det samme (ikke lazy-loaded), kan et resource-hint skære lidt af opsætningstiden for forbindelsen:
<link rel="preconnect" href="https://www.youtube-nocookie.com">Brug dette sparsomt, kun til indlejringer der genuint er over skærmkanten, da preconnect til domæner, du ikke straks bruger, spilder de samme ressourcer, du prøver at spare.
9. Mål med rigtige værktøjer, ikke gætteri
Google PageSpeed Insights og Lighthouse-panelet indbygget i de fleste browseres udviklerværktøjer vil specifikt påpege uoptimerede tredjeparts indlejringer og estimere den tid, de koster dig. Test en side før og efter du har anvendt lazy-loading og en responsiv indpakning, for at se den konkrete forskel i stedet for at antage.
Effektopsummering
| Teknik | Primær fordel |
|---|---|
| Native lazy-loading | Udskyder indlejringer uden for skærmen helt |
| Klik-for-at-indlæse | Eliminerer forespørgsler for uafspillede videoer |
| Privatlivsvenligt domæne | Færre cookie-relaterede scripts før afspilning |
| Ingen autoplay som standard | Frigør båndbredde under indledende indlæsning |
| Responsiv indpakning | Forhindrer layoutforskydning (bedre CLS) |
| Preconnect for indlejringer over skærmkanten | Hurtigere forbindelsesopsætning hvor det betyder noget |
Relateret læsning
Se vores komplette YouTube embed guide for det fulde billede, og 12 YouTube embed parametre forklaret for alle afspilningsmuligheder.
Forstå hvad der faktisk indlæses, når en indlejring dukker op
For effektivt at gøre noget hurtigere hjælper det at vide, hvad det faktisk gør. Når et YouTube iframe indlæses, henter det afspillerens JavaScript-applikation, et forhåndsvisningsbillede, og et sæt sporings- og konfigurationsressourcer fra Googles domæner, alt sammen før en besøgende trykker afspil. Dette er en betydeligt større indledende datamængde end for eksempel et enkelt statisk billede, hvilket er præcis grunden til, at en side med flere indlejringer, der indlæses samtidig, føles tungere end den samme side med det tilsvarende antal billeder. At forstå dette er det, der gør teknikker som lazy-loading og klik-for-at-indlæse så effektive: de retter sig specifikt mod denne omkostning før afspilning, i stedet for at forsøge at fremskynde selve videostreamingen, hvilket i høj grad er uden for din kontrol, da det sker på Googles infrastruktur.
Mål den specifikke effekt på dine Core Web Vitals
Googles Core Web Vitals, specifikt Largest Contentful Paint (LCP) og Cumulative Layout Shift (CLS), påvirkes direkte af, hvordan indlejringer håndteres. En indlejring placeret nær toppen af en side, der ikke er lazy-loaded, kan selv blive LCP-elementet, hvilket betyder at dens indlæsningstid direkte bestemmer din rapporterede sidehastighedsscore. En indlejring uden en reserveret, korrekt størrelsestilpasset beholder er en af de mest almindelige årsager til CLS-straffe, da det omgivende indhold synligt forskyder sig, når afspilleren endelig indlæses og gør krav på sin plads. At teste en side i Chromes Lighthouse-panel (indbygget i DevTools, eller tilgængelig gennem PageSpeed Insights) vil identificere præcis, hvilken af disse to metrikker en indlejring påvirker på en specifik side, hvilket fortæller dig, om lazy-loading, størrelsestilpasning, eller begge dele kræver opmærksomhed.
En almindelig fejl: lazy-loading af alt, inklusive indlejringer over skærmkanten
Det er værd at nævne en fejl, der går den anden vej: at anvende loading=”lazy” på en indlejring, der allerede er synlig uden at scrolle, helt øverst på siden. Lazy-loading af et element over skærmkanten kan faktisk forsinke det en smule sammenlignet med at indlæse det ivrigt, da browseren først skal fastslå, at det er i det synlige område, før den henter det. Den generelle regel er at lazy-loade indlejringer under skærmkanten, og lade indlejringer, der genuint er synlige ved indledende indlæsning, hvis nogen, indlæse normalt eller endda med et eksplicit fetchpriority-hint, hvis de er særligt fremtrædende.
Kombinér teknikker til en videotung blog eller anmeldelsesside
En side, der jævnligt udgiver videoanmeldelser eller oversigter, drager fordel af bevidst at kombinere flere af disse ni teknikker i stedet for kun at anvende én. Et praktisk mønster: brug klik-for-at-indlæse miniaturebilleder til hver indlejring i et listeindlæg af oversigtstypen, reservér korrekt størrelsestilpasset plads til hvert miniaturebillede for at undgå layoutforskydning, brug det privatlivsvenlige domæne gennemgående, og reservér faktiske autoplayende, øjeblikkeligt indlæste indlejringer kun til en enkelt fremhævet video helt øverst på en dedikeret videoside. Denne kombination holder oversigtsider hurtige, mens den stadig giver en flagskibs-videoside den mere umiddelbare, højere-kvalitets oplevelse, den fortjener.
Hvordan indlejringshastighed passer ind i den samlede sidehastighedsstrategi
Det er værd at placere YouTube indlejringer i kontekst sammen med en sides andet sidehastighedsarbejde. For de fleste indholdssider forbliver billeder og webskrifttyper den enkelt største samlede bidragyder til sidevægt, hvor tredjeparts indlejringer som YouTube typisk kommer ind på andenpladsen. Det betyder, at indlejringsoptimering giver reelle, målbare gevinster, men den virker bedst som en del af en bredere sidehastighedsindsats snarere end isoleret; en side med en uoptimeret YouTube indlejring og uoptimerede billeder bliver ikke genuint hurtig ved kun at fikse den ene af de to. Prioritér, hvad end en Lighthouse-revision markerer som den større mulighed på dine specifikke sider.
En bemærkning om alternativer til tredjeparts indlejring
Nogle sider forsøger at undgå omkostningen ved tredjeparts indlejringer helt ved i stedet at hoste videofiler selv. Dette bytter ét sæt omkostninger for et andet: selvhostet video kræver din egen båndbredde og lagerplads, mangler typisk YouTubes adaptive streaming-kvalitetsvalg, og fjerner opdagelses- og statistikfordelene ved at have indholdet liggende på YouTube også. For de fleste sider forbliver en velfungerende optimeret YouTube indlejring, ved hjælp af de ni teknikker i denne guide, en bedre balance mellem ydeevne og funktionalitet end selvhosting, selvom meget trafiktunge video-først platforme nogle gange laver et andet regnestykke.
Et sidste ord om prioritering af disse ni teknikker
Hvis du kun kan implementere én ændring i dag, så gør det til native lazy-loading; det er en enkelt HTML attribut, har ingen reel ulempe for indlejringer under skærmkanten, og giver typisk den største enkeltstående forbedring af de ni teknikker dækket her. Behandl den responsive indpakning som anden prioritet, da layoutforskydningsstraf lægger sig oveni for hver indlejring på en side, der mangler en, og arbejd dig gennem de resterende syv, som tiden tillader, nogenlunde i rækkefølgen præsenteret ovenfor.
Hvordan dette forbinder sig til mobilspecifik ydeevne
Mobile forbindelser og enheder forstærker omkostningen ved uoptimerede indlejringer mere end computer gør, da mobilnetværk er mere tilbøjelige til at være begrænset af båndbredde, og mobile processorer har mindre plads til at håndtere flere samtidige tunge sideelementer. Hver teknik i denne guide hjælper mobil ydeevne mindst lige så meget som computer, og lazy-loading i særdeleshed har en tendens til at vise en større relativ forbedring på mobil, da udskydelse af unødvendige forespørgsler betyder mere, når den tilgængelige båndbredde i forvejen er mere begrænset. Hvis din sides statistik viser en betydelig mobilmålgruppe, prioritér at teste disse teknikker specifikt på en begrænset mobilforbindelse i Chrome DevTools, i stedet for kun på en hurtig computerforbindelse, hvor forskellen kan være langt mindre mærkbar.
En afsluttende opsummering af de ni teknikker
På tværs af native lazy-loading, klik-for-at-indlæse mønstre, det privatlivsvenlige domæne, undgåelse af unødvendig autoplay, korrekt størrelsestilpasning, responsive indpakninger, begrænsning af indlejringer per side, målrettede preconnect-hints og løbende måling, er den fælles tråd at udskyde eller reducere arbejde, browseren skal udføre, før en besøgende faktisk ønsker at se en bestemt video. Ingen af disse teknikker kræver, at man giver afkald på indlejret YouTube video eller flytter til selvhosting; de sikrer blot, at omkostningen ved indlejring kun betales, når og hvor det faktisk er nødvendigt.
En bemærkning om test under virkelige forhold
Laboratoriebaserede værktøjer som Lighthouse er nyttige, men repræsenterer en kontrolleret, idealiseret test; feltdata fra værktøjer som Googles Chrome User Experience Report (CrUX) afspejler, hvad rigtige besøgende på rigtige netværk og enheder faktisk oplevede. Hvor de to er uenige, er feltdata generelt det mere præcise billede af din faktiske målgruppes oplevelse med indlejret video på din side.
Generer en lazy-loaded indlejring
Gratis værktøj
Vores generator inkluderer loading=”lazy” og en responsiv indpakning som standard.
Ofte stillede spørgsmål
Skader lazy-loading SEO?
Nej, native browser lazy-loading er velforstået af søgemaskinernes crawlere og anbefales generelt for sidehastighed, som i sig selv er en rangeringsfaktor.
Er en YouTube indlejring tungere end en selvhostet video?
Selve afspilleren tilføjer overhead, men du undgår at hoste og streame videofilen selv, hvilket som regel er en større omkostning. Lazy-loading lukker det meste af den praktiske kløft.
Gælder disse teknikker også for Shorts indlejringer?
Ja, alle ni gælder på samme måde; kun billedformatet for den responsive indpakning ændrer sig for en lodret Shorts indlejring.
Bør jeg lazy-loade en indlejring, der er det allerførste på siden?
Generelt nej; lazy-loading er tiltænkt indhold uden for skærmen, og at anvende det på en indlejring, der allerede er synlig ved indlæsning, kan forsinke den en smule i stedet for at fremskynde noget.
Påvirker videoens egen længde eller opløsning sideindlæsningstiden?
Nej, den indledende sideindlæsningsomkostning kommer fra afspilleren og dens understøttende scripts, ikke selve videofilen, som kun streamer progressivt, når afspilningen faktisk begynder.
Er der en grænse for, hvor mange lazy-loaded indlejringer en side kan have?
Ingen hård grænse, men hver enkelt koster stadig noget, når den rent faktisk ruller i syne, så meget lange sider med snesevis af indlejringer drager fordel af paginering udover lazy-loading.
Vil disse teknikker forbedre min Google-placering?
Sidehastighed og Core Web Vitals er en rangeringsfaktor, så forbedringer her kan hjælpe, selvom de er én af mange faktorer og typisk betyder mest, når din nuværende hastighed er genuint dårlig.
Kræver disse teknikker en udvikler at implementere?
Lazy-loading er en enkelt HTML attribut, som enhver, der er tryg ved at redigere en sides HTML, kan tilføje; klik-for-at-indlæse og preconnect-hints drager fordel af noget udviklingskendskab, men er ikke avancerede teknikker.