Få responsiva webbplatser att fungera
Det fanns en tid när du med säkerhet kunde skilja mellan en datorwebbsida och en mobilwebbsida. Faktiskt så mycket att en hel industri växte upp kring att återanvända stationära webbplatser för mobila enheter.
Ett tag var du ingen om du inte hade en separat mobilsajt på en separat domän. Sedan började saker förändras.
Mobilskärmar förbättrade till oigenkännlighet. Det gjorde även mobila webbläsare. Tabletter kastade ett annat element in i ekvationen. 4G kom med. Retina-skärmar erbjöd nya nivåer av tydlighet för slutanvändare.
Plötsligt såg gränsen mellan stationär dator och mobil suddig ut.
Samtidigt ökade mångfalden i storlek och upplösning på skrivbordsskärmar.
Och en växande huvudvärk för webbdesigners.
De dagar då du bara behövde tillgodose en handfull utsiktsportstorlekar var förbi. Saker och ting började bli komplicerade.
Lyckligtvis fanns hjälp till hands i form av mediafrågor och konceptet med responsiv design.
Tack vare mediafrågor blev det möjligt att variera stilar och layout – även innehåll – beroende på användarens visningsportbredd och skärmupplösning. Naturligtvis är mediefrågor inte på något sätt det enda verktyget i den responsiva designerns trickspåse, men det är rimligt att säga att de ligger till grund för tekniken.
Detta var fantastiska nyheter för mobilen. Responsiv design innebar att du effektivt kunde leverera olika versioner av samma sajt till olika enheter. Allt utan att utveckla en separat mobilsajt på en annan domän.
Hur är det med prestanda?
Webbplatsägare börjar inse att slutanvändare bryr sig om prestanda. Särskilt återförsäljare börjar inse att rakning av millisekunders laddningstid kan översättas till miljoner på balansräkningen.
Lyckligtvis erbjuder responsiva webbplatser en tydlig prestandafördel jämfört med sina dedikerade mobila kusiner: omdirigeringen till en mobil domän elimineras.
Men trots detta har responsiv design lyckats skaffa sig lite rykte för dålig prestanda.
På vissa sätt är det här ganska orättvist, men det är värt att titta på de extra prestandautmaningarna som lyhörd design ger upphov till oförsiktiga…
Bilder
Bildfiler är stora. Och eftersom de är stora är de ofta skyldiga till långsamma laddningstider. De är därför ett bra ställe att börja för alla som försöker optimera en webbplatss prestanda.
Tyvärr var en av de första lösningarna för att leverera bilder responsivt inte bra för prestanda.
Tekniken är vackert enkel. Använd bara max-width: 100% för att se till att bilder skalas till bredden på det innehållande elementet:
img
{
max-width: 100%;
}När behållaren krymper för att passa mindre visningsportar, kommer alla bilder inuti att krympa med den. Lätt!
Men det finns ett problem. Storleken på bilden kan krympa på skärmen, men storleken på filen förblir densamma. Detta är långt ifrån idealiskt ur prestationssynpunkt. Du kan skicka en bild på 800 x 800 pixlar längs tråden, bara för att den ska visas i 80 x 80 pixlar: med andra ord, du kan sända hundratals (eller tusentals) onödiga byte. Det kommer inte bara ta lång tid att ladda bilden, alla dessa redundanta bytes kan tömma slutanvändarens värdefulla datatillåtelse.
Detta är dock inte det enda – och inte ens det bästa – sättet att leverera responsiva bilder. För det första, en bild som fungerar med 800 pixlar bred kommer inte nödvändigtvis att fungera lika bra i olika delar av den storleken.
För att hantera detta kan du använda en mediefråga för att visa olika versioner av bilden beroende på visningsportens storlek genom att använda en mediefråga och visa: 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">Detta gör att du kan visa olika versioner av en bild, snarare än bara samma bild i olika storlekar. Det minskar dock inte antalet byte. Faktum är att den övergripande sidstorleken blir större, eftersom alla bilder kommer att laddas, oavsett om de visas eller inte.
Ett bättre alternativ – om det är praktiskt – är att använda bakgrundsbilder i <divs>stället för <img>element. Detta är att föredra eftersom bilder som hänvisas till i CSS laddas endast om de används (så länge de inte är data-URI):
@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;
}
}Detta fungerar bra: besökare laddar bara ner de bilder de behöver, när och när de behöver dem. Problemet är att det är stökigt och effektivt behandlar innehåll som stil. Som sådan skapar det potentiellt ett underhållsproblem och kan också leda till att viktiga bilder ignoreras av sökmotorer.
Varför inte istället använda SVG (skalbar vektorgrafik): ett bildformat som skalas till sin natur? SVG-bilder har också fördelen att de enkelt kan stylas med CSS (se den här fantastiska handledningen om hur du gör SVG responsiva med CSS). Detta är perfekt för ikoner och logotyper, men tyvärr kommer du inte att kunna använda SVG:er för foton – för dessa måste du tillgripa rasterformat, som JPEG.
Ett annat alternativ är att använda en av ett antal JavaScript-lösningar för att leverera responsiva bilder. Detta är ett populärt sätt att göra det, men det lägger till ytterligare ett lager av komplexitet. Dessutom, eftersom JavaScript blockerar DOM-konstruktion, har alla lösningar som involverar JavaScript potentialen att hålla uppe renderingen. Så även om det finns några mycket smarta plugins där ute, bara genom att introducera JavaScript i ekvationen, överlåter du dig i viss mån till det minsta av två onda.
Tills nyligen var dessa de enda alternativen.
Nu, men elementen <picture>och <source>, och attributen srcset och sizes, ger äntligen verkligt responsiva bilder till webben. Den nya specifikationen börjar också få webbläsarstöd, med fullt stöd i Chrome och Opera, och stöd för upplösningsväxling i Safari. Tills andra webbläsare kommer ikapp finns det en utmärkt JavaScript -polyfill.
I denna modiga nya värld kan du använda srcset för att skapa en lista med kandidatbilder som webbläsaren kan välja från. Du kan sedan använda en mediefråga i storleksattributet för att diktera storleken på vilken bilden ska visas. Genom att använda <picture>elementet tillsammans med mediefrågor inuti ett eller flera element kan du specificera ett annat intervall av bilder för olika förhållanden (t.ex. för visningsportar upp till en viss bredd, använd bild a, b eller c, och för större visningsportar använd bild x, y eller z). Detta är användbart om du behöver leverera en beskuren version av en bild för användare med små skärmar.
Den exakta detaljen för hur man använder den nya syntaxen ligger utanför ramen för den här artikeln, men du kan hitta en utmärkt handledning på alistapart.
Den kanske enda nackdelen med den här nya specifikationen är att den är ganska långrandig, vilket kan innebära uppsvälld HTML på sidor med massor av bilder. Men fördelarna överväger vida nackdelarna.
Laddar CSS du inte (nödvändigtvis) behöver
Även om mediefrågor låter dig tillämpa olika CSS-regler beroende på de kriterier du har ställt in, går det inte att komma ifrån det faktum att slutanvändare måste ladda ner all CSS som kan gälla. Detta gäller även om du lägger din CSS i separata filer och placerar din mediefråga i <link>elementet.
Till exempel kommer båda följande stilmallar att laddas, oavsett visningsportens bredd:
<link rel="stylesheet" media="(max-width: 600px)" href="css/style1.css">
<link rel="stylesheet" media="(min-width: 601px)" href="css/style2.css">Detta är inte en webbläsarbugg. Kriterierna som används i mediefrågor relaterar ofta till saker som förändras under ett besök på en sida. En besökare kan till exempel välja att ändra storlek på webbläsarfönstret eller rotera sin surfplatta/mobilenhet. Den resulterande förändringen i visningen bör vara sömlös, och att avfyra en begäran om en annan CSS-fil skulle vara långt ifrån idealiskt. Detta gäller särskilt för mobila enheter, som försöker stänga radiolänkar så snart som möjligt för att bevara batterikraften. Att eventuellt behöva återupprätta den länken när visningsportens storlek ändras kan vara dåliga nyheter för batteritiden.
Men Chrome anstränger sig för att hantera dessa olika filer på ett intelligent sätt. Medan alla filer kommer att laddas ner, kommer bara den med den aktuella mediefrågan att blockera renderingen. Alla andra laddas med lägre prioritet.
Tyvärr är andra webbläsare inte riktigt lika förpliktiga. I Firefox, till exempel, blockerar oanvända CSS-filer inte bara rendering – de blockerar även laddningen av andra objekt på sidan.
Vattenfallsdiagrammet nedan illustrerar poängen. Bilderna på den här sidan börjar inte laddas förrän den oanvända CSS-filen har laddats ner helt:
Du kan komma runt detta genom att använda JavaScript för att ladda CSS villkorligt, men som vi redan har sett kommer JavaScript med sina egna prestandakostnader.
Vad betyder allt detta för prestanda för en responsiv webbplats kontra en mobilwebbplats?
Tja, mobilanvändare och stationära användare på en responsiv webbplats måste ladda ner samma CSS.
Och det kommer att finnas mer av det än vad det skulle vara på en webbplats som är designad enbart för dator eller mobil.
Dessutom är det mer sannolikt att en dedikerad mobilwebbplats använder en lättare, avskalad version av CSS för stationära datorer (även om detta kanske är mindre sant nu, eftersom användarna växer att förvänta sig en rikare upplevelse på allt mer sofistikerade mobilskärmar).
Så allt annat lika ser det ut som om det ligger något i argumentet att en responsiv sannolikt är långsammare än en mobilsajt på grund av den extra CSS som krävs. Men så länge designers är medvetna om de potentiella fallgroparna, bör de kunna skapa snabbladdade stilmallar för en responsiv webbplats. I synnerhet är det en bra idé att:
- undvik att använda data-URI för bilder – binära bakgrundsbilder laddas (normalt) endast om/när de behövs, men alla data-URI:er kommer att laddas oavsett.
- håll det lätt – eftersom all CSS måste laddas ner är det viktigt att vara effektiv. Detta innebär att undvika dubbelarbete och att se till att globala regler ställs utanför den mediefrågedrivna CSS.
RESS (Responsive Web Design + Server Side Components)
RESS är en hybrid mellan responsiv och adaptiv design, vilket innebär att användaragent sniffar på servern för att titta på egenskaperna hos klientenheten och leverera innehåll som passar den.
Om en av invändningarna mot responsiv design är att det innebär att leverera allt innehåll till alla enheter, varför inte mildra detta genom att skära bort en del av innehållet där du kan?
Detta kan vara mycket vettigt. Om det finns en bild som du vet att du aldrig kommer att vilja visa på enheter vars skärm är under en viss storlek, kan du lika gärna inte skicka den till dessa enheter, vilket sparar bandbredd och minskar laddningstiden.
Vad mer är, om du använder mediefrågor som du vet omöjligt kunde tillfredsställa på vissa enheter, finns det åtminstone ett argument för att separera din CSS i olika filer och ladda dem villkorligt.
Det är värt att komma ihåg att hela denna process inte är "gratis" i prestandatermer. En del arbete måste självklart utföras på servern, vilket tar tid – förmodligen inte tillräckligt för att uppväga fördelarna, men det är något att vara medveten om.
Domen
Är responsiva webbplatser långsamma?
Det beror på vad du menar med långsam.
Är den snabbaste responsiva webbplatsen du kan skapa sannolikt långsammare än den snabbaste dedikerade mobilsajten du kan skapa?
Förmodligen.
Vi har också sett att det finns några fallgropar. Om du inte är försiktig är det lätt att det slutar med att användare tvingas ladda ner en massa redundanta bilder och CSS, vilket gör din responsiva sida mycket långsammare än den behöver vara.
Det behöver dock inte vara så. Det är fullt möjligt att skapa en responsiv webbplats som är precis så snabb som den behöver vara och som ger en utmärkt användarupplevelse. Och när både standarder och webbläsare börjar komma ikapp vad utvecklarna vill leverera borde det börja bli enklare.