Få responsive nettsteder til å fungere

Det var en tid da du trygt kunne skille mellom en stasjonær nettside og en mobil nettside. Faktisk så mye at en hel bransje vokste opp rundt å gjenbruke skrivebordssider for mobil.

En stund var du ingen hvis du ikke hadde en egen mobilside på et eget domene. Så begynte ting å endre seg.

Mobilskjermer er forbedret til det ugjenkjennelige. Det samme gjorde mobilnettlesere. Nettbrett kastet et annet element inn i ligningen. 4G kom med. Retina-skjermer tilbød nye nivåer av klarhet for sluttbrukere.

Plutselig så grensen mellom desktop og mobil uklar ut.

Samtidig var det et økende mangfold i størrelsen og oppløsningen på stasjonære skjermer.

Og en økende hodepine for webdesignere.

Borte var de dagene da du bare måtte ta hensyn til en håndfull viewport-størrelser. Ting ble komplisert.

Heldigvis var hjelpen tilgjengelig i form av medieforespørsler og konseptet med responsiv design.

Takket være mediespørringer ble det mulig å variere stiler og layout – til og med innhold – avhengig av brukerens visningsportbredde og skjermoppløsning. Mediespørringer er selvfølgelig på ingen måte det eneste verktøyet i den responsive designerens trikspose, men det er rimelig å si at de danner grunnlaget for teknikken.

Dette var gode nyheter for mobil. Responsiv design betydde at du effektivt kunne levere forskjellige versjoner av samme nettsted til forskjellige enheter. Alt uten å utvikle et eget mobilnettsted på et annet domene.

Hva med ytelse?

Nettstedseiere begynner å innse at sluttbrukere bryr seg om ytelse. Spesielt forhandlere begynner å forstå at barbering av millisekunder av lastetid kan oversettes til millioner på balansen.

Heldigvis tilbyr responsive nettsteder én klar ytelsesfordel i forhold til deres dedikerte mobile fettere: viderekoblingen til et mobildomene er eliminert.

Til tross for dette har responsiv design klart å skaffe seg litt rykte for dårlig ytelse.

På noen måter er dette ganske urettferdig, men det er verdt å se på de ekstra ytelsesutfordringene som responsiv design kommer på de uforsiktige…

Bilder

Bildefilene er store. Og fordi de er store, har de ofte skylden for trege lastetider. De er derfor et godt sted å starte for alle som prøver å optimalisere ytelsen til et nettsted.

Dessverre var en av de første løsningene for å levere bilder responsivt ikke bra for ytelsen.

Teknikken er nydelig enkel. Bare bruk maks-bredde: 100 % for å sørge for at bildene skaleres til bredden på elementet som inneholder:

img
{
max-width: 100%;
}

Ettersom beholderen krymper for å passe til mindre visningsporter, vil alle bilder inni krympe med den. Lett!

Men det er et problem. Størrelsen på bildet kan krympe på skjermen, men størrelsen på filen forblir den samme. Dette er langt fra ideelt sett fra et ytelsessynspunkt. Du kan sende et bilde på 800 x 800 piksler nedover ledningen, bare for at det skal vises i 80 x 80 piksler: med andre ord, du kan overføre hundrevis (eller tusenvis) av unødvendige bytes. Ikke bare vil bildet ta lang tid å laste, alle de overflødige bytene kan tømme sluttbrukerens verdifulle datakvote.

Dette er imidlertid ikke den eneste – og heller ikke den beste – måten å levere responsive bilder på. For det første vil ikke et bilde som fungerer med 800 piksler i bredden nødvendigvis fungere like bra i forskjellige deler av den størrelsen.

For å håndtere dette kan du bruke en mediespørring til å vise forskjellige versjoner av bildet avhengig av visningsportens størrelse ved å bruke en mediespørring og vise: ingen.

CSS:

@media (min-width: 601px) {
#croppedImage
{
display:none;
}
}
@media (max-width: 600px) {
#largeImage
{
display:none;
}
}

HTML:

<img id="largeImage" width="400" height="400" alt="" src="images/largeImage.webp">
<img id="croppedImage" width="200" height="200" alt="" src="images/croppedImage.webp">

Dette lar deg vise forskjellige versjoner av et bilde, i stedet for bare det samme bildet i forskjellige størrelser. Den reduserer imidlertid ikke antall byte. Faktisk vil den totale sidestørrelsen være større, siden alle bildene vil bli lastet inn, enten de vises eller ikke.

