Responsiivisten verkkosivustojen tekeminen toimiviksi

Oli aika, jolloin pystyit luotettavasti erottamaan pöytätietokoneen verkkosivun mobiilisivusta. Itse asiassa niin paljon, että koko toimiala kasvoi työpöytäsivustojen uudelleenkäytön ympärille mobiililaitteille.

Jonkin aikaa et ollut kukaan, jos sinulla ei ollut erillistä mobiilisivustoa erillisessä verkkotunnuksessa. Sitten asiat alkoivat muuttua.

Mobiilinäytöt paranivat huomaamatta. Samoin mobiiliselaimet. Tabletit heittivät yhtälöön toisen elementin. 4G tuli mukaan. Retina-näytöt tarjosivat uusia selkeyden tasoja loppukäyttäjille.

Yhtäkkiä pöytäkoneen ja mobiililaitteen välinen raja näytti epäselvältä.

Samaan aikaan pöytätietokoneiden näyttöjen koko ja resoluutio vaihteli.

Ja kasvava päänsärky verkkosuunnittelijoille.

Takana olivat ajat, jolloin piti ottaa huomioon vain kourallinen kuvaportin kokoa. Asiat muuttuivat monimutkaisiksi.

Onneksi apua oli saatavilla mediakyselyjen ja reagoivan suunnittelun konseptin muodossa.

Mediakyselyiden ansiosta tyylejä ja asettelua – jopa sisältöä – oli mahdollista vaihdella käyttäjän näkymän leveyden ja näytön resoluution mukaan. Mediakyselyt eivät tietenkään ole ainoa työkalu reagoivan suunnittelijan temppupussissa, mutta on reilua sanoa, että ne muodostavat tekniikan perustan.

Tämä oli loistava uutinen mobiililaitteille. Responsiivinen suunnittelu tarkoitti, että pystyit toimittamaan tehokkaasti saman sivuston eri versioita eri laitteille. Kaikki ilman erillistä mobiilisivustoa eri verkkotunnukselle.

Entä suorituskyky?

Sivuston omistajat alkavat ymmärtää, että loppukäyttäjät välittävät suorituskyvystä. Etenkin vähittäiskauppiaat alkavat ymmärtää, että millisekuntien latauksen poistaminen voi johtaa miljooniin taseeseen.

Onneksi responsiiviset sivustot tarjoavat yhden selkeän suorituskyvyn edun omistautuneisiin mobiiliserkkuihinsa verrattuna: uudelleenohjaus mobiiliverkkotunnukseen on eliminoitu.

Tästä huolimatta responsiivinen suunnittelu on kuitenkin onnistunut saamaan jonkin verran mainetta huonosta suorituskyvystä.

Jollain tapaa tämä on melko epäreilua, mutta on syytä tarkastella ylimääräisiä suorituskykyhaasteita, joita reagoiva suunnittelu aiheuttaa varomattomille…

Kuvat

Kuvatiedostot ovat suuria. Ja koska ne ovat suuria, ne ovat usein syyllisiä hitaisiin latausaikoihin. Siksi ne ovat hyvä paikka aloittaa jokaiselle, joka yrittää optimoida sivuston suorituskykyä.

Valitettavasti yksi ensimmäisistä ratkaisuista kuvien toimittamiseen responsiivisesti ei ollut loistava suorituskyvyn kannalta.

Tekniikka on ihanan yksinkertainen. Käytä vain enimmäisleveyttä: 100 % varmistaaksesi, että kuvat skaalautuvat sisältävän elementin leveyteen:

img
{
max-width: 100%;
}

Kun säiliö kutistuu sopimaan pienempiin kuvaportteihin, kaikki sisällä olevat kuvat kutistuvat sen mukana. Helppo!

Mutta siinä on ongelma. Kuvan koko saattaa pienentyä näytöllä, mutta tiedoston koko pysyy samana. Tämä on kaukana ihanteellisesta suorituskyvyn näkökulmasta. Saatat lähettää 800 x 800 pikselin kuvan johtoa pitkin vain, jotta se näytetään 80 x 80 pikselinä: toisin sanoen saatat lähettää satoja (tai tuhansia) tarpeettomia tavuja. Sen lisäksi, että kuvan lataaminen kestää kauan, kaikki nämä ylimääräiset tavut voivat kuluttaa loppukäyttäjän arvokasta datamäärää.

Tämä ei kuitenkaan ole ainoa – eikä edes paras – tapa tuottaa responsiivisia kuvia. Ensinnäkin kuva, joka toimii 800 pikseliä leveänä, ei välttämättä toimi yhtä hyvin tämän koon eri murto-osilla.

Tämän ratkaisemiseksi voit käyttää mediakyselyä kuvan eri versioiden näyttämiseen näyttöportin koosta riippuen käyttämällä mediakyselyä ja näyttöä: ei mitään.

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">

Näin voit näyttää kuvan eri versioita saman kuvan eri kokojen sijaan. Se ei kuitenkaan vähennä tavujen määrää. Itse asiassa sivun kokonaiskoko on suurempi, koska kaikki kuvat ladataan riippumatta siitä, näytetäänkö ne vai eivät.

Parempi vaihtoehto – jos se on käytännöllistä – on käyttää taustakuvia elementtien <divs>sijaan. <img>Tämä on suositeltavaa, koska CSS:ssä viitatut kuvat ladataan vain, jos niitä käytetään (niin kauan kuin ne eivät ole data-URI:ita):

@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;
}
}

Tämä toimii hyvin: vierailijat lataavat vain tarvitsemansa kuvat, milloin ja milloin he tarvitsevat niitä. Ongelmana on, että se on epäsiisti ja käsittelee sisältöä tehokkaasti tyylinä. Sellaisenaan se saattaa aiheuttaa ylläpidettävyysongelman ja saattaa myös johtaa siihen, että hakukoneet jättävät huomioimatta tärkeitä kuvia.

Mikset sen sijaan käyttäisi SVG:tä (skaalautuva vektorigrafiikka): kuvamuoto, joka skaalautuu luonnostaan? SVG-kuvilla on myös se etu, että ne on helppo muotoilla CSS:n avulla (katso tämä loistava opetusohjelma SVG-tiedostojen tekemisestä reagoiviksi CSS:n avulla). Tämä sopii mainiosti kuvakkeille ja logoille, mutta valitettavasti et voi käyttää SVG-tiedostoja valokuviin – näitä varten sinun on turvauduttava rasterimuotoihin, kuten JPEG.

Toinen vaihtoehto on käyttää yhtä useista JavaScript-ratkaisuista reagoivien kuvien toimittamiseen. Tämä on suosittu tapa tehdä se, mutta se lisää toisen kerroksen monimutkaisuutta. Lisäksi koska JavaScript estää DOM-rakentamisen, mikä tahansa JavaScriptiä käyttävä ratkaisu voi hidastaa renderöintiä. Joten vaikka siellä on joitain erittäin fiksuja laajennuksia, vain lisäämällä JavaScriptin yhtälöön, olet jossain määrin alistumassa pienempään kahdesta pahasta.

Viime aikoihin asti nämä olivat ainoat vaihtoehdot.

Nyt kuitenkin elementit <picture>ja <source>sekä attribuutit srcset ja sizes tuovat vihdoin todella reagoivia kuvia verkkoon. Uusi spesifikaatio alkaa myös saada selaintukea, sillä se tukee täysin Chromea ja Operaa ja tukee resoluution vaihtoa Safarissa. Kunnes muut selaimet saavat kiinni, on olemassa erinomainen JavaScript- polyfill.

Tässä rohkeassa uudessa maailmassa voit käyttää srcsetiä luettelon kuvista, joista selain voi valita. Voit sitten käyttää mediakyselyä sizes-attribuutissa määrittääksesi koon, jolla kuva näytetään. Käyttämällä <picture>elementtiä yhdessä mediakyselyjen kanssa yhden tai useamman elementin sisällä, voit määrittää erilaisen kuvaalueen eri olosuhteisiin (esim. tiettyyn leveyteen asti käytä kuvaa a, b tai c ja suurempiin kuvaportteihin kuvaa. x, y tai z). Tämä on hyödyllistä, jos sinun on toimitettava kuvasta rajattu versio käyttäjille, joilla on pieni näyttö.

Tarkat yksityiskohdat uuden syntaksin käytöstä eivät kuulu tämän artikkelin piiriin, mutta löydät erinomaisen opetusohjelman osoitteessa alistapart.

Ehkä tämän uuden määrityksen ainoa haittapuoli on, että se on melko pitkäveteinen, mikä voi tarkoittaa paisunutta HTML-koodia sivuilla, joilla on paljon kuvia. Edut ovat kuitenkin paljon suuremmat kuin haitat.

Ladataan CSS:ää, jota et (välttämättä) tarvitse

Vaikka mediakyselyiden avulla voit soveltaa erilaisia ​​CSS-sääntöjä määrittämiesi kriteerien mukaan, loppukäyttäjien on ladattava kaikki mahdollisesti sovellettavat CSS-syötteet. Tämä pitää paikkansa, vaikka laittaisit CSS:n erillisiin tiedostoihin ja asetat mediakyselysi <link>elementtiin.

Esimerkiksi molemmat seuraavat tyylisivut ladataan näkymän leveydestä riippumatta:

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

Tämä ei ole selainvirhe. Mediakyselyissä käytetyt kriteerit liittyvät usein asioihin, jotka muuttuvat sivulla käynnin aikana. Vierailija voi esimerkiksi päättää muuttaa selainikkunan kokoa tai kääntää tablettiaan/mobiililaitettaan. Tuloksena olevan näytön muutoksen pitäisi olla saumaton, ja toisen CSS-tiedoston pyynnön laukaiseminen ei olisi kaikkea muuta kuin ihanteellinen. Tämä pätee erityisesti mobiililaitteisiin, jotka pyrkivät sulkemaan radiolinkit mahdollisimman pian akun virran säästämiseksi. Mahdollisesti linkin luominen uudelleen, kun näkymän koko muuttuu, voi olla huono uutinen akun käyttöiän kannalta.

Chrome pyrkii kuitenkin käsittelemään näitä eri tiedostoja älykkäästi. Vaikka kaikki tiedostot ladataan, vain tiedosto, jolla on tällä hetkellä vastaava mediakysely, estää renderöinnin. Kaikki muut latautuvat alhaisemmalla prioriteetilla.

Valitettavasti muut selaimet eivät ole yhtä velvoittavia. Esimerkiksi Firefoxissa käyttämättömät CSS-tiedostot eivät vain estä hahmonnusta – ne estävät myös sivun muiden objektien lataamisen.

Alla oleva vesiputouskaavio havainnollistaa asiaa. Tämän sivun kuvat eivät ala latautua ennen kuin käyttämätön CSS-tiedosto on ladattu kokonaan:

Voit kiertää tämän lataamalla CSS:n ehdollisesti JavaScriptillä, mutta kuten olemme jo nähneet, JavaScriptillä on omat suorituskykykustannukset.

Mitä tämä kaikki tarkoittaa reagoivan sivuston ja mobiilisivuston suorituskyvylle?

Responsiivisen sivuston mobiilikäyttäjien ja työpöytäkäyttäjien on ladattava sama CSS.

Ja sitä tulee olemaan enemmän kuin vain pöytäkoneille tai mobiililaitteille suunnitellulla sivustolla.

Lisäksi omistettu mobiilisivusto käyttää todennäköisemmin kevyempää, kevennettyä versiota työpöytätietokoneiden CSS:stä (vaikka tämä on ehkä vähemmän totta nyt, kun käyttäjät odottavat entistä monipuolisempaa kokemusta entistä kehittyneemmiltä mobiilinäytöiltä).

Jos muut asiat ovat samat, näyttää siltä, ​​​​että jokin väitteessä on, että reagoiva sivusto on todennäköisesti hitaampi kuin mobiilisivusto vaadittavan ylimääräisen CSS:n vuoksi. Kuitenkin niin kauan kuin suunnittelijat ovat tietoisia mahdollisista karikoista, heidän pitäisi pystyä luomaan nopeasti latautuvia tyylisivuja reagoivalle sivustolle. Erityisesti on hyvä idea:

• Vältä tietojen URI:iden käyttöä kuville – binaariset taustakuvat ladataan (normaalisti) vain, jos/kun niitä tarvitaan, mutta kaikki data-URI:t ladataan siitä huolimatta.
• pidä se kevyenä – koska kaikki CSS on ladattava, on tärkeää olla tehokas. Tämä tarkoittaa päällekkäisyyksien välttämistä ja sen varmistamista, että globaalit säännöt asetetaan mediakyselyyn perustuvan CSS:n ulkopuolelle.

RESS (responsiivinen verkkosuunnittelu + palvelinpuolen komponentit)

RESS on reagoivan ja mukautuvan suunnittelun hybridi, jossa käyttäjäagentti haistelee palvelimella asiakaslaitteen ominaisuuksien tarkastelemiseksi ja sille sopivan sisällön toimittamiseksi.

Jos yksi responsiivisen suunnittelun vastalauseista on, että siihen sisältyy kaiken sisällön toimittaminen kaikille laitteille, miksi et lieventäisi tätä leikkaamalla osan sisällöstä pois mahdollisuuksien mukaan?

Tässä voi olla paljon järkeä. Jos tiedät kuvan, jota et koskaan halua näyttää laitteissa, joiden näyttö on tietyn koon alapuolella, et voi yhtä hyvin olla lähettämättä sitä kyseisiin laitteisiin, mikä säästää kaistanleveyttä ja lyhentää latausaikaa.

Lisäksi, jos käytät mediakyselyitä, joiden tiedät, että ne eivät voi olla tyydyttäviä tietyillä laitteilla, on olemassa ainakin perustelu CSS:n erottamiselle eri tiedostoiksi ja niiden ehdolliseen lataamiseen.

On syytä pitää mielessä, että tämä koko prosessi ei ole "ilmainen" suorituskyvyn kannalta. Jotkin työt on luonnollisesti suoritettava palvelimella, mikä vie aikaa – luultavasti ei tarpeeksi painamaan etuja, mutta se on syytä olla tietoinen.

Tuomio

Ovatko reagoivat sivustot hitaita?

Riippuu mitä tarkoitat hitaalla.

Onko nopein reagoiva sivusto todennäköisesti hitaampi kuin nopein mobiilisivusto, jonka voit tehdä?

Todennäköisesti.

Olemme myös nähneet, että on olemassa muutamia sudenkuoppia. Jos et ole varovainen, käyttäjät on helppo pakottaa lataamaan paljon ylimääräisiä kuvia ja CSS:ää, mikä tekee reagoivasta sivustosta paljon hitaampaa kuin sen pitäisi olla.

Sen ei kuitenkaan tarvitse olla niin. On täysin mahdollista luoda responsiivinen sivusto, joka on aivan niin nopea kuin se on ja tarjoaa erinomaisen käyttökokemuksen. Ja kun sekä standardit että selaimet alkavat saada umpeen sitä, mitä kehittäjät haluavat tarjota, sen pitäisi alkaa helpottamaan.