Hastighet er brukervennlighet.
For å si det mer nøyaktig, er nettsidenes hastighet en stor del av brukervennligheten. Det mest intuitive grensesnittet som noensinne er opprettet av menneskets sinn, vil gjøre deg ikke bra hvis brukeren blir slått av når den laster.
Det er det. Artikkelen er ferdig ... Ok, så det er faktisk mye mer til det, men den første setningen er omtrent halvparten av det du trenger å vite. Vi må gjøre våre nettsteder raske.
Jeg kunne bruke mange superlative uttrykk som "flammende fort" eller "ekstremt rask", eller til og med "raskere enn en fartkule", men de ville være utilstrekkelige. Det er enklere å si at det ikke er noe slikt som "for fort".
Vi trenger å ta et minutt for å snakke om hvilken type fart jeg refererer til. Kort sagt, all fart. Nærmere bestemt, tre typer fart:
Dette er den tiden det tar for all informasjonen som skal lastes ned til brukerens enheter. Dette påvirkes hovedsakelig av hastigheten på internettforbindelsen, og den faktiske størrelsen på filene.
Du kan ikke gjøre mye om tilkoblingen, men du kan gjøre mye om filstørrelse.
Etter at filene er lastet ned, må de behandles og gjengis av nettleseren. All behandling og gjengivelse påvirkes av hvor godt koden din ble skrevet, og alt annet skjer på brukerens telefon, nettbrett eller bærbar datamaskin.
Det eneste du kan kontrollere er din egen kode, men det er en stor forskjell.
Og så er det den psykologiske faktoren. Raske nettsteder kan se ut som de går sakte. Langsomme nettsteder kan gjøres for å føle seg litt raskere med den juridiske anvendelsen av noen triks.
Denne delen handler om å studere brukeren din, og la dem få vite hva som skjer når de samhandler med nettstedet eller appen din.
Du må være oppmerksom på alle tre aspekter av nettsidenes hastighet for å få nettstedet ditt til å føle at det går fort. Og jo større siden er, jo mer er det å optimalisere.
La oss komme i gang da.
Mange ganger, spesielt på de mindre eksperimentelle prosjektene som jeg elsker så mye, finner jeg meg selv å bruke mer tid på CSS enn noen annen del av koden. Ofte er det også mer CSS skrevet enn HTML eller JavaScript. Så det, derimot, er en indikator på hvor mye CSS kan påvirke filstørrelsen.
Så, selvfølgelig, er det spørsmål om hvor fort nettstedet ditt faktisk vil kjøre på brukerens skrivebord, laptop, nettbrett eller telefon. Mye av det faktiske "arbeidet" eller gjengivelsen av en nettside er gjort av programvaren, med litt hjelp fra GPU.
Det kan lastes raskt, men bla sakte. Måten CSS er skrevet på, har en direkte effekt på hvor raskt en bestemt enhet faktisk kan vise nettsiden når filene er lastet ned.
Når du optimaliserer et nettsted for å kjøre raskere, er CSS vanligvis et godt sted å starte.
CSS som sitter i stilarket ditt og ikke gjør noe gjør filene dine unødvendig større. Ok, så dette kan virke som en no-brainer; men det skjer fortsatt med det beste av oss.
Du tar ut noe innhold og glemmer å slette det gamle CSS. Du endrer et containertelements klasse eller ID, og glemmer å slette den gamle CSS. Du skriver noen CSS, innser at det er en bedre måte, og glem ... du får det.
Kast flere front-end-utviklere inn i blandingen, og du har en oppskrift på et uhåndterlig, uhåndterbart stilark eller samling av dem hvis du ikke er forsiktig. Ubrukt kode bremser siden lasting på grunn av sin eksistens som data. Det bremser utviklingen fordi det kan forvirre folk som leser stilarket.
Det kan også bety tregere gjengivelse ganger, fordi det er bare mer CSS for nettleseren å se gjennom mens den samsvarer med alle CSS til de aktuelle HTML-elementene.
Enten du vurderer og sletter alt gammelt CSS manuelt, bruker automatiserte verktøy for å hjelpe deg med å finne ubrukte CSS-seleksorer, eller bare slett ting tilfeldig til noe bryter (ikke gjør det), du må ta den gamle koden ut.
Når det gjelder hvordan nettleseren samsvarer med CSS med riktig HTML, er det på tide å se på CSS-valgene. Mye har blitt skrevet om hvilke selgere som gjør det raskeste, hvilke som er tregte, om du burde plage med de sakte i det hele tatt, og så videre.
Problemet er at mye av denne informasjonen er gammel. Tilbake i år 2000 skrev Dave Hyatt (en utvikler som arbeider med Safari, og aktivt medlem av W3Cs CSS Working Group) dette:
Den triste sannheten om CSS3 selectors er at de egentlig ikke bør brukes i det hele tatt hvis du bryr deg om sideytelse.
Hvis du vil ta en titt på dokumentet dette sitatet kom fra, du vil se at han snakket om selektorer som : første barn og andre pseudo-selektorer. Og han hadde rett.
Han er fortsatt; men i de siste femten årene har datamaskinene avansert litt. I dag må den ekstra innsatsen som kreves av datamaskinen for å gjengi det CSS ikke være merkbar av noen, bortsett fra de som bruker den billigste av billige mobile enheter.
Det er en bekymring i seg selv, så egentlig, det vil avhenge av prosjektet ved hånden, måldemografien din og så videre. Enkelt sagt, bruk din beste dømmekraft, og kanskje ikke gå overbord på pseudoselectors.
Ellers, med mindre sidene dine når boklengden, må de seleksjonene du bruker, ha svært liten effekt på ytelsen til nettstedet ditt. Fortsett ta en titt på dokumentet som er koblet over og bli kjent med hva som gjør det raskeste og hva som ikke gjør det. Du kan fortsatt finne informasjonen nyttig.
Du kan også se denne artikkelen fra CSS-Tricks for en litt nyere ta på emnet.
Selvfølgelig er det også CSS egenskaper som tar lengre tid å gjengi enn andre. De klassiske egenskapene som bredde, høyde og farge er fortsatt den raskeste. De som har en tendens til å ta litt lengre tid (og kan variere fra nettleser til nettleser) pleier å være CSS3 egenskaper som bokseskygge.
Prosessen med å legge til en dråpe skygge til et element er komplisert, så langt som gjengivelse av nettsider er bekymret. Det som er interessant å merke seg er det, som påpekt HTML5 Rocks , kan den nødvendige prosessorkraften variere sterkt avhengig av de spesifikke dimensjonene til dropshadow.
denne artikkelen indikerer at det samme gjelder for andre egenskaper som ramme-radius og transformasjon.
Igjen, dette ville få liten effekt på gjengivelsen av en side på din gjennomsnittlige desktop eller laptop. Mobil enheter kan imidlertid ta en større hit, og erfaringen kan lide som følge av dette. Alle hater hakkete rulling.
Likevel må det veies mot kostnadene ved å bruke bilder for å produsere de samme effektene. Noen husker de tingene vi gjorde for å få avrundede hjørner, en gang i gang?
Bare ikke gå overbord, og stilene dine bør gjengi seg raskt nok.
Nå kommer vi inn på andre territorier. CSS-animasjoner kan blazingly raskt, eller de kan bremse nettleseren til det punktet at spillriggene har problemer med å holde opp.
Dette er delvis fordi ikke alle animasjoner gjengis likt. Noen av de tunge løftene er gjort av maskinvaren, mens andre typer animasjon må utføres helt av nettleserens egne funksjoner. Dette er spesielt kostbart på mobile enheter.
I en annen artikkel På HTML5 Rocks, er CSS-egenskapene som er raskest å animere, posisjon , skala , rotasjon og opasitet.
Sjekk ut artikkelen for en mer fullstendig oversikt over hva som kan animeres mens kostnadene holdes lave.
Her er hvor jeg tilbyr deg de mest praktiske rådene som jeg, forfatteren, kan gi deg. Bruk CSS preprosessorer som LESS, SASS og Stylus. Visst, hvis du bruker dem feil, kan du generere større stilark enn du hadde tenkt på; men de potensielle fordelene er verdt det.
Hvis du for eksempel vil redusere antall HTTP-forespørsler gjort til serveren (alltid en god ide), inkludere alle tilbakestillinger, rammer, til en LESS / SASS-fil. Når det kompileres, vil det hele være i et enkelt stilark. I tillegg tilbyr de fleste preprosessorer muligheten til å sende ut alt CSS i en bekreftet form.
På denne måten kan du bruke så mange forskjellige filer som du trenger for organisering av kode, uten å påvirke filstørrelsen på uheldig måte.
JavaScript kan være veldig tregt. For å være mer spesifikk kan JavaScript ha en mye mer direkte effekt på "prosesseringsdelen" av hastighetsligningen enn CSS. Verre, JS kan bli eksponentielt tyngre når det gjelder filstørrelse for å oppnå tilsynelatende trivielle ting.
Det er en dobbel whammy med smertefull treghet, og brukerne våre er ofte ofrene, spesielt de som bruker mobile nettlesere. Dette er imidlertid ikke feilen til språket. Hvordan skrudd opp vår JS får er ofte i direkte forhold til vår uvitenhet om programmering generelt.
Jeg er en ikke-utvikler. Jeg har ofte brukt biblioteker som jQuery, eller individuelle frittstående JS plugins for å få ting gjort. Jo mer jeg trenger å gjøre, jo flere plugins jeg trenger for å få alt til å fungere. Disse pluginene og rammene leveres med ekstra alternativer og funksjoner som jeg aldri kan bruke.
Det er båndbredde-stjele oppblåst, der.
I tillegg kan plugins kanskje ikke fungere godt sammen. De kan sakte hverandre ned, eller man kan stoppe en annen fra å arbeide helt.
Det er bortkastet prosessorkraft, der.
Hvis du virkelig ønsker å øke hastigheten på nettstedet ditt, barberer du millisekunder (eller hele sekunder, i noen tilfeller) her er det du trenger å gjøre:
Som CSS, er det best å holde JS i eksterne filer, og koblet til HTML-en din. Du tror kanskje ikke at det er så stor en sak hvis du ikke har mye JS-kode, og det legger til en HTTP-forespørsel, men her er saken: Eksterne CSS- og JS-filer blir cachet av nettleseren.
Så når den samme siden blir bedt om igjen, eller andre sider på nettstedet ditt, som bruker det samme CSS eller JS, blir forespurt, blir de cachede eksterne filene brukt i stedet for å bli lastet ned igjen. Det er raskere lastingstider og litt raskere behandling. Det er verdt det ekstra samtalen til serveren nå og igjen.
I utgangspunktet går teorien slik: nettleseren gjør det som står øverst på en side kildekoden først. Det er derfor ting som taggen går nær toppen.
JavaScript-filer kan imidlertid redusere alt ved å stoppe nettleseren fra å gjengi HTML-en din til de lastes. Siden de fleste JS-effektene og pluginene som brukes ofte, bare trenger å fungere etter at resten av siden er på skjermen, er dette mindre enn ideelt.
Forbedre brukerens opplevelse og redusere oppfattet ladetid ved å koble til de eksterne filene nederst på siden, rett før taggen.
Når en bruker kommer rundt for å samhandle med alt som krever JS, bør det være klart å gå.
Hvis du designer en fullverdig app, kan du og kanskje ignorere denne delen. Et godt, fleksibelt og lett rammeverk kan gi utviklere en stor fordel. For små til mellomstore nettsteder kan imidlertid en JavaScript-ramme være overkill. På disse nettstedene blir JS mest brukt i back-end av CMS for å administrere innhold. På forsiden kan det hende du har en bildegjenger, eller murverk eller to. Hvis du virkelig har lyst, kan du ha automatisk fullført på søkefeltet.
Det meste innholdet trenger ikke å bli fancied opp og animert som dette. JavaScript bør, så mye som mulig, være reservert for å forbedre brukeropplevelsen. Å stole på det å ganske enkelt opp et nettsted kan resultere i et sakte, sakte sted, spesielt på mobile enheter.
På en måte er alle koderammer det samme, enten det er JavaScript, PHP, Python, HTML eller CSS: hver funksjon er en gjeng med kode. Når du velger et rammeverk eller et plugin for en jobb, spør deg selv om du skal bruke alle funksjonene den tilbyr, eller til og med de fleste av dem.
Hvis ikke, er rammemodulet? Kan du velge og velge bare de delene du egentlig trenger? I så fall, og du tror at filstørrelsen skal være verdt det, så må du gå for det! Ellers er det best praksis å se hva du kan ta ut mer enn hva du kan klappe inn.
Ikke permanent! Tenk på det på denne måten, er det noe innhold eller funksjonalitet på nettstedet ditt gjemt av JS? Kan folk få tilgang til det uten at JS er aktivert i nettleserne sine?
Hvis så, så flott. Men hvis folk ikke kan se viktig informasjon, kontakter du eller navigerer riktig uten JavaScript, så har du et problem. Jo, du kan stole på at folk som fortsatt har det aktivert, men du har alltid fått de kanten tilfeller.
Hvordan relaterer dette til nettsidehastighet? Tenk deg hvor langsom surfing vil få hvis en del av nettstedet ditt plutselig bare ikke virker.
Ikke seriøst, hvis du ikke er en utvikler, og du har budsjettet for en, kan du få en, selv for små, enkle jobber. Det er billigere i det lange løp å ansette noen som har erfaring med å gjøre det riktig, en gang.
I tilfelle at ting går galt feil (og vi snakker om datamaskiner her, så noe vil gå galt), vil de finne ut hva som gikk galt raskere. De har erfaring med å finne slike problemer og løse dem. Hvis ikke noe annet, vil de være bedre til å gå på de aktuelle emnene.
Viktigst av alt, de vil vite hvordan å gjøre det som må gjøres med mindre kode. Mindre kode (vanligvis) kjører raskere og (alltid) nedlastinger raskere. Det er det enkleste rådet jeg muligens kan gi.
(Hvis du er utvikler, eller lærer, har jeg samlet en liste over opplæringsprogrammer som vil være nederst i denne artikkelen. Inkludert er noen nybegynnerveiledere for å skrive JavaScript som kjører raskt.)
Når du tar video ut av ligningen, er den største tingen på et gitt innholdsdrevet nettsted bildene. Bilder har en tendens til å være stor, omfangsrik og sakte som helvete når de ikke er optimalisert.
Nå, med spredning av retina skjermbilder tvinger oss til å bruke større bilder hvis vi vil ha ting til å se bra ut på hver enhet, vil problemet ikke bli lettere å løse. Og verre, det er et problem som er lett å glemme til du ender med å bruke mer enn beregnet på båndbredde.
Når hver byte teller, har vi ikke råd til å glemme.
Den gode nyheten er at dette ikke er noe nytt problem på noen måte. Hvorfor er det bra? Det betyr at det er tonnevis av mulige løsninger å velge mellom, og du kan bruke mer enn en av dem om gangen. Faktisk er det generelt en god ide.
Så til ISP og hosting-selskaper begynner å gi oss all ubegrenset fri båndbredde (ikke hold pusten), her er noen ting du kan gjøre:
Enkelt sagt, gjør så mye du kan, visuelt sett, med CSS og JavaScript før du slår på bilder. Koden vil alltid være billigere å overføre enn bilder, så hold deg så mye som mulig. Til tross for prosessorkraften som forbrukes av CSS-baserte dropshadows, gradienter og lignende, vurderes avvikene.
Vær også oppmerksom på at SVG-bilder teller, i dette tilfellet, som "kode", fordi det er alt de er: XML-kode som gjengis som et bilde. Dermed bør de brukes når du trenger noe vektorrelatert.
Nå, tilbake til de nevnte retina skjermene, hva gjør vi om dem? Hvordan sparer vi på båndbredde der?
Det er her vi vender oss til elementet og egenskapen for bildesett . De er relativt nye, og støttes ikke fullt ut, men de tillater nettlesere å velge riktig bildestørrelse for enheten som blir brukt.
Så mens dette ikke sparer deg for båndbredde for at noen ser på nettstedet ditt i iMac, er det ikke så stort av en avtale fordi de mest sannsynlig har bredbånd. Noen på telefonen får i mellomtiden en mindre versjon av det samme bildet, slik at de ikke venter for lenge.
Mange image size woes blir løst når du lærer hvilket bildeformat som skal brukes i en gitt situasjon. Jeg kunne fortsette med bestemte bildeformater, hvordan komprimeringen fungerer, og så videre, men du trenger bare å huske et par ting:
Det er virkelig alt av det. Hvis du gjør dette, og spiller med optimaliseringsinnstillingene når du lagrer bildene, kan du ofte få ganske anstendig kvalitet ved relativt små filstørrelser.
Det er imidlertid et nytt format ut som heter WebP, som støttes av Chrome og Opera automatisk. Google påstander at WebP-filene er 26% mindre enn PNG, og 25-34% mindre, avhengig av et par faktorer.
Dette er gode nyheter, bortsett fra to ting: Firefox og IE. Nå, hvis du ikke har noe imot å bruke fallbacks og et ekstra skript, kan du bruke WebP-format nå, i dag. Bare last ned WebPJS , og du er god til å gå.
WebPJS bruker JavaScript og litt Flash ( sukk ... men det er bare for IE) for å få det til å fungere, men det virker. Du kan vurdere det hvis du trenger å tjene opp mange og mange større bilder raskt, med ulempen er at det ikke vil fungere uten JS.
Det finnes to typer komprimering som du kan bruke på bildene dine. Først har vi lossy komprimering . Dette brukes på lossy formater som JPEG. Det lar deg komprimere et bilde omtrent så mye du vil med forståelsen om at kvaliteten vil bli verre og verre og verre. Ting vil få pixelated og miste definisjon.
Lossless komprimering brukes på formater som PNG, og kan redusere filstørrelsen til en viss grad. Men det har sine grenser. Det kommer alltid et punkt der det er umulig å lage et bilde mindre uten å miste kvalitet.
Hvis du har Photoshop eller et tilsvarende avansert bilderedigeringsprogram, er det ofte best å bruke dem til å komprimere bildene dine slik at du kan se hvordan utgangen vil se ut når du er ferdig.
(Automatiske verktøy, spesielt elektroniske verktøy, har etter min erfaring en tendens til å komprimere ting, kanskje litt for langt. Jeg vil likevel oppgi de beste komprimeringsverktøyene jeg har funnet i koblingsdelen nedenfor.)
Hvis du bruker et CMS som WordPress, vil det automatisk endre størrelsen på bilder som er for store. Det er også enkelt å finne plugins som automatisk vil komprimere dem for deg.
Mind deg, jeg anbefaler bare automatisk komprimering i tilfeller der du vet at du skal laste opp masse, og mange bilder av tilsvarende kvalitet til samme formål. En fotoblogg er et eksempel.
Hvis du kjører et nettsted der brukerne laster opp sine egne bilder, vel ... automatisk resizing og komprimering er et absolutt must, og det er derfor hvert sosialt nettverk gjør det.
Her er et par biter av råd som ikke passer inn i noen av de tre kategoriene ovenfor.
"Minifisering" koden betyr bare at alle ekstra mellomrom og linjeskift blir tatt ut. Dette kan redusere filstørrelsen ganske betydelig.
Det kan høres ut som mye arbeid, men det er verktøy der ute for å minifisere CSS og JS automatisk, og holde de oppgraderte filene skilt for kildefilene dine, av ganske åpenbare grunner.
Som tidligere nevnt, kan forskjellige CSS preprosessorer sende ut all koden din i forkortet form i utgangspunktet.
Forutsatt at serveren er konfigurert riktig, kan all kode sendes til nettleseren i komprimert format. Tekstfiler komprimerer veldig bra, og reduserer størrelsen på filene som sendes betydelig.
Nå må serveren ta et øyeblikk eller to for å komprimere filene den sender, og brukerens nettleser må dekomprimere dem, men dette er vanligvis verdt båndbreddeavviket.
For en fullstendig forklaring på hvordan dette virker, se Slik optimaliserer du nettstedet ditt med GZIP-komprimering .
Browserbufring skjer i noen grad takket være moderne nettlesere. En nettleser går til et nettsted, og lagrer midlertidig bildene og annen informasjon den finner der.
På den måten, hvis den samme brukeren returnerer innen en gitt tidsperiode, trenger ikke nettleseren å be om de samme bildene igjen. Det laster bare de som den allerede har, og ber om nye bilder som den kanskje ikke har.
Det er imidlertid noe du kan gjøre for å fortelle nettlesere hva du skal cache og hvor lenge, sett i denne veiledningen .
Og så er det server caching. Serverkufring tar i utgangspunktet bare ditt nettsted og setter en slags "kopi" av den mellom brukerne og den faktiske serveren din. Hvorfor ville du plage deg?
Vel, det er spesielt nyttig for folk som bruker innholdsstyringssystemer i stor skala. Å få brukerne til å få tilgang til en midlertidig kopi av nettstedet ditt i stedet for den faktiske saken reduserer antall samtaler til databasen din. Informasjon blir vist og lastet raskere fordi den ikke trenger å bli omarbeidet hver gang.
Avhengig av hvordan den er konfigurert, kan server caching også redusere kostnadene for båndbredde generelt. I utgangspunktet er jo større nettstedet ditt er, jo mer grunn du må se på å cache det.
Og nå, delen du har ventet på: Liste over lenker! Vi har veiledninger og veiledninger, for det meste, og et par bildekompresjonsverktøy å anbefale.
Yahoo! Kan ikke være så stor en avtale som den en gang var, men deres utvikler nettverk har mange gode ting på den. Dette inkluderer deres Best Practices for å øke hastigheten på nettstedet ditt , som dekker noen av de grunnleggende tingene du kan gjøre. Noen av det dekker samme grunnlag som denne artikkelen, men det er mer i tillegg.
I introduksjonen nevnte jeg oppfattet nettstedhastighet, også kjent som oppfattet perfomance. Hvis du vil lese mer om det, sjekk ut En nybegynners guide til oppfattet ytelse: 4 måter å få det mobile nettstedet ditt til å føle som en innfødt app .
Effeckt.css er et sett med CSS-baserte animasjoner som er utformet for å gjengi seg raskt, uansett hvilken plattform brukeren er på.
Dette er en veiledning for å sikre at CSS blir lastet ned og behandlet så raskt som mulig av nettleseren.
Når du bare begynner, lærer å kode riktig kan være like stor en fart boost som noen tilfeldige tips av triks du kan lære. Dårlig kode koster mer når det gjelder behandlingstid, så lær å gjøre ting på riktig måte.
Her er en grunnleggende veiledning som fokuserer mer spesifikt på å skrive JavaScript som kjører raskt.
Akkurat som tittelen sier, dette er alle råd rettet spesifikt til JavaScript V8.
Og noen ganger vil du nok ende opp med å bruke jQuery. Hvis du skal gjøre det, bør du i det minste vite hvordan du skriver jQuery selectors som ikke vil bremse deg ned. Og her er hvor Sitepoint har du dekket .
Les dette for mer informasjon om bildformater på nettet. Informasjonen er litt gammel, men fortsatt gyldig, og god å vite.
Dette er en mer teknisk guide til bildeoptimalisering fra Google Developer Network.
Compressor.io er et av de mer imponerende verktøyene jeg personlig har møtt. Det er en online app, så du må laste opp noen filer du vil komprimere, men det kan gjøre underverker for JPG. Den tilbyr både lossy og lossless komprimeringsalternativer, hver med ganske fantastiske resultater, og det kan også gjøre batchbehandling.
Trimage spesialiserer seg på lossless komprimering, men den kan installeres på egen datamaskin, på Windows, Mac eller Linux. Siden det installeres på datamaskinen din (og ja, kommer med forskjellige kommandolinjealternativer samt en GUI), kan den enkelt kjøres automatisk som en del av en utviklings arbeidsflyt.
Som alltid er det mye mer å lære. Men bevæpnet med informasjonen vi har gitt, og ressursene vi har koblet til, vil du være på vei til byggeplasser og apper som ikke irriterer helvete ut av brukerne dine.
Og det er det første skrittet mot å imponere dem.