Et bedre alternativ – hvis det er praktisk – er å bruke bakgrunnsbilder i <divs>stedet for <img>elementer. Dette er å foretrekke fordi bilder referert til i CSS lastes bare hvis de brukes (så lenge de ikke er data-URIer):

@media (min-width: 601px) {
#largeImage
{
width:400px;
height:400px;
background-image:url(/images/largeImage.webp);
}
#croppedImage
{
display:none;
}
}
 
@media (max-width: 600px) {
#croppedImage
{
width:200px;
height:200px;
background-image:url(/images/croppedImage.webp);
}
#largeImage
{
display:none;
}
}

Dette fungerer bra: besøkende laster bare ned bildene de trenger, når og når de trenger dem. Problemet er at det er uryddig og effektivt behandler innhold som stil. Som sådan skaper det potensielt et vedlikeholdsproblem og kan også føre til at viktige bilder blir ignorert av søkemotorer.

I stedet, hvorfor ikke bruke SVG (skalerbar vektorgrafikk): et bildeformat som skaleres av natur? SVG-bilder har også fordelen at de enkelt kan styles med CSS (se denne flotte opplæringen om hvordan du gjør SVG-er responsive med CSS). Dette er perfekt for ikoner og logoer, men du vil dessverre ikke kunne bruke SVG-er for bilder – for disse må du ty til rasterformater, som JPEG.

Et annet alternativ er å bruke en av en rekke JavaScript-løsninger for å levere responsive bilder. Dette er en populær måte å gjøre det på, men det legger til et nytt lag med kompleksitet. Dessuten, siden JavaScript blokkerer DOM-konstruksjon, har enhver løsning som involverer JavaScript potensial til å holde opp gjengivelsen. Så selv om det er noen veldig smarte plugins der ute, bare ved å introdusere JavaScript i ligningen, resignerer du til en viss grad med det minste av to onder.

Inntil nylig var dette de eneste alternativene.

Nå bringer imidlertid <picture>og- <source>elementene, og attributtene srcset og størrelser, endelig virkelig responsive bilder til nettet. Den nye spesifikasjonen begynner også å få nettleserstøtte, med full støtte i Chrome og Opera, og støtte for oppløsningsbytte i Safari. Inntil andre nettlesere fanger opp, finnes det en utmerket JavaScript- polyfill.

I denne modige nye verdenen kan du bruke srcset til å sette opp en liste over kandidatbilder som nettleseren kan velge mellom. Du kan deretter bruke en mediespørring i størrelsesattributtet for å diktere størrelsen bildet skal vises med. Ved å bruke <picture>elementet sammen med mediespørringer 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ørre visningsporter, bruk bilde x, y eller z). Dette er nyttig hvis du trenger å levere en beskåret versjon av et bilde for brukere med små skjermer.

Den nøyaktige detaljen om hvordan du bruker den nye syntaksen er utenfor rammen av denne artikkelen, men du kan finne en utmerket opplæring på alistapart.

Den eneste ulempen med denne nye spesifikasjonen er kanskje at den er ganske langdrakt, noe som kan bety oppblåst HTML på sider med mange bilder. Imidlertid er fordelene langt større enn ulempene.

Laster CSS du ikke (nødvendigvis) trenger

Selv om mediespørringer lar deg bruke forskjellige CSS-regler avhengig av kriteriene du har satt, er det ingen vei utenom det faktum at sluttbrukere må laste ned all CSS som kan gjelde. Dette gjelder selv om du legger CSS-en din i separate filer og plasserer mediespørringen din i elementet <link>.

For eksempel vil begge de følgende stilarkene lastes, uavhengig av visningsportens bredde:

<link rel="stylesheet" media="(max-width: 600px)" href="css/style1.css">
<link rel="stylesheet" media="(min-width: 601px)" href="css/style2.css">

Dette er ikke en nettleserfeil. Kriteriene som brukes i mediesøk relaterer seg ofte til ting som endres under et besøk på en side. For eksempel kan en besøkende bestemme seg for å endre størrelse på nettleservinduet eller rotere nettbrettet/mobilenheten. Den resulterende endringen i visningen skal være sømløs, og å avfyre ​​en forespørsel om en annen CSS-fil ville være langt fra ideelt. Dette gjelder spesielt for mobile enheter, som ser ut til å lukke radioforbindelser så tidlig som mulig for å bevare batteristrømmen. Potensielt å måtte reetablere den koblingen når visningsportstørrelsen endres, kan være dårlige nyheter for batterilevetiden.

