\n Det var en tid da du trygt kunne skille mellom en stasjon\u00e6r nettside og en mobil nettside. Faktisk s\u00e5 mye at en hel bransje vokste opp rundt \u00e5 gjenbruke skrivebordssider for mobil.\n<\/p>\n
\n En stund var du ingen hvis du ikke hadde en egen mobilside p\u00e5 et eget domene. S\u00e5 begynte ting \u00e5 endre seg.\n<\/p>\n
\n Mobilskjermer er forbedret til det ugjenkjennelige. Det samme gjorde mobilnettlesere. Nettbrett kastet et annet element inn i ligningen. 4G kom med. Retina-skjermer tilb\u00f8d nye niv\u00e5er av klarhet for sluttbrukere.\n<\/p>\n
\n Plutselig s\u00e5 grensen mellom desktop og mobil uklar ut.\n<\/p>\n
\n Samtidig var det et \u00f8kende mangfold i st\u00f8rrelsen og oppl\u00f8sningen p\u00e5 stasjon\u00e6re skjermer.\n<\/p>\n
\n Og en \u00f8kende hodepine for webdesignere.\n<\/p>\n
\n Borte var de dagene da du bare m\u00e5tte ta hensyn til en h\u00e5ndfull viewport-st\u00f8rrelser. Ting ble komplisert.\n<\/p>\n
\n Heldigvis var hjelpen tilgjengelig i form av medieforesp\u00f8rsler og konseptet med responsiv design.\n<\/p>\n
\n Takket v\u00e6re mediesp\u00f8rringer ble det mulig \u00e5 variere stiler og layout \u2013 til og med innhold \u2013 avhengig av brukerens visningsportbredde og skjermoppl\u00f8sning. Mediesp\u00f8rringer er selvf\u00f8lgelig p\u00e5 ingen m\u00e5te det eneste verkt\u00f8yet i den responsive designerens trikspose, men det er rimelig \u00e5 si at de danner grunnlaget for teknikken.\n<\/p>\n
\n Dette var gode nyheter for mobil. Responsiv design betydde at du effektivt kunne levere forskjellige versjoner av samme nettsted til forskjellige enheter. Alt uten \u00e5 utvikle et eget mobilnettsted p\u00e5 et annet domene.\n<\/p>\n
\n Nettstedseiere begynner \u00e5 innse at sluttbrukere bryr seg om ytelse. Spesielt forhandlere begynner \u00e5 forst\u00e5 at barbering av millisekunder av lastetid kan oversettes til millioner p\u00e5 balansen.\n<\/p>\n
\n Heldigvis tilbyr responsive nettsteder \u00e9n klar ytelsesfordel i forhold til deres dedikerte mobile fettere: viderekoblingen til et mobildomene er eliminert.\n<\/p>\n
\n Til tross for dette har responsiv design klart \u00e5 skaffe seg litt rykte for d\u00e5rlig ytelse.\n<\/p>\n
\n P\u00e5 noen m\u00e5ter er dette ganske urettferdig, men det er verdt \u00e5 se p\u00e5 de ekstra ytelsesutfordringene som responsiv design kommer p\u00e5 de uforsiktige…\n<\/p>\n
\n Bildefilene er store. Og fordi de er store, har de ofte skylden for trege lastetider. De er derfor et godt sted \u00e5 starte for alle som pr\u00f8ver \u00e5 optimalisere ytelsen til et nettsted.\n<\/p>\n
\n Dessverre var en av de f\u00f8rste l\u00f8sningene for \u00e5 levere bilder responsivt ikke bra for ytelsen.\n<\/p>\n
\n Teknikken er nydelig enkel. Bare bruk maks-bredde: 100 % for \u00e5 s\u00f8rge for at bildene skaleres til bredden p\u00e5 elementet som inneholder:\n<\/p>\n
img\n{\nmax-width: 100%;\n}<\/code><\/pre>\n\n Ettersom beholderen krymper for \u00e5 passe til mindre visningsporter, vil alle bilder inni krympe med den. Lett!\n<\/p>\n
\n Men det er et problem. St\u00f8rrelsen p\u00e5 bildet kan krympe p\u00e5 skjermen, men st\u00f8rrelsen p\u00e5 filen forblir den samme. Dette er langt fra ideelt sett fra et ytelsessynspunkt. Du kan sende et bilde p\u00e5 800 x 800 piksler nedover ledningen, bare for at det skal vises i 80 x 80 piksler: med andre ord, du kan overf\u00f8re hundrevis (eller tusenvis) av un\u00f8dvendige bytes. Ikke bare vil bildet ta lang tid \u00e5 laste, alle de overfl\u00f8dige bytene kan t\u00f8mme sluttbrukerens verdifulle datakvote.\n<\/p>\n
\n Dette er imidlertid ikke den eneste \u2013 og heller ikke den beste \u2013 m\u00e5ten \u00e5 levere responsive bilder p\u00e5. For det f\u00f8rste vil ikke et bilde som fungerer med 800 piksler i bredden n\u00f8dvendigvis fungere like bra i forskjellige deler av den st\u00f8rrelsen.\n<\/p>\n
\n For \u00e5 h\u00e5ndtere dette kan du bruke en mediesp\u00f8rring til \u00e5 vise forskjellige versjoner av bildet avhengig av visningsportens st\u00f8rrelse ved \u00e5 bruke en mediesp\u00f8rring og vise: ingen.\n<\/p>\n
\n CSS:<\/strong>\n<\/p>\n@media (min-width: 601px) {\n#croppedImage\n{\ndisplay:none;\n}\n}\n@media (max-width: 600px) {\n#largeImage\n{\ndisplay:none;\n}\n}<\/code><\/pre>\n\n HTML:<\/strong>\n<\/p>\n<img id=\"largeImage\" width=\"400\" height=\"400\" alt=\"\" src=\"images\/largeImage.webp\" \/>\n<img id=\"croppedImage\" width=\"200\" height=\"200\" alt=\"\" src=\"images\/croppedImage.webp\" \/><\/code><\/pre>\n\n Dette lar deg vise forskjellige versjoner av et bilde, i stedet for bare det samme bildet i forskjellige st\u00f8rrelser. Den reduserer imidlertid ikke antall byte. Faktisk vil den totale sidest\u00f8rrelsen v\u00e6re st\u00f8rre, siden alle bildene vil bli lastet inn, enten de vises eller ikke.\n<\/p>\n
\n Et bedre alternativ \u2013 hvis det er praktisk \u2013 er \u00e5 bruke bakgrunnsbilder i stedet for <img src=\"https:\/\/inform.click\/wp-content\/uploads\/2024\/11\/inform.click\" \/><\/code>elementer. Dette er \u00e5 foretrekke fordi bilder referert til i CSS lastes bare hvis de brukes (s\u00e5 lenge de ikke er data-URIer):\n<\/p>\n@media (min-width: 601px) {\n#largeImage\n{\nwidth:400px;\nheight:400px;\nbackground-image:url(\/images\/largeImage.webp);\n}\n#croppedImage\n{\ndisplay:none;\n}\n}\n \n@media (max-width: 600px) {\n#croppedImage\n{\nwidth:200px;\nheight:200px;\nbackground-image:url(\/images\/croppedImage.webp);\n}\n#largeImage\n{\ndisplay:none;\n}\n}<\/code><\/pre>\n\n Dette fungerer bra: bes\u00f8kende laster bare ned bildene de trenger, n\u00e5r og n\u00e5r de trenger dem. Problemet er at det er uryddig og effektivt behandler innhold som stil. Som s\u00e5dan skaper det potensielt et vedlikeholdsproblem og kan ogs\u00e5 f\u00f8re til at viktige bilder blir ignorert av s\u00f8kemotorer.\n<\/p>\n
\n I stedet, hvorfor ikke bruke SVG (skalerbar vektorgrafikk): et bildeformat som skaleres av natur? SVG-bilder har ogs\u00e5 fordelen at de enkelt kan styles med CSS (se denne flotte oppl\u00e6ringen<\/a> om hvordan du gj\u00f8r SVG-er responsive med CSS). Dette er perfekt for ikoner og logoer, men du vil dessverre ikke kunne bruke SVG-er for bilder \u2013 for disse m\u00e5 du ty til rasterformater, som JPEG.\n<\/p>\n\n Et annet alternativ er \u00e5 bruke en av en rekke JavaScript-l\u00f8sninger for \u00e5 levere responsive bilder. Dette er en popul\u00e6r m\u00e5te \u00e5 gj\u00f8re det p\u00e5, men det legger til et nytt lag med kompleksitet. Dessuten, siden JavaScript blokkerer DOM-konstruksjon, har enhver l\u00f8sning som involverer JavaScript potensial til \u00e5 holde opp gjengivelsen. S\u00e5 selv om det er noen veldig smarte plugins der ute, bare ved \u00e5 introdusere JavaScript i ligningen, resignerer du til en viss grad med det minste av to onder.\n<\/p>\n
\n Inntil nylig var dette de eneste alternativene.\n<\/p>\n
\n N\u00e5 bringer imidlertid og- <source \/><\/code>elementene, og attributtene srcset og st\u00f8rrelser, endelig virkelig responsive bilder til nettet. Den nye spesifikasjonen begynner ogs\u00e5 \u00e5 f\u00e5 nettleserst\u00f8tte, med full st\u00f8tte i Chrome og Opera, og st\u00f8tte for oppl\u00f8sningsbytte i Safari. Inntil andre nettlesere fanger opp, finnes det en utmerket JavaScript- polyfill<\/a>.\n<\/p>\n\n I denne modige nye verdenen kan du bruke srcset til \u00e5 sette opp en liste over kandidatbilder som nettleseren kan velge mellom. Du kan deretter bruke en mediesp\u00f8rring i st\u00f8rrelsesattributtet for \u00e5 diktere st\u00f8rrelsen bildet skal vises med. Ved \u00e5 bruke elementet sammen med mediesp\u00f8rringer inne i ett eller flere elementer, kan du spesifisere et annet utvalg av bilder for forskjellige forhold (f.eks. for visningsporter opp til en viss bredde, bruk bilde a, b eller c, og for st\u00f8rre visningsporter, bruk bilde x, y eller z). Dette er nyttig hvis du trenger \u00e5 levere en besk\u00e5ret versjon av et bilde for brukere med sm\u00e5 skjermer.\n<\/p>\n