Reageerivate veebisaitide toimimine

Oli aeg, mil sai enesekindlalt vahet teha lauaarvuti veebilehe ja mobiilse veebilehe vahel. Tegelikult nii palju, et töölauasaitide mobiilseadmete jaoks muutmise ümber kasvas terve tööstusharu.

Mõnda aega polnud te keegi, kui teil polnud eraldi domeenis eraldi mobiilisaiti. Siis hakkasid asjad muutuma.

Mobiiliekraanid on tundmatuseni paranenud. Nii ka mobiilibrauserid. Tahvelarvutid viskasid võrrandisse veel ühe elemendi. 4G tuli kaasa. Retina ekraanid pakkusid lõppkasutajatele uut selgust.

Järsku tundus piir lauaarvuti ja mobiili vahel hägune.

Samal ajal kasvas töölauakuvarite suuruse ja eraldusvõime mitmekesisus.

Ja kasvav peavalu veebidisaineritele.

Möödas olid ajad, mil pidid rahuldama vaid käputäie vaateava suurusi. Asjad läksid keeruliseks.

Õnneks oli abi käepärast meediapäringute ja reageeriva disaini kontseptsiooni näol.

Tänu meediapäringutele sai võimalikuks muuta stiile ja paigutust – isegi sisu – olenevalt kasutaja vaateava laiusest ja ekraani eraldusvõimest. Muidugi pole meediapäringud kaugeltki ainuke tööriist reageeriva disaineri trikkide kotis, kuid võib öelda, et need on tehnika aluseks.

See oli mobiili jaoks suurepärane uudis. Tundlik disain tähendas, et saate tõhusalt edastada sama saidi erinevaid versioone erinevatesse seadmetesse. Seda kõike ilma eri domeenil eraldi mobiilisaiti arendamata.

Aga jõudlus?

Saidiomanikud on hakanud mõistma, et lõppkasutajad hoolivad jõudlusest. Eelkõige on jaemüüjad hakanud mõistma, et laadimisaja millisekundite vähendamine võib bilansis tähendada miljoneid.

Õnneks pakuvad reageerivad saidid oma mobiilsete nõbude ees selget jõudluse eelist: ümbersuunamine mobiilidomeenile on välistatud.

Sellele vaatamata on tundlik disain saavutanud vähese jõudluse maine.

Mõnes mõttes on see üsna ebaõiglane, kuid tasub vaadata täiendavaid jõudlusprobleeme, mis tulenevad tundlikust disainist ettevaatlikumatele…

Pildid

Pildifailid on suured. Ja kuna need on suured, on nad sageli süüdi aeglastes laadimisaegades. Seetõttu on need hea koht alustamiseks kõigile, kes üritavad saidi toimivust optimeerida.

Kahjuks ei olnud üks esimesi lahendusi piltide tundlikuks edastamiseks jõudluse jaoks suurepärane.

Tehnika on ilusti lihtne. Kasutage lihtsalt max-width: 100%, et veenduda, et pildid skaleeruvad sisaldava elemendi laiusega:

img
{
max-width: 100%;
}

Kui konteiner kahaneb, et see sobiks väiksemate vaateavade jaoks, kahanevad kõik sees olevad pildid koos sellega. Lihtne!

Aga seal on probleem. Kujutise suurus võib ekraanil kahaneda, kuid faili suurus jääb samaks. See pole jõudluse seisukohast kaugeltki ideaalne. Võite saata 800 x 800 pikslise kujutise mööda traati, ainult selleks, et see kuvatakse 80 x 80 piksliga: teisisõnu võite edastada sadu (või tuhandeid) mittevajalikke baite. Pildi laadimine ei võta mitte ainult kaua aega, vaid kõik need üleliigsed baidid võivad lõppkasutaja väärtuslikku andmemahtu ammendada.

See pole aga ainus – ega isegi mitte parim – viis tundlike piltide edastamiseks. Esiteks, pilt, mis töötab laiusega 800 pikslit, ei pruugi selle suuruse erinevate osade puhul nii hästi töötada.

Selle lahendamiseks saate kasutada meediumipäringut, et kuvada kujutise erinevad versioonid sõltuvalt vaateava suurusest, kasutades meediumipäringut ja kuva: pole.

CSS:

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

HTML:

See võimaldab teil kuvada pildi erinevaid versioone, mitte ainult sama pilti erinevates suurustes. See aga ei vähenda baitide arvu. Tegelikult on lehe üldine suurus suurem, kuna kõik pildid laaditakse olenemata sellest, kas neid kuvatakse või mitte.