Chrome gjør imidlertid en innsats for å håndtere disse forskjellige filene på en intelligent måte. Mens alle filene vil bli lastet ned, vil bare den med det aktuelle mediesøket blokkere gjengivelsen. Eventuelle andre vil lastes med lavere prioritet.

Dessverre er ikke andre nettlesere fullt så forpliktende. I Firefox, for eksempel, blokkerer ubrukte CSS-filer ikke bare gjengivelse – de blokkerer også lasting av andre objekter på siden.

Fossdiagrammet nedenfor illustrerer poenget. Bildene på denne siden begynner ikke å lastes før den ubrukte CSS-filen er lastet ned fullstendig:

Du kan omgå dette ved å bruke JavaScript for å laste CSS betinget, men som vi allerede har sett, har JavaScript sine egne ytelseskostnader.

Hva betyr alt dette for ytelsen til et responsivt nettsted versus et mobilnettsted?

Vel, mobilbrukere og desktop-brukere på et responsivt nettsted må laste ned samme CSS.

Og det kommer til å være mer av det enn det ville vært på et nettsted designet bare for datamaskin eller mobil.

Dessuten er det mer sannsynlig at et dedikert mobilnettsted bruker en lettere, nedstrippet versjon av stasjonær CSS (selv om dette kanskje er mindre sant nå, ettersom brukere vokser til å forvente en rikere opplevelse på stadig mer sofistikerte mobilskjermer).

Så andre ting er like, det ser ut som om det er noe i argumentet om at en respons sannsynligvis vil være tregere enn en mobilside på grunn av den ekstra CSS som kreves. Men så lenge designere er klar over de potensielle fallgruvene, bør de være i stand til å lage hurtiglastende stilark for et responsivt nettsted. Spesielt er det en god idé å:

• unngå å bruke data-URIer for bilder – binære bakgrunnsbilder vil (normalt) bare lastes inn hvis/når de er nødvendig, men alle data-URIer vil bli lastet uansett.
• hold det lett – siden all CSS må lastes ned, er det viktig å være effektiv. Dette betyr å unngå duplisering og sørge for at globale regler settes utenfor den mediesøk-drevne CSS-en.

RESS (responsiv webdesign + serversidekomponenter)

RESS er en hybrid mellom responsiv og adaptiv design, som innebærer at brukeragent snuser på serveren for å se på egenskapene til klientenheten og levere innhold som passer til den.

Hvis en av innvendingene mot responsiv design er at det innebærer å levere alt innhold til alle enheter, hvorfor ikke redusere dette ved å kutte ut noe av innholdet der du kan?

Dette kan gi mye mening. Hvis det er et bilde du vet at du aldri vil vise på enheter hvis skjerm er under en viss størrelse, kan du like gjerne ikke sende det til disse enhetene, noe som sparer båndbredde og reduserer lastetiden.

Dessuten, hvis du bruker mediespørringer som du vet umulig kan tilfredsstilles på visse enheter, er det i det minste et argument for å dele CSS-en din i forskjellige filer og laste dem betinget.

Det er verdt å huske på at hele denne prosessen ikke er "gratis" når det gjelder ytelse. Noe arbeid må åpenbart utføres på serveren, noe som tar tid – sannsynligvis ikke nok til å oppveie fordelene, men det er noe å være klar over.

Dommen

Er responsive nettsteder trege?

Det kommer an på hva du mener med sakte.

Er det sannsynlig at det raskeste responsive nettstedet du kan lage er tregere enn det raskeste dedikerte mobilnettstedet du kan lage?

Sannsynligvis.

Vi har også sett at det er noen fallgruver. Hvis du ikke er forsiktig, er det lett å ende opp med å tvinge brukere til å laste ned mange overflødige bilder og CSS, noe som gjør det responsive nettstedet ditt mye tregere enn det trenger å være.

Det trenger imidlertid ikke være slik. Det er fullt mulig å lage et responsivt nettsted som er like raskt som det trenger å være og som gir en utmerket brukeropplevelse. Og etter hvert som både standarder og nettlesere begynner å fange opp med hva utviklerne ønsker å levere, bør det begynne å bli enklere.