Hastighet är användbarhet.
För att säga det mer exakt är webbhastigheten en viktig del av användbarheten. Det mest intuitiva gränssnittet som någonsin skapats av människans sinne kommer inte göra dig bra om användaren slås av när den laddas.
Det är allt. Artikeln är klar ... Ok, så det finns faktiskt mycket mer till det, men den första meningen är ungefär hälften av vad du behöver veta. Vi måste göra våra webbplatser snabba.
Jag skulle kunna använda många superlativa uttryck som "blixtsnabbt" eller "extremt snabbt", eller till och med "snabbare än en fartkula", men de skulle vara otillräckliga. Det är enklare att säga att det inte finns något sådant som "för snabbt".
Vi behöver ta en minut för att prata om vilken typ av hastighet jag refererar till. Kort sagt, hela hastigheten. Mer specifikt tre typer av hastighet:
Det här är den tid det tar för all information att ladda ner till dina användares enheter. Detta påverkas främst av internetanslutningens hastighet och den faktiska storleken på filerna.
Du kan inte göra mycket om anslutningen, men du kan göra mycket om filstorlek.
När dina filer har laddats ner måste de bearbetas och återges av webbläsaren. All sådan behandling och återgivning påverkas av hur bra din kod skrevs, och allting pågår på användarens telefon, surfplattform eller laptop / skrivbord.
Det enda du kan kontrollera är din egen kod, men det gör en stor skillnad.
Och då är det den psykologiska faktorn. Snabba webbplatser kan se ut som att de går långsamt. Långsamma webbplatser kan göras för att känna en liten bit snabbare med den rättsliga tillämpningen av några knep.
Den här delen handlar om att studera din användare och låta dem veta vad som händer när de interagerar med din webbplats eller app.
Du måste vara uppmärksam på alla tre aspekter av webbplatsens hastighet för att få din webbplats att känna att den går fort. Och ju större webbplatsen är desto mer är det att optimera.
Låt oss börja, då.
Många gånger, särskilt på de mindre experimentella projekt som jag älskar så mycket, tycker jag att jag spenderar mer tid på CSS än någon annan del av koden. Ofta finns det också fler CSS skrivna än HTML eller JavaScript. Så det där är en indikator på hur mycket din CSS kan påverka filstorleken.
Då är det självklart fråga om hur snabbt din webbplats faktiskt kommer att köras på din användares skrivbord, bärbara dator, surfplatta eller telefon. Mycket av det faktiska "arbetet" eller att göra en webbsida görs av mjukvaran, med lite hjälp från din GPU.
Det kan hämta snabbt, men rulla långsamt. Hur din CSS skrivs har en direkt effekt på hur snabbt en viss enhet faktiskt kan visa webbsidan när filerna har laddats ner.
När optimering av en webbplats ska köras snabbare är CSS vanligtvis ett bra ställe att börja.
CSS som sitter i ditt stylesheet och inte gör någonting gör dina filer onödigt större. Okej, så här kan det tyckas som en ingen-brainer; men det händer fortfarande med det bästa av oss.
Du tar bort något innehåll och glömmer att ta bort den gamla CSS. Du ändrar ett behållarelements klass eller ID, och glömmer att radera den gamla CSS. Du skriver några CSS, inser att det finns ett bättre sätt, och glöm det ... du får det.
Kasta flera front-end-utvecklare i mixen, och du har ett recept på ett obevekligt, obekvämt stilark eller samling av dem om du inte är försiktig. Oanvänd kod saktar ner sidladdning på grund av sin existens som data. Det saktar ner utvecklingen eftersom det kan förvirra människor som läser stilarket.
Det kan också innebära långsammare återgivningstider, eftersom det bara är mer CSS för att webbläsaren ska titta igenom medan den matchar alla CSS till dess lämpliga HTML-element.
Oavsett om du granskar och tar bort alla gamla CSS manuellt, använder du automatiska verktyg för att hjälpa dig att hitta oanvända CSS-valörer eller bara radera saker slumpmässigt tills något rasterar (gör inte det) måste du ta den gamla koden ut.
Med tanke på hur webbläsaren matchar CSS med lämplig HTML, är det dags att titta på CSS-väljare. Mycket har skrivits om vilka väljare som gör det snabbaste, vilka som är långsamma, om du borde störa de långsamma i alla och så vidare.
Problemet är att mycket av denna information är gammal. Tillbaka i år 2000 skrev Dave Hyatt (en utvecklare som arbetar med Safari och aktiv medlem av W3C: s CSS Working Group) följande:
Den ledsna sanningen om CSS3-selektorer är att de verkligen inte borde användas alls om du bryr dig om sidprestanda.
Om du tar en titt på dokumentet det citatet kom ifrån, ser du att han pratade om väljare som : första barn och andra pseudo-väljare. Och han hade rätt.
Han är fortfarande; men under de senaste femton åren har datorer avancerat lite. Numera behöver den extra insats som krävs av datorn för att göra den CSS inte märkas av någon, utom de som använder den billigaste av billiga mobila enheter.
Det är en oro i sig, så det kommer verkligen att bero på projektet, din måldemografi och så vidare. Enkelt uttryckt, använd din bästa bedömning och kanske inte gå överbord på pseudo-väljare.
Annars, om inte dina sidor når boklängden, måste de väljare du använder ha mycket liten effekt på din webbplatss prestanda. Fortfarande, ta en titt på dokumentet som länkats ovan och bli bekant med vad som gör det snabbaste och vad som inte gör det. Du kan fortfarande hitta informationen användbar.
Du kan också se Denna artikel från CSS-Tricks för en något senare satsning på ämnet.
Självklart finns det också CSS-egenskaper som tar längre tid att göra än andra. De klassiska egenskaperna som bredd, höjd och färg är fortfarande de snabbaste. De som tenderar att ta lite längre tid (och kan variera från webbläsare till webbläsare) tenderar att vara CSS3 egenskaper som boxskugga.
Processen att lägga till en droppskugga till ett element är komplext, vad gäller att göra webbsidor oroade. Det som är intressant att notera är det, som påpekat HTML5 Rocks , krävs det att processkraften varierar mycket beroende på de specifika dimensionerna för droppskuggan.
Denna artikel indikerar att samma sak gäller för andra egenskaper, såsom gränsen och transformen.
Återigen skulle dessa ha liten inverkan på att en sida skulle visas på din genomsnittliga skrivbord eller laptop. Mobila enheter kan dock ta en större träff, och erfarenheten kan leda till detta. Alla hatar hakig rullning.
Ändå måste det vägas mot kostnaden för att använda bilder för att ge samma effekter. Någon minns vad vi gjorde för att få rundade hörn, en gång i taget?
Bara gå inte överbord, och dina stilar ska göra tillräckligt snabbt.
Nu kommer vi in på annat territorium. CSS-animationer kan bli blixtsnabbt, eller de kan sakta ner webbläsaren till den punkt som spelarriggar har problem med att hålla upp.
Detta beror delvis på att inte all animering görs lika. En del av den tunga lyftningen görs av hårdvaran, medan andra typer av animationer måste göras helt av webbläsarens egna funktioner. Detta är särskilt dyrt på mobila enheter.
I en annan artikel På HTML5 Rocks är de CSS-egenskaper som är snabbast att animera position , skala , rotation och opacitet.
Kolla in artikeln för en mer fullständig översikt över vad som kan animeras samtidigt som "kostnaden" är låg.
Här erbjuder jag dig de mest praktiska råd som jag, författaren, kan ge dig. Använd CSS-förprocessorer som LESS, SASS och Stylus. Visst, om du använder dem fel kan du generera större formatmallar än vad du menade; men de potentiella fördelarna är värda det.
Om du till exempel vill minska antalet HTTP-förfrågningar som görs på servern (alltid en bra idé), inkludera alla återställningar, ramar, till en LESS / SASS-fil. När det sammanställs kommer det alla att vara i ett enda stilark. Dessutom erbjuder de flesta preprocessorer möjligheten att mata ut alla CSS i minifierad form.
På det här sättet kan du använda så många olika filer som du behöver för organisationsändamål utan att på ett otillbörligt sätt påverka filstorleken.
JavaScript kan vara riktigt långsamt. För att vara mer specifik kan JavaScript ha en mycket mer direkt effekt på "bearbetning" delen av hastighetsekvationen än CSS. Värre, JS kan bli exponentiellt tyngre när det gäller filstorlek för att uppnå till synes triviala saker.
Det är en dubbel whammy av smärtsam långsamhet, och våra användare är ofta offer, speciellt de på mobila webbläsare. Detta är dock inte felet i språket. Hur skruvas upp vår JS får är ofta i direkt proportion till vår okunnighet om programmering i allmänhet.
Jag är en icke-utvecklare. Jag har ofta använt bibliotek som jQuery, eller enskilda fristående JS-plugins för att få saker gjorda. Ju mer jag behöver göra, ju fler plugins jag behöver för att få allt att fungera. Dessa plugins och ramar kommer med extra alternativ och funktioner som jag aldrig kan använda.
Det finns bandbreddstjälvblod, precis där.
Dessutom kan plugins kanske inte fungera bra tillsammans. De kan sakta ner varandra, eller man kan stoppa en annan från att arbeta helt och hållet.
Det finns bortkastad bearbetningskraft, precis där.
Om du verkligen vill påskynda din webbplats, raka bort millisekunder (eller hela sekunder, i vissa fall) är här vad du behöver göra:
Precis som CSS, är det bäst att hålla JS i externa filer och kopplade till din HTML. Du kanske inte tror att det är så mycket om du inte har mycket JS-kod, och det lägger till en HTTP-begäran, men här är det: externa CSS och JS-filer blir cachade av webbläsaren.
Så när samma sida begärs igen eller andra sidor på din webbplats som använder samma CSS eller JS blir begärda, används de cachade externa filerna istället för att hämtas igen. Det är snabbare sändningstider och lite snabbare bearbetning. Det är värt det extra samtalet till servern varje nu och då.
I grund och botten går teorin så här: webbläsaren gör vad som helst överst på en sidas källkod först. Det är därför saker som taggen går nära toppen.
JavaScript-filer kan dock sakta ner allt genom att stoppa webbläsaren från att göra din HTML tills de laddas. Eftersom de flesta av de vanliga JS-effekterna och pluginsna bara behöver fungera efter att resten av sidan finns på skärmen är detta mindre än perfekt.
Förbättra användarens upplevelse och minska uppfattad laddningstid genom att länka till de externa filerna längst ner på sidan, precis före taggen.
När en användare kommer runt för att interagera med allt som kräver JS, bör det vara klart att gå.
Om du utformar en fullfjädrad app kan du och kanske ignorera det här avsnittet. En bra, flexibel och ljus ram kan ge utvecklare en enorm kant. För små till medelstora webbplatser kan dock en JavaScript-ram vara överkillig. På dessa webbplatser kommer JS mest att användas i baksidan av CMS för att administrera innehåll. På framsidan kan du ha en bildreglage, eller murverklayout eller två. Om du verkligen gillar det kanske du har slutfört automatiskt på sökfältet.
Det mesta innehållet behöver inte fansas upp och animeras så här. JavaScript bör så mycket som möjligt reserveras för att förbättra användarupplevelsen. Att förlita sig på att helt enkelt rätt på en webbplats kan resultera i en långsam, långsam webbplats, särskilt på mobila enheter.
På ett sätt är alla kodramar samma, oavsett om det är JavaScript, PHP, Python, HTML eller CSS: varje funktion är ett gäng kod. När du väljer en ram eller ett plugin för ett jobb, fråga dig själv om du ska använda alla funktioner som erbjuds, eller till och med de flesta av dem.
Om inte, är rammodulen? Kan du välja och välja endast de delar du faktiskt behöver? Om så är fallet, och du tror att filstorleksavvägningen är värt det, så går det med allihop! Annars är det bästa sättet att se vad du kan ta ut mer än vad du kan klämma in.
Inte permanent! Tänka på det här sättet, är det något innehåll eller funktionalitet på din webbplats gjord av JS? Kan folk komma åt det utan att ha aktiverat JS i sina webbläsare?
Om så, då bra. Men om människor inte kan se viktig information, kontakta dig eller navigera ordentligt utan JavaScript, så har du ett problem. Visst kan du lita på de flesta som fortfarande har det aktiverat, men du har alltid fått dessa kantfall.
Hur hänför sig detta till webbhastighet? Föreställ dig hur långsam surfning som kommer att bli om en del av din webbplats plötsligt bara inte fungerar.
Inte allvarligt, om du inte är en utvecklare, och du har budgeten för en, får du en, även för små, enkla jobb. Det är billigare i längden att anställa någon som har erfarenhet av att göra det rätt, en gång.
Om sakerna går hemskt fel (och vi pratar om datorer här, så kommer något att gå fel), kommer de ta reda på vad som gick fel snabbare. De har erfarenhet av att hitta sådana problem och lösa dem. Om inget annat kommer de att vara bättre på att gå igenom de specifika ämnena.
Viktigast av allt kommer de att veta hur man gör vad som behöver göras med mindre kod. Mindre kod (vanligtvis) körs snabbare och (alltid) hämtas snabbare. Det är det enklaste rådet jag kan ge.
(Om du är utvecklare eller lär dig, har jag sammanställt en lista med handledning som ligger längst ner i den här artikeln. Innehållet är några nybörjarguider för att skriva JavaScript som kör snabbt.)
När du tar video ur ekvationen är den största saken på en viss innehållsinriktad webbplats bilderna. Bilder tenderar att vara stora, skrymmande och långsamma som helvete när de inte optimeras.
Nu med att spridningen av näthinnan skärmar oss att använda större bilder om vi vill att det ska se bra ut på varje enhet, kommer problemet inte att bli lättare att lösa. Och värre är det ett problem som är lätt att glömma tills du slutar spendera mer än vad som är avsedd för bandbredd.
När varje byte räknas, har vi inte råd att glömma.
Den goda nyheten är att det här inte är något nytt problem på något sätt. Varför är det bra? Det betyder att det finns massor av potentiella lösningar att välja på, och du kan använda mer än en av dem i taget. Faktum är att det i allmänhet är en bra idé.
Så tills ISP och hostingföretag börjar ge oss all obegränsad fri bandbredd (håll inte andan), här är några saker du kan göra:
Enkelt uttryckt, gör så mycket du kan, visuellt sett, med CSS och JavaScript innan du vänder dig till bilder. Koden kommer alltid att vara billigare att överföra än bilder, så håll fast så mycket som möjligt. Trots bearbetningseffekten som förbrukas av CSS-baserade drop-skuggor, gradienter och liknande, överväger avvägningarna.
Tänk också på att SVG-bilder räknas som "kod" i det här fallet, eftersom det är allt de är: XML-kod som görs som en bild. Således bör de användas närhelst du behöver något vektorrelaterat.
Vad ska vi göra om dem då vi återvänder till ovan nämnda näthinnesskärmar? Hur sparar vi på bandbredd där?
Det här är vart vi vänder oss till elementet och bildsättningsegenskapen . De är relativt nya och inte helt stödda, men de tillåter webbläsare att välja rätt bildstorlek för den enhet som används.
Så medan det här inte kommer att spara någon bandbredd för någon som tittar på din webbplats i deras iMac, är det inte så stor av en affär eftersom de troligen har bredband. Någon på sin telefon får under tiden en mindre version av samma bild, så att de inte väntar för länge.
Många bildstorlekar blir fixade när du lär dig vilken bildformat som ska användas i en viss situation. Jag kunde fortsätta med de specifika bildformaten, hur komprimeringen fungerar osv. Men du behöver bara komma ihåg ett par saker:
Det är verkligen allting. Om du gör det och spelar med optimeringsinställningarna när du sparar bilderna kan du ofta få ganska anständig kvalitet vid relativt små filstorlekar.
Det finns dock ett nytt format som heter WebP, som automatiskt stöds av Chrome och Opera. Google påståenden WebP-filerna är 26% mindre än PNG och 25-34% mindre beroende på några faktorer.
Det här är bra nyheter, förutom två saker: Firefox och IE. Nu, om du inte har något emot att använda fallbacks och ett extra skript, kan du använda WebP-format nu, idag. Bara ladda ner WebPJS , och du är bra att gå.
WebPJS använder JavaScript och lite Flash ( suck ... men det är bara för IE) för att få det att fungera, men det fungerar. Du kan överväga om du behöver tjäna mycket och mycket större bilder snabbt, med nackdelen att det inte fungerar utan JS.
Det finns två typer av kompression som du kan använda på dina bilder. Först har vi lossy kompression . Detta används på lossyformat som JPEG. Det låter dig komprimera en bild om så mycket du vill med förståelsen att kvaliteten blir värre och värre och sämre. Sakerna kommer att bli pixelerade och förlora definitionen.
Lossless kompression används i format som PNG, och kan till viss del minska filstorleken. Men det har sina gränser. Det kommer alltid en punkt där det är omöjligt att göra en bild mindre utan att förlora kvalitet.
Om du har Photoshop eller en liknande avancerad bildredigerare är det ofta bäst att använda dem för att komprimera dina bilder så att du kan se hur utsignalen kommer att se ut när du är klar.
(Automatiska verktyg, speciellt onlineverktyg, har enligt min erfarenhet en tendens till att komprimera saker kanske lite för långt. Jag kommer ändå att lista de bästa komprimeringsverktygen som jag har hittat i länkarna nedan.)
Om du använder ett CMS som WordPress, kommer det automatiskt att ändra storlek på bilder som är för stora. Det är också lätt att hitta plugins som automatiskt komprimerar dem för dig.
Tänk på att jag bara rekommenderar automatisk komprimering i fall där du vet att du ska ladda upp partier och massor av bilder av liknande kvalitet för samma ändamål. En fotoblogg är ett exempel.
Om du kör en webbplats där användarna laddar upp egna bilder, väl ... automatisk resizing och komprimering är ett absolut måste, och det är därför varje socialt nätverk gör det.
Här är några tips som inte passade in i någon av de tre kategorierna ovan.
"Minifiering" av din kod betyder bara att alla extra mellanslag och radbrytningar blir tagna. Detta kan minska filstorleken ganska betydligt.
Det kan låta som mycket arbete, men det finns verktyg där ute för att minimera CSS och JS automatiskt och hålla de minifrerade filerna separata för dina källfiler, av ganska uppenbara skäl.
Som tidigare nämnts kan olika CSS-förprocessorer, i första hand, mata ut all kod i minifierad form.
Om din server är rätt inställd kan hela din kod skickas till webbläsaren i ett komprimerat format. Textfiler komprimerar mycket bra, vilket minskar storleken på filerna som skickas avsevärt.
Nu måste din server ta ett ögonblick eller två för att komprimera filerna som skickas, och användarens webbläsare måste dekomprimera dem, men det är vanligtvis värt att bandet breddas.
För en fullständig förklaring av hur det här fungerar, se Hur man optimerar din webbplats med GZIP-komprimering .
Browserkachning händer automatiskt i viss utsträckning tack vare moderna webbläsare. En webbläsare går till en webbplats och lagrar tillfälligt bilderna och annan information som den hittar där.
På så sätt, om samma användare returnerar inom en viss tid, behöver webbläsaren inte fråga samma bilder om igen. Det laddar bara de som den redan har och begär nya bilder som den inte kan ha.
Det finns dock något du kan göra för att berätta för webbläsare vad du ska cache och hur länge, som ses i den här guiden .
Och då finns det serverhantering. Serverkachning tar i grund och botten bara din webbplats och sätter ett slags "kopia" av det mellan dina användare och din faktiska server. Varför skulle du störa?
Tja, det är särskilt användbart för personer som använder innehållshanteringssystem i stor skala. Att ha dina användare tillgång till en tillfällig kopia av din webbplats istället för den faktiska saken minskar antalet samtal till din databas. Information visas och laddas snabbare eftersom det inte behöver omarbetas varje gång.
Beroende på hur det är inställt kan serverhantering också minska kostnaderna för bandbredd i allmänhet. I grund och botten, desto större är din webbplats, desto mer anledning måste du titta på att cacha den.
Och nu, det avsnitt du har väntat på: listan över länkar! Vi har handledningar och guider, för det mesta, och ett par bildkomprimeringsverktyg att rekommendera.
Yahoo! kan inte vara så stor en överenskommelse som den en gång var, men deras utvecklarnätverk har många bra saker på den. Detta inkluderar deras Bästa praxis för att påskynda din webbplats , som täcker några av de grundläggande sakerna du kan göra. En del av det täcker samma grund som den här artikeln, men det finns också mer.
I introduktionen nämnde jag uppfattad platshastighet, även känd som uppfattad prestanda. Om du vill läsa mer om det, kolla in En nybörjarhandbok för uppfattad prestanda: 4 sätt att få din mobila webbplats att känna som en infödd app .
Effeckt.css är en uppsättning CSS-baserade animeringar som är utformade för att göra snabba, oavsett vilken plattform användaren är på.
Detta är en guide för att se till att din CSS laddas ner och behandlas så snabbt som möjligt av webbläsaren.
När du bara börjar, lär sig att koda korrekt kan vara lika stor en hastighetsökning som några slumpmässiga tips om tricks du kan lära dig. Dålig kod kostar mer när det gäller behandlingstid, så lär dig att göra saker på rätt sätt.
Här är en grundläggande guide som fokuserar mer specifikt på att skriva JavaScript som kör snabbt.
Precis som titeln säger, detta är all råd riktad specifikt till JavaScript V8.
Och ibland kommer du förmodligen att sluta använda jQuery. Om du ska göra det borde du åtminstone veta hur man skriver jQuery-selektorer som inte saktar ner dig. Och här är där Sitepoint har du täckt .
Läs detta för mer information om bildformat på webben. Informationen är lite gammal men fortfarande giltig och bra att veta.
Detta är en mer teknisk guide till bildoptimering som tillhandahålls av Google Developer Network.
Compressor.io är ett av de mer imponerande verktyg som jag personligen stött på. Det är en onlineapp, så du måste ladda upp några filer som du vill komprimera, men det kan göra underverk för JPG. Det erbjuder både lossy och förlustfri komprimeringsalternativ, var och en med ganska fantastiska resultat, och det kan också göra batchbehandling.
Trimage specialiserat på förlustfri komprimering, men den kan installeras på egen dator, på Windows, Mac eller Linux. Eftersom det installeras till din dator (och ja, levereras med olika kommandoradsalternativ samt en GUI) kan den enkelt köras automatiskt som en del av ett utvecklingsprocess.
Som alltid finns det mycket mer att lära. Men beväpnad med informationen vi har tillhandahållit och de resurser vi har länkat till, kommer du att vara på väg till byggplatser och appar som inte irriterar helvetet från dina användare.
Och det är det första steget mot att imponera på dem.