Nylig har jeg fått mange responsive nettsteder med mye av ytelsesproblemer. På de fleste av dem er problemene så tydelige at de nesten er ubrukelige på annet enn den nyeste generasjonen smarttelefoner. Tatt i betraktning det faktum at lydhørhet som et konsept er ment å nå en bredere publikum, virker dette ganske kontraproduktivt.

Den største bidragsyteren til dette problemet er det fremdeles utbredte desktop-første designparadigmet. Å tenke fra perspektivet til mobil-første ser ut til å løse problemet, men det alene garanterer ikke tilfredsstillende ytelse. Vi ser alle ut til å stole altfor mye på mer eller mindre grasiøs nedbrytning. Vi er avhengige av shims og polyfills for å muliggjøre manglende funksjonalitet. Vi stoler på biblioteker for å muliggjøre rask utvikling og å ha ryggen når nettleserkompatibilitet er et problem.

Telefonmordere løst, forkledd som responsive nettsteder. kvitring

'Hvorfor bekymre seg?' spør du kanskje. “De fleste av våre besøkende har smarttelefoner med de nyeste operativsystemversjonene. De kan håndtere nettstedene våre. Analysene forteller oss det. ”

Jeg beklager stråmannsargumentet, men jeg synes det fortjener å si høyt at de som kan bruk nettstedet ditt vil være flertallet av brukerne dine. Hvis du ikke ser Android 2.3 i analysene dine, betyr det at det ikke er noen brukere med disse enhetene? Eller betyr det at nettstedet ditt ikke har noe å tilby disse brukerne? Tenk på at mange enheter av den generasjonen fremdeles er i hyllene, og blir kjøpt helt nye også i dag. Du bør ikke avvise det direkte som en tidligere teknologi.

Derfor vil jeg gjerne snakke om de ideelle sakene og faktiske mål for nettutvikling. Og om praksis og paradigmer som får oss nærmere disse målene.

Tegl-første designparadigme

En betydelig del av det årlige telefonsalget tas fortsatt av funksjonstelefoner. En enda større andel av befolkningen kjøper ikke telefoner hvert år, men har likevel noen nettkompatible enheter i besittelse. Legg til disse tallene siste generasjons smarttelefoner som fortsatt er i bruk, legg til tennene og andre semi-kompatible enheter på nettet (WAP-enheter, TV-er, brødristere, t-skjorter og murstein). Legg dem sammen, så kan du oppnå en svimlende sum.

Du vil ikke se dem i analysene dine med mindre det fungerer der. kvitring

Tenk på brukssakene for dette publikummet. De kommer ikke til å lese lange artikler, bla gjennom og undersøke på enhetene sine. Men de kan gå gjennom gruene ved å prøve å skrive inn en URL på det numeriske tastaturet og navigere på siden ved hjelp av retningstaster for å komme til et telefonnummer eller dobbeltsjekke en adresse på farten.

Hvor vanskelig er det da for oss å implementere en sub-mobile-first layout som bare gir den informasjonen til enhetene under en viss terskel for evner og ytelse?

Grasiøs forbedring

Med grasiøs degradering som en minimumspraksis, har vi laget et prinsipp for fangst som (til en viss grad) hindrer tanker utover det. Når grasiøs nedbrytning er på plass, kan vi sikkert si at jobben vår er gjort og gjort bra. Oftere og oftere trenger vi ikke engang å tenke på det, da det allerede er dekket av de forskjellige rammene og bibliotekene som er i bruk. Og til slutt fjerner polyfills og shims behovet for funksjonalitetsnedbrytning i noen tilfeller.

Etter hvert som denne funksjonaliteten blir mer og mer tilgjengelig, blir behovet for å tenke på det (enn si det utover) mer og mer fjernt.

Fra synspunktet til denne artikkelen kan det brytes ned slik:

Ungraceful nedbrytning: Hvis en funksjon ikke er lett tilgjengelig, mislykkes implementeringen på en slik måte at den blir ubrukelig eller brukbar på en uoverkommelig praktisk måte.

Grasiøs nedbrytning: Hvis en funksjon ikke er lett tilgjengelig, mislykkes den på en måte som fremdeles muliggjør akseptabel brukervennlighet.

Ungraceful forbedring: Hvis funksjonen ikke er lett tilgjengelig, etterlignes den av en flerfylling eller shim.

Der, problemet løst.

Vel, med mindre du vurderer ytelsen til de samme low-end enhetene.

Manglende prosessorkraft og datafunksjoner til sine yngre søsken, blir de bedt om å bære mye større belastning. Å ta polyfills som en løsning skaper en illusjon om at alle moderne funksjoner nå er tilgjengelige på alle enheter og kan brukes uten bekymring.

Og så implementerer du modernisere og fyll ut alt bare i tilfelle. Den minst kompetente enheten ender med å laste inn den største mengden data og utføre den største mengden behandling. Dermed sikrer du den “beste” sluttbrukeropplevelsen.

Shiv, shim og polyfill? Takk og lov, de fleste smarttelefoner støtter ikke Flash! kvitring

Ideen om grasiøs forbedring ville reversere konseptet ved å starte med de laveste funksjonskravene og laste oppgraderinger til balansen mellom ytelse og brukervennlighet er optimal basert på enhetens evner. Dermed vil datatrafikk- og behandlingskravene bli flyttet til de enhetene som er best egnet til å håndtere dem.

Visst, for øyeblikket er konseptet uoverkommelig komplekst: det støttes ikke av de fleste rammeverk og biblioteker, det er for det meste ikke diskutert, og referanser til slik praksis er få, langt fra hverandre og lokalisert til mikrofunksjonaliteter. Men på et tidspunkt var det slik med alle konsepter og funksjoner.

Det kan, men må det?

En annen god praksis med nettutvikling er å sjekke om en funksjon er tilgjengelig på en enhet før du aktiverer den.

Ta imidlertid hensyn til at du kan installere den nyeste versjonen av Google Chrome på din år gamle Android-telefon, og den vil hevde at den kan kjøre CSS animasjoner , WebGL , bakgrunnsparallakseffekter og mange andre funksjoner. Men det virkelig, egentlig , kan ikke. Så mye at nettleseren krasjer, og hele enheten ikke reagerer på et punkt at den må startes på nytt for å gjenvinne kontrollen.

Dette problemet har nylig begynt å påvirke Android-applikasjoner på en stor måte (fra et brukerperspektiv). En av de mest merkbare degraderingene i denne forstand har påvirket Google Talk / Hangouts appoppgradering som har gjort tjenesten deres fra det letteste chat-programmet tilgjengelig til et nesten ubrukelig program på grunn av ytelsesproblemer på eldre enheter. (Bare for å understreke dette poenget en gang til: 'eldre' her betyr at du fremdeles kan kjøpe det helt fra hyllen, helt nytt i nesten alle butikker). Det samme problemet påvirket YouTube-appen og Twitter-appen (etter min erfaring) og tilsynelatende mange andre.

Så ta et øyeblikk på et eller annet tidspunkt i planleggingsfasen for å evaluere verdien av en kjernefunksjon med høy ytelse i forhold til banebrytende sminke. Eller i det minste la den siste generasjonen av appen / tjenesten / innholdet ditt være tilgjengelig i en eller annen form for eldre brukere. Når vi snakkar om det…

La brukerne velge bort fra blødningskanten

Har du noen gang funnet at du prøver å bruke Gmail fra en gammel enhet, eller over en dårlig forbindelse? At 'Last basic HTML' link sikkert kommer godt med.

Hvorfor har ikke din banebrytende, responsive, animerte, berøringsorienterte nettbutikk den funksjonaliteten?

Tenk på det: du ba om at det skulle være responsivt, slik at du kan nå flere potensielle kunder. Du gjorde det banebrytende for å gi det beste førsteinntrykket. Og som et resultat kan færre potensielle kunder nå til og med grunnleggende informasjon om deg og dine tjenester. Hvis grasiøs forbedring er et for kostbart konsept for deg, hvorfor ikke i det minste tilby de besøkende muligheten til å få tilgang til en tekstversjon av innholdet ditt hvis “WOW” -versjon er for mye for enhetene deres.

Trenger du virkelig hele biblioteket?

Til slutt er den siste beste fremgangsmåten jeg vil se presset litt utover standarden 'bruk den eller miste den'. Det er noen ganger kjedelig å holde rede på hvilke biblioteker og moduler som faktisk er i bruk, og bare inkludere dem, men å holde hele verktøysettet på hver side er bare slurvete.

Vanlig løgn fra det 21. århundre: bare noen få sekunder igjen. kvitring

Nylig har jeg tatt vare på hvor mye funksjonalitet jeg faktisk bruker når jeg inkluderer et bibliotek. Og verktøyet jeg bruker oftest er jQuery . Ofte finner jeg ut at jeg bare har brukt en eller to funksjoner (for eksempel $ .extend eller $ .ready), eller enda verre, at jeg har brukt den bare for å få elementer etter klasse eller ID. Noen ganger lar jeg det være slik, andre ganger går jeg tilbake gjennom koden for å fjerne eller koble avhengigheten.

Ville det ikke være pent om du automatisk kunne analysere hva og hvor mye av et bibliotek som til slutt ble brukt og gå ned i vekt basert på resultatene?

Mange biblioteker og applikasjoner tilbyr muligheten til å tilpasse belastningen før du begynner å bruke den. Men jeg fortsetter å ha denne følelsen av at det ikke burde være for langt utenfor vår rekkevidde å standardisere en automatisert 'bruk den eller miste den' -arkitekturen i bibliotekene våre.

Jeg har en allergi mot 'inkluder alt' -tilnærmingen. Men å bruke det i forbindelse med en slik funksjonalitet kan vende tilnærmingen til noe som ligner på et prototypingkort: et altfor fleksibelt utviklingsverktøy som blir minifisert ikke bare i syntaksen, men i selve funksjonaliteten.

Det som kreves er en bare utviklingsversjon av biblioteket som gjennom en enhetstest av avhengig funksjonalitet muliggjør sporing av brukte funksjoner og gir ut minimal avhengighet eller i det minste omfang av utnyttelse (for eksempel å spørre har jeg tatt med jQuery for 8% av funksjonaliteten eller 80%). Avhengighetsutgangen kan da brukes til å kirsebærplukke, samle og minimere produksjonen for produksjon.

Men hva kan jeg gjøre med det?

Først av alt, engasjere problemet . Tenk på det, diskuter det med jevnaldrende, og prøv å få øye på problemet i virkelige scenarier.

Prøv det. Grav ut den siste generasjonen telefonen du har stukket bort i en skuff et eller annet sted. Prøv å bruke den på dine egne nettsteder og sjekk om innholdet til og med kan brukes eksternt. Gå og besøk noen slektninger bak tiden som er ute i landet, og prøv å være en teknisk evangelist for dem. Se om deres forsinkelse i teknisk adopsjon faktisk blir lettere av tilgjengelighetsproblemer.

Hvis du er kjøper idriftsett et nettsted, sørg for å be om (i det minste) støtte på lavt nivå om dette problemet. Husk: Målet er ikke å lage en full port av alle funksjonene dine til enheter på lavt nivå. Alt som blir spurt er at disse brukerne får kontaktinformasjonen din i stedet for at enheten krasjer.

Sett av faktiske ressurser til dette: Den enkleste løsningen for problemet bør ikke ta mer enn en dag eller to, og noe fremover. Husk de mest grunnleggende grunnene til å lage nettstedet i utgangspunktet (enn si å lage et responsivt nettsted).

Hvis du er en pakkeutvikler arbeider med et bibliotek, rammeverk, pakke eller annen innebygd programvare: det er du som kan gjøre mest mulig forskjell her. Hvis du kan legge til rette for eller innlemme disse konseptene i plattformen din, påvirker du hele landskapet for nettutvikling. Hvis du tar det med i pakkeutformingen din, gi meg beskjed, så skal jeg evangelisere for deg.

Og til slutt, ** hvis du er en utvikler eller a designer** , ikke bare stopp ved beste praksis. Forsøk alltid å se litt over den horisonten. Det harde arbeidet er på deg å presse disse konseptene som ingen ennå ba om, som ikke støttes og udokumenteres til fordel for dine kunder og brukere.

Til syvende og sist, hvis du vil høre noen fortsette med dette i timevis og finne deg i nærheten Zagreb , gi meg beskjed. Vi kan ta en kopp kaffe.