Parem alternatiiv – kui see on praktiline – on kasutada elementide asemel taustapilte. See on eelistatav, kuna CSS-is viidatud kujutised laaditakse ainult siis, kui neid kasutatakse (kui need pole andme-URI-d):

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

See toimib hästi: külastajad laadivad alla ainult neid pilte, mida nad vajavad, just siis, kui nad neid vajavad. Probleem on selles, et see on korrastamata, käsitledes sisu tõhusalt stiilina. Sellisena võib see tekitada hooldusprobleeme ja põhjustada ka selle, et otsingumootorid eiravad olulisi pilte.

Selle asemel, miks mitte kasutada SVG-d (skaleeritav vektorgraafika): pildivorming, mis skaleerub oma olemuselt? SVG-piltide eeliseks on ka see, et neid saab CSS-iga hõlpsasti kujundada (vaadake seda suurepärast õpetust, kuidas muuta SVG-d CSS-iga reageerivaks). See sobib suurepäraselt ikoonide ja logode jaoks, kuid kahjuks ei saa te fotode jaoks SVG-sid kasutada – selleks peate kasutama rastervorminguid, näiteks JPEG.

Teine võimalus on kasutada reageerivate piltide edastamiseks ühte paljudest JavaScripti lahendustest. See on populaarne viis seda teha, kuid see lisab veel ühe keerukuse kihi. Veelgi enam, kuna JavaScript blokeerib DOM-i konstrueerimise, võib iga JavaScripti hõlmav lahendus renderdamist takistada. Ehkki seal on mõned väga nutikad pistikprogrammid, ainuüksi võrrandisse JavaScripti lisamisega nõustute mingil määral kahest kurjast väiksemaga.

Kuni viimase ajani olid need ainsad võimalused.

Nüüd aga toovad elemendid ja ning atribuudid srcset ja sizes lõpuks veebi tõeliselt tundlikud pildid. Uus spetsifikatsioon hakkab saama ka brauseri tuge, millel on täielik tugi Chrome’is ja Operas ning eraldusvõime vahetamise tugi Safaris. Kuni teised brauserid järele ei jõua, on olemas suurepärane JavaScripti polüfill.

Selles vapper uues maailmas saate kasutada srcsetit, et koostada brauseri jaoks valitud piltide loend. Seejärel saate atribuudis sizes kasutada meediumipäringut, et määrata, millises suuruses kujutist kuvatakse. Kasutades elementi koos meediumipäringutega ühes või mitmes elemendis, saate erinevate tingimuste jaoks määrata erineva pildivahemiku (nt kuni teatud laiusega vaateavade jaoks kasutage pilti a, b või c ja suuremate vaateavade jaoks pilti x, y või z). See on kasulik, kui peate väikese ekraaniga kasutajatele edastama pildi kärbitud versiooni.

Uue süntaksi kasutamise täpsed üksikasjad ei kuulu selle artikli ulatusse, kuid suurepärase õpetuse leiate aadressilt alistapart.

Võib-olla on selle uue spetsifikatsiooni ainsaks puuduseks see, et see on üsna pikk, mis võib tähendada HTML-i ülepaisumist lehtedel, kus on palju pilte. Kuid eelised kaaluvad oluliselt üles puudused.

CSS-i laadimine, mida te (tingimata) ei vaja

Kuigi meediumipäringud võimaldavad teil sõltuvalt teie seatud kriteeriumidest rakendada erinevaid CSS-i reegleid, ei saa te sellest mööda, et lõppkasutajad peavad alla laadima kõik CSS-i, mis võivad kehtida. See kehtib isegi siis, kui panete oma CSS-i eraldi failidesse ja asetate oma meediumipäringu sellesse

elementi.

Näiteks laaditakse olenemata vaateava laiusest mõlemad järgmised laadilehed:

See ei ole brauseri viga. Meediapäringutes kasutatavad kriteeriumid on sageli seotud asjadega, mis lehe külastuse ajal muutuvad. Näiteks võib külastaja otsustada brauseriakna suurust muuta või tahvelarvutit/mobiilseadet pöörata. Sellest tulenev kuvamuutus peaks olema sujuv ja teise CSS-faili päringu käivitamine poleks kaugeltki ideaalne. See kehtib eriti mobiilseadmete kohta, mis soovivad aku säästmiseks raadiolingid esimesel võimalusel sulgeda. Võimalik, et selle lingi taasloomine, kui vaateava suurus muutub, võib olla halb uudis aku kasutusaega.

Chrome püüab aga neid erinevaid faile arukalt käsitleda. Kuigi kõik failid laaditakse alla, blokeerib renderdamise ainult see, millel on praegu sobiv meediumipäring. Kõik teised laaditakse madalama prioriteediga.

Kahjuks pole teised brauserid nii kohusetundlikud. Näiteks Firefoxis ei blokeeri kasutamata CSS-failid ainult renderdamist, vaid blokeerivad ka muude lehel olevate objektide laadimise.

Allolev juga diagramm illustreerib asja. Sellel lehel olevaid pilte ei hakata laadima enne, kui kasutamata CSS-fail on täielikult alla laaditud:

Saate sellest mööda hiilida, kui kasutate CSS-i tingimuslikuks laadimiseks JavaScripti, kuid nagu oleme juba näinud, kaasnevad JavaScriptiga oma jõudluskulud.

Mida see kõik tähendab reageeriva saidi ja mobiilisaidi toimivuse jaoks?

Noh, tundliku saidi mobiilikasutajad ja lauaarvutite kasutajad peavad alla laadima sama CSS-i.

Ja seda saab olema rohkem kui ainult lauaarvutitele või mobiilidele mõeldud saidil.

Veelgi enam, spetsiaalne mobiilisait kasutab tõenäolisemalt lauaarvuti CSS-i kergemat ja vähendatud versiooni (kuigi praegu on see võib-olla vähem tõsi, kuna kasutajad ootavad üha keerukamatel mobiiliekraanidel rikkalikumat kogemust).

Seega, kui muud tegurid on võrdsed, näib olevat midagi selles argumendis, et reageeriv sait on tõenäoliselt aeglasem kui mobiilisait, kuna on vaja täiendavat CSS-i. Kuid seni, kuni disainerid on võimalikest lõksudest teadlikud, peaksid nad suutma luua tundliku saidi jaoks kiiresti laaditavaid stiililehti. Eelkõige on hea mõte:

• vältige andmete URI-de kasutamist piltide jaoks – binaarsed taustpildid laaditakse (tavaliselt) ainult siis, kui neid vaja on, kuid kõik andme-URI-d laaditakse sellest hoolimata.
• hoidke seda kergelt – kuna kõik CSS-id tuleb alla laadida, on oluline olla tõhus. See tähendab dubleerimise vältimist ja globaalsete reeglite seadmist väljaspool meediumipäringupõhist CSS-i.

RESS (tundlik veebidisain + serveripoolsed komponendid)

RESS on reageeriva ja adaptiivse disaini hübriid, mis hõlmab kasutajaagendi nuusutamist serveris, et vaadata kliendi seadme omadusi ja edastada sellele sobivat sisu.

Kui üks vastuväiteid tundlikule disainile on see, et see hõlmab kogu sisu edastamist kõikidesse seadmetesse, siis miks mitte leevendada seda, lõigates võimalusel osa sellest sisust välja?

Sellel võib olla palju mõtet. Kui teate, et teil on pilt, mida te ei soovi kunagi kuvada seadmetes, mille ekraan on alla teatud suuruse, võite sama hästi jätta seda nendesse seadmetesse saatmata, säästes ribalaiust ja lühendades laadimisaega.

Veelgi enam, kui kasutate meediumipäringuid, mida teate, et teatud seadmetes ei saa rahuldada, on vähemalt argument CSS-i eraldamiseks erinevateks failideks ja nende tingimuslikuks laadimiseks.

Tasub meeles pidada, et kogu see protsess ei ole jõudluse mõttes "tasuta". Ilmselgelt tuleb serveris mõningaid töid teha, mis võtab aega – ilmselt mitte piisavalt, et kasu üles kaaluda, kuid sellega tasub arvestada.

Kohtuotsus

Kas reageerivad saidid on aeglased?

Oleneb, mida sa mõtled aeglase all.

Kas kõige kiiremini reageeriv sait, mille saate teha, on tõenäoliselt aeglasem kui kiireim spetsiaalne mobiilisait, mille saate luua?

Tõenäoliselt.

Oleme ka näinud, et on mõned lõksud. Kui te ei ole ettevaatlik, on lihtne sundida kasutajaid alla laadima palju üleliigseid pilte ja CSS-i, muutes teie tundliku saidi palju aeglasemaks, kui see peaks olema.

Siiski ei pea see nii olema. On täiesti võimalik luua tundlik sait, mis on nii kiire kui vaja ja pakub suurepärast kasutuskogemust. Ja kuna nii standardid kui ka brauserid hakkavad järele jõudma sellele, mida arendajad soovivad pakkuda, peaks see muutuma lihtsamaks.