Hastighed er brugervenlighed.
For at sige det mere præcist er webshastigheden en vigtig del af brugervenligheden. Den mest intuitive grænseflade, der nogensinde er skabt af menneskets sind, vil gøre dig ikke god, hvis brugeren bliver slukket af det tidspunkt, hvor den laster.
Det er det. Artiklen er færdig ... Ok, så der er faktisk meget mere til det, men den første sætning er omkring halvdelen af hvad du behøver at vide. Vi er nødt til at gøre vores hjemmesider hurtige.
Jeg kunne bruge mange superlative udtryk som "lynrask hurtigt" eller "ekstremt hurtig" eller endda "hurtigere end en fartkugle", men de ville være utilstrækkelige. Det er enklere at sige, at der ikke er noget som "for hurtigt".
Vi skal tage et øjeblik for at tale om hvilken slags hastighed jeg henviser til. Kort sagt, al hastighed. Mere specifikt tre slags hastighed:
Dette ville være den tid det tager for alle de oplysninger, der skal downloades til dine brugers enheder. Dette påvirkes primært af hastigheden af internetforbindelsen og den faktiske størrelse af filerne.
Du kan ikke gøre meget om forbindelsen, men du kan meget om filstørrelsen.
Når dine filer er downloadet, skal de behandles og gengives af browseren. Al den behandling og gengivelse påvirkes af, hvor godt din kode er skrevet, og alt andet foregår på brugerens telefon, tablet eller laptop / desktop.
Det eneste du kan styre er din egen kode, men det gør en stor forskel.
Og så er der den psykologiske faktor. Hurtige hjemmesider kan se ud som om de går langsomt. Langsomme websteder kan laves for at føle en lille smule hurtigere med den retlige anvendelse af nogle tricks.
Denne del handler om at studere din bruger og lade dem vide, hvad der sker, når de interagerer med dit websted eller din app.
Du skal være opmærksom på alle tre aspekter af webshastighed for at få dit websted til at føle, at det går hurtigt. Og jo større webstedet er, desto mere er der at optimere.
Lad os komme i gang, da.
Mange gange, især på de mindre eksperimentelle projekter, som jeg elsker så meget, finder jeg mig selv at bruge mere tid på CSS end nogen anden del af koden. Ofte er der også mere CSS skrevet end HTML eller JavaScript. Så det lige her er en indikator på, hvor meget dit CSS kan påvirke filstørrelsen.
Så er der selvfølgelig tale om, hvor hurtigt dit website rent faktisk vil køre på din brugers skrivebord, laptop, tablet eller telefon. Meget af det egentlige "arbejde" eller rendering af en webside udføres af softwaren, med lidt hjælp fra din GPU.
Det kan hurtigt indlæses, men rul langsomt. Den måde, hvorpå din CSS er skrevet, har en direkte effekt på, hvor hurtigt en bestemt enhed faktisk kan vise websiden, når filerne er blevet downloadet.
Når optimering af et websted til at køre hurtigere, er CSS normalt et godt sted at starte.
CSS, der sidder i dit stylesheet og ikke gør noget, gør dine filer unødvendigt større. Okay, så denne kan virke som en no-brainer; men det sker stadig med det bedste af os.
Du tager noget indhold ud og glemmer at slette det gamle CSS. Du ændrer et containerelements klasse eller ID, og glemmer at slette det gamle CSS. Du skriver nogle CSS, indser, at der er en bedre måde, og glemmer ... du får det.
Kaste flere front-end-udviklere i mixen, og du har en opskrift på et uhåndterligt, uhåndterligt stilark eller samling af dem, hvis du ikke er forsigtig. Ubrugt kode sænker sideindlæsningen på grund af dets eksistens som data. Det bremser udviklingen, fordi det kan forvirre folk, der læser stilarket.
Det kan også betyde langsommere gengivelsestider, fordi det er bare mere CSS for browseren at se igennem, mens den passer til alle CSS'erne til dets relevante HTML-elementer.
Uanset om du gennemgår og sletter alt gammelt CSS manuelt, skal du bruge automatiserede værktøjer til at hjælpe dig med at finde ubrugte CSS-selektorer eller bare slette ting tilfældigt, indtil noget går i stykker (ikke gør det). Du skal tage den gamle kode ud.
Når man taler om, hvordan browseren matcher CSS med den relevante HTML, er det på tide at se på CSS selectors. Der er skrevet meget om, hvilke selektorer der gør det hurtigste, hvilke er langsomme, uanset om du skal forstyrre de langsomte overhovedet og så videre.
Problemet er, at mange af disse oplysninger er gamle. Tilbage i år 2000 skrev Dave Hyatt (en udvikler, der arbejder på Safari, og aktivt medlem af W3Cs CSS Working Group):
Den triste sandhed om CSS3-selektorer er, at de virkelig ikke bør bruges overhovedet, hvis du bekymrer dig om sideydelse.
Hvis du tager et kig på dokumentet dette citat kom fra, du vil se, at han talte om selektorer som : førstebarn og andre pseudo-selektorer. Og han havde ret.
Han er stadig; men i de sidste femten år har computere avanceret lidt. I dag skal den ekstra indsats, der kræves af computeren til at gøre det CSS, ikke mærkes af nogen, undtagen dem, der bruger den billigste af billige mobilenheder.
Det er en bekymring i sig selv, så det vil virkelig afhænge af projektet ved hånden, din måldemografi og så videre. Simpelthen sæt, brug din bedste dømmekraft, og måske gå ikke overbord på pseudo-vælgerne.
Ellers, medmindre dine sider når boglængde, skal de selektorer, du bruger, have meget lidt effekt på dit websteds ydeevne. Se endnu et kig på dokumentet, der er linket ovenfor, og fortrolig med, hvad der gør det hurtigste og hvad der ikke gør. Du kan stadig finde oplysningerne nyttige.
Du kan også se denne artikel fra CSS-Tricks til en lidt nyere tage på emnet.
Selvfølgelig er der også CSS egenskaber, der tager længere tid at gøre end andre. De klassiske egenskaber som bredde, højde og farve er stadig den hurtigste. Dem, der har tendens til at tage lidt længere tid (og kan variere fra browser til browser) har tendens til at være CSS3 egenskaber som box-skygge.
Processen med at tilføje en dropshadow til et element er kompleks, hvad angår gengivelse af websider. Det, der er interessant at bemærke, er det, som påpeget HTML5 Rocks , kan den krævede behandlingskraft variere meget afhængigt af de specifikke dimensioner af drop shadow.
denne artikel indikerer, at det samme gælder for andre egenskaber som grænseradius og transformation.
Igen ville disse have ringe effekt på gengivelsen af en side på din gennemsnitlige desktop eller laptop. Mobil enheder kan dog tage et større hit, og oplevelsen kan lide som følge heraf. Alle hader hakket rullning.
Det skal dog vejes mod omkostningerne ved at bruge billeder til at producere de samme effekter. Nogen husker de ting, vi gjorde for at få afrundede hjørner, en gang om gangen?
Bare gå ikke overbord, og dine stilarter skal gøre hurtigt nok.
Nu kommer vi ind på andet område. CSS animationer kan blæser hurtigt, eller de kan bremse browseren til det punkt, at spil rigge har svært ved at holde op.
Dette skyldes delvist, fordi ikke alle animationer gengives ens. Nogle af de tunge løft er lavet af hardware, mens andre former for animation skal udføres udelukkende af browserens egne funktioner. Dette er især dyrt på mobile enheder.
I en anden artikel På HTML5 Rocks er CSS-egenskaberne, der er hurtigste til at animere, position , skala , rotation og opacitet.
Se artiklen for et mere komplet overblik over, hvad der kan animeres, samtidig med at "omkostningerne" bliver lave.
Her er hvor jeg tilbyder dig de mest praktiske råd, som jeg, forfatteren, kan give dig. Brug CSS preprocessorer som LESS, SASS og Stylus. Sikker på, hvis du bruger dem forkert, kan du generere større stylesheets end du havde tænkt dig; men de potentielle fordele er det værd.
Hvis du f.eks. Vil reducere antallet af HTTP-anmodninger, der er foretaget til serveren (altid en god ide), skal du inkludere alle nulstiller, rammer, i en mindre / SASS-fil. Når det kompileres, vil det hele være i et enkelt stilark. Desuden tilbyder de fleste præprocessorer muligheden for at udlæse alle CSS i formular.
På denne måde kan du bruge så mange forskellige filer, som du har brug for til organisering af kode, uden at filstørrelsen uberettiget påvirkes.
JavaScript kan være meget langsomt. For at være mere specifik kan JavaScript have en meget mere direkte effekt på "proces" delen af hastighedsligningen end CSS. Værre, JS kan blive eksponentielt tungere med hensyn til filstørrelse for at opnå tilsyneladende trivielle ting.
Det er en dobbelt whammy af smertefuld langsomhed, og vores brugere er ofte ofre, især dem på mobile browsere. Dette er imidlertid ikke sproget i sproget. Hvordan skruet op vores JS får er ofte direkte i forhold til vores uvidenhed om programmering generelt.
Jeg er en ikke-udvikler. Jeg har ofte brugt biblioteker som jQuery, eller individuelle stand-alone JS plugins for at få ting færdige. Jo mere jeg skal gøre, jo flere plugins skal jeg gøre for at få det til at fungere. Disse plugins og rammer leveres med ekstra muligheder og funktioner, som jeg aldrig må bruge.
Der er den båndbredde-stjæleblod, lige der.
Derudover kan plugins muligvis ikke fungere godt sammen. De kan bremse hinanden nede, eller man kan stoppe en anden fra at arbejde helt.
Der er den spildte proceskraft, lige der.
Hvis du virkelig ønsker at fremskynde dit websted, skal du rake millisekunder (eller hele sekunder, i nogle tilfælde) her er hvad du skal gøre:
Ligesom CSS, er det bedst at holde JS i eksterne filer, og linket til din HTML. Du tror måske ikke, det er så meget, hvis du ikke har meget JS-kode, og det tilføjer en HTTP-anmodning, men her er det: Eksterne CSS og JS-filer hentes i browseren.
Så når den samme side bliver anmodet om igen, eller andre sider på dit websted, der bruger det samme CSS eller JS, bliver anmodet om, bliver de cachelagrede eksterne filer brugt i stedet for at blive downloadet igen. Det er hurtigere ved ilægningstider og lidt hurtigere behandling. Det er værd at det ekstra kald til serveren nu og igen.
Grundlæggende går teorien sådan: browser'en gør hvad der helst øverst på en sides kildekode først. Derfor går ting som tagget tæt på toppen.
JavaScript-filer kan dog sænke alt ved at stoppe browseren fra at gøre din HTML, indtil de er indlæst. Da de fleste af de jævnlige JS-effekter og plugins kun skal fungere, efter at resten af siden er på skærmen, er dette mindre end ideel.
Forbedre brugerens oplevelse og reducere den opfattede belastningstid ved at linke til de eksterne filer nederst på siden lige før taggen.
Når en bruger kommer rundt for at interagere med noget, der kræver JS, bør det være klar til at gå.
Hvis du designer en komplet app, kan du og måske ignorere dette afsnit. En god, fleksibel og lys ramme kan give udviklere en enorm kant. For små til mellemstore websteder kan der dog være overkill med en JavaScript-ramme. På disse hjemmesider vil JS hovedsagelig blive brugt i back-end af CMS til administration af indhold. På forsiden kan du have en billedskyder eller murværklayout eller to. Hvis du virkelig har det lyst, kan du have fuldført på søgefeltet.
Det meste indhold behøver ikke at blive fancied og animeret som dette. JavaScript bør så meget som muligt reserveres for at forbedre brugeroplevelsen. At stole på at simpelthen temmelig et websted kan resultere i et langsomt, langsomt sted, især på mobile enheder.
På en måde er alle koderammer det samme, uanset om det er JavaScript, PHP, Python, HTML eller CSS: Hver funktion er en masse kode. Når du vælger en ramme eller et plugin til et job, så spørg dig selv, om du vil bruge alle funktioner, den tilbyder, eller endda de fleste af dem.
Hvis ikke, er rammemodulet? Kan du vælge og vælge kun de dele, du rent faktisk har brug for? Hvis det er tilfældet, og du mener, at filstørrelsen er værd, så går det helt sikkert! Ellers er det bedste praksis at se, hvad du kan tage ud mere end hvad du kan få fat i.
Ikke permanent! Tænk på det på denne måde, er der noget indhold eller funktionalitet på dit websted gemt væk af JS? Kan folk få adgang til det uden at have JS aktiveret i deres browsere?
Hvis ja, så godt. Men hvis folk ikke kan se vigtige oplysninger, kontakte dig eller navigere korrekt uden JavaScript, så har du et problem. Sikker på, du kan stole på de fleste mennesker, der stadig har det aktiveret, men du har altid fået disse kantsager.
Hvordan relaterer det sig til webshastighed? Forestil dig, hvordan langsom browsing vil få, hvis en del af dit websted pludselig bare ikke virker.
Ikke alvorligt, hvis du ikke er en udvikler, og du har budgettet til en, skal du få en, selv for små, enkle job. Det er billigere i det lange løb at ansætte nogen, der har erfaring med at gøre det rigtigt, en gang.
I tilfælde af at ting går galt forkert (og vi taler om computere her, så noget går galt), vil de finde ud af, hvad der gik galt hurtigere. De har erfaring med at finde de slags problemer og løse dem. Hvis ikke andet, vil de være bedre til at google de pågældende emner.
Vigtigst, de vil vide, hvordan man gør hvad der skal gøres med mindre kode. Mindre kode (normalt) kører hurtigere og (altid) downloads hurtigere. Det er det enkleste råd, jeg muligvis kan give.
(Hvis du er udvikler eller er ved at lære, har jeg samlet en liste over vejledninger, som vil være nederst i denne artikel. Inkluderet er nogle nybegyndere guider til at skrive JavaScript, der kører hurtigt.)
Når du tager video ud af ligningen, er den største ting på et hvilket som helst indholdsdrevet websted billederne. Billeder har tendens til at være store, omfangsrige og langsomme som helvede, når de ikke er optimeret.
Nu, med udbredelsen af nethinden skærmer tvinger os til at bruge større billeder, hvis vi vil have ting at se godt ud på hver enhed, vil problemet ikke blive lettere at løse. Og værre er det et problem, der er let at glemme, indtil du ender med at bruge mere end beregnet på båndbredde.
Når hver byte tæller, har vi ikke råd til at glemme.
Den gode nyhed er, at dette ikke er noget nyt problem på nogen måde. Hvorfor er det godt? Det betyder, at der er masser af mulige løsninger at vælge imellem, og du kan bruge mere end en af dem ad gangen. Faktisk er det generelt en god ide.
Så indtil internetudbydere og hostingfirmaer begynder at give os ubegrænset gratis båndbredde (hold ikke vejret), her er nogle ting du kan gøre:
Du skal blot sige, gør så meget som muligt, visuelt, med CSS og JavaScript, før du vender dig til billeder. Koden vil altid være billigere at overføre end billeder, så hold det så meget som muligt. På trods af forarbejdningseffekten, der forbruges af CSS-baserede drop-shadows, gradienter og lignende, overvejes afvejningerne.
Husk også, at SVG-billeder tæller i dette tilfælde som "kode", fordi det er alt de er: XML-kode, der gengives som et billede. Således bør de bruges, når du har brug for noget vektorrelateret.
Nu vender vi tilbage til de ovennævnte nethinden skærme, hvad gør vi om dem? Hvordan sparer vi på båndbredde der?
Det er her, vi vender os til elementet og billedindstillingsegenskaben . De er relativt nye og understøttes ikke fuldt ud, men de tillader browsere at vælge den passende billedstørrelse for den enhed, der bruges.
Så mens dette ikke sparer dig nogen båndbredde for nogen, der ser dit websted i deres iMac, er det ikke så stort af en aftale, fordi de højst sandsynligt har bredbånd. Nogen på deres telefon får i mellemtiden en mindre version af det samme billede, så de ikke venter for længe.
Mange image size woes bliver fikset, når du lærer hvilket billedformat der skal bruges i en given situation. Jeg kunne fortsætte med de specifikke billedformater, hvordan komprimeringen fungerer osv., Men du behøver kun at huske et par ting:
Det er virkelig alt sammen. Hvis du gør dette og spiller med optimeringsindstillingerne, når du gemmer billederne, kan du ofte få ret anstændigt kvalitet ved relativt små filstørrelser.
Der er dog et nyt format kaldet WebP, som automatisk understøttes af Chrome og Opera. Google fordringer at WebP-filer er 26% mindre end PNG'er og 25-34% mindre afhængigt af et par faktorer.
Dette er gode nyheder, bortset fra to ting: Firefox og IE. Nu, hvis du ikke har noget imod at bruge fallbacks og et ekstra script, kan du bruge WebP format nu, i dag. Bare download WebPJS , og du er god til at gå.
WebPJS bruger JavaScript og en lille smule Flash ( suk ... men det er kun for IE) for at få det til at fungere, men det virker. Du kan overveje det, hvis du skal servere masser og mange større billeder hurtigt, med ulempen er, at det ikke virker uden JS.
Der er to typer kompression, som du kan bruge på dine billeder. For det første har vi lossy kompression . Dette bruges til tabsformater som JPEG. Det giver dig mulighed for at komprimere et billede om så meget som du kan lide med den forståelse at kvaliteten bliver værre og værre og værre. Ting vil blive pixeleret og tabe definition.
Lossless kompression anvendes på formater som PNG, og kan til en vis grad reducere deres filstørrelse. Men det har sine grænser. Der kommer altid et punkt, hvor det er umuligt at lave et billede mindre uden at miste kvaliteten.
Hvis du har Photoshop eller et tilsvarende avanceret billedredaktør, er det ofte bedst at bruge dem til at komprimere dine billeder, så du kan se, hvordan produktionen vil se ud, når du er færdig.
(Automatiske værktøjer, især onlineværktøjer, har efter min opfattelse tendens til at komprimere ting måske lidt for langt. Jeg vil alligevel notere de bedste komprimeringsværktøjer, som jeg har fundet i linket nedenfor.)
Hvis du bruger et CMS som WordPress, vil det automatisk ændre størrelsen på billeder, der er for store. Det er også nemt at finde plugins, der automatisk komprimerer dem til dig.
Mind dig, jeg anbefaler kun automatisk komprimering i tilfælde hvor du ved, at du skal uploade mange, og masser af billeder af tilsvarende kvalitet til samme formål. En fotoblog er et eksempel.
Hvis du kører et websted, hvor brugerne uploader deres egne billeder, godt ... automatisk ændring og komprimering er et absolut must, og derfor gør ethvert socialt netværk det.
Her er et par stykker råd, der ikke passer til nogen af de tre kategorier ovenfor.
"Minificering" din kode betyder bare, at alle ekstra mellemrum og linjeskift bliver taget ud. Dette kan reducere filstørrelsen ret betydeligt.
Det kan lyde som en masse arbejde, men der er værktøjer derude til at minimere CSS og JS automatisk og holde de minificerede filer adskilt for dine kildefiler af forholdsvis indlysende årsager.
Som tidligere nævnt kan forskellige CSS-forprocessorer i første omgang udlevere al din kode i minificeret form.
Forudsat at din server er konfigureret rigtigt, kan al din kode sendes til browseren i et komprimeret format. Tekstfiler komprimerer meget godt, hvilket reducerer størrelsen af de filer, der sendes betydeligt.
Nu skal din server tage et øjeblik eller to for at komprimere de filer, den sender, og brugerens browser skal dekomprimere dem, men det er normalt værd for båndbreddehandel.
For en fuldstændig forklaring på hvordan dette virker, se Sådan optimeres dit websted med GZIP-komprimering .
Browser caching sker automatisk i et vist omfang takket være moderne browsere. En browser går til et websted, og gemmer midlertidigt billederne og andre oplysninger, den finder der.
På den måde, hvis den samme bruger vender tilbage inden for en given periode, behøver browseren ikke at bede om de samme billeder igen. Det laster bare dem, den allerede har, og anmoder om nye billeder, som den måske ikke har.
Der er dog noget du kan gøre for at fortælle browsere, hvad du skal cache og for hvor længe, som det ses i denne vejledning .
Og så er der server caching. Server caching tager i princippet bare dit websted og sætter en slags "kopi" af det mellem dine brugere og din aktuelle server. Hvorfor ville du forstyrre?
Nå, det er især nyttigt for folk, der bruger indholdsledelsessystemer i stor skala. At have dine brugere adgang til en midlertidig kopi af dit websted i stedet for den faktiske ting reducerer antallet af opkald til din database. Oplysninger bliver vist og indlæst hurtigere, fordi det ikke skal genbehandles hver gang.
Afhængigt af hvordan den er oprettet, kan server caching også reducere båndbreddeomkostningerne generelt. Dybest set er jo større dit websted er, desto større grund skal du kigge på.
Og nu er det afsnit du har ventet på: listen over links! Vi har vejledninger og vejledninger, for det meste, og et par billedkomprimeringsværktøjer at anbefale.
Yahoo! Må ikke være så stor en aftale som det engang var, men deres udvikler netværk har mange gode ting på det. Dette omfatter deres Bedste praksis til at fremskynde din hjemmeside , som dækker nogle af de grundlæggende ting, du kan gøre. Nogle af det dækker samme grund som denne artikel, men der er mere udover.
I introduktionen nævnte jeg opfattet webstedshastighed, også kendt som perceived perfomance. Hvis du gerne vil læse mere om det, så tjek En nybegyndervejledning til opfattet ydeevne: 4 måder at få dit mobilwebsted til at føle som en indbygget app .
Effeckt.css er et sæt CSS-baserede animationer, der er designet til at gøre det hurtigt, uanset hvilken platform brugeren er på.
Det her er en vejledning for at sikre, at din CSS hentes og behandles hurtigst muligt af browseren.
Når du lige er begyndt, lære at kode korrekt kan være lige så stor en hastighedsforøgelse som nogle tilfældige tips om tricks du måske lærer. Dårlig kode koster mere med hensyn til behandlingstid, så lær at gøre tingene på den rigtige måde.
Her er en grundlæggende vejledning der fokuserer mere specifikt på at skrive JavaScript, der kører hurtigt.
Ligesom titlen siger, det her er alle rådgivning målrettet specifikt til JavaScript V8.
Og nogle gange vil du sandsynligvis ende med at bruge jQuery. Hvis du skal gøre det, skal du i det mindste vide, hvordan du skriver jQuery-selektorer, der ikke vil bremse dig. Og her er der Sitepoint har du dækket .
Læs dette for mere information om billedformater på internettet. Oplysningerne er lidt gamle, men stadig gyldige og gode at vide.
Det her er en mere teknisk vejledning til billedoptimering, som leveres af Google Developer Network.
Compressor.io er et af de mere imponerende værktøjer, jeg personligt har oplevet. Det er en onlineapp, så du skal uploade filer, du vil komprimere, men det kan gøre underværker for JPG'er. Det giver både lossy og lossless komprimering muligheder, hver med temmelig fantastiske resultater, og det kan også gøre batch behandling.
Trimage specialiserer sig i tabsfri kompression, men den kan installeres på din egen computer, på Windows, Mac eller Linux. Da det installeres til din computer (og ja, leveres med forskellige kommandolinjeindstillinger samt en GUI), kan den nemt køres automatisk som en del af en udviklingsarbejdsproces.
Som altid er der meget mere at lære. Men bevæbnet med de oplysninger, vi har leveret, og de ressourcer, vi har linket til, vil du være på vej til byggepladser og apps, der ikke irriterer helvede ud af dine brugere.
Og det er det første skridt i retning af at imponere dem.