MÄRKSPRÅK OCH STILMALLAR II EXAMINATIONSUPPGIFT 1 HELENE BROGELAND

Transkript

1 MÄRKSPRÅK OCH STILMALLAR II EXAMINATIONSUPPGIFT 1 HELENE BROGELAND 1

2 Innehåll Inledning... 3 Optimering av min webbportfolio... 4 Analys och dokumentation av utgångsläget... 4 Optimeringsaktiviteter... 6 Minimera nyttolasten... 6 Aktivera komprimering... 6 Optimera bilder... 7 Visa skalade bilder... 9 Minifiering... 9 Minimera fördröjning vid sidinläsning Ange bilddimensioner Ange en teckenuppsättning Minska antal request Sammanfattning Optimeringens roll i arbetsflödet Optimeringens effekter för användaren Referenser

3 Inledning Denna rapport behandlar olika aspekter av arbetet med att kunna erbjuda användarna av ens webbplats så bra prestanda som möjligt. En viktig del av detta arbete är optimering av de olika komponenter en webbplats är uppbyggd av. Större delen av rapporten behandlar det praktiska, tekniska jobbet med att optimera den portfolio jag skapat i tidigare kurs. Idag finns ett stort antal sätt som användare får tillgång till internet. Detta gör att både utrustning (skärmstorlekar etc.) och uppkopplingshastighet varierar stort. För att tillmötesgå detta måste man arbeta med optimering. Detta kan både göras på serversidan och i de komponenter som utgör själva webbplatsen. Enligt Stefan Nilsson (medium: online, tillgänglig: vt14/m1-introduktion-till-webboptimering, hämtad: ) kan man dela upp optimeringsinsatserna i följande delar: färre requests CSS-optimering minifiering optimering av media val av webbhotell med hänsyn tagen till möjlighet för komprimering av koden caching på browsersidan webbserverns närhet till användarna möjlighet att avvakta laddning av vissa Javascript Google har stort inflytande i hur man skall angripa detta med optimering. Man betonar vikten av kort överföringstid (pagespeed) och tar hänsyn till detta vid rankning av sidor i sina sökresultat (medium: online, tillgänglig: hämtad: ). För att göra det möjligt för webbutvecklare att åstadkomma detta har Google tagit fram ett antal verktyg som kan ge hjälp till att uppnå maximal optimering. Under optimeringsarbetet av min portfolio har jag bland annat använt tillägget PageSpeed i Google Chrome (se nedan). Det finns även en samling dokument, Google Best Practice (medium: online, tillgänglig: hämtad: ) som ger tips och rekommendationer om hur man skall angripa de olika delarna i optimeringsprocessen. 3

4 Optimering av min webbportfolio Efter examinationen av min portfolio publicerade jag den på (något förändrad från examinationsuppgiften). För att kunna laborera och optimera portfolion så lägger jag ut den examinerade versionen (processanalysen borttagen + tillägg av material från senare kurser) i en undermapp till den officiella hemsidan - dvs på Analys och dokumentation av utgångsläget Efter publicering blir mitt första steg att så långt som möjligt dokumentera och analysera portfolions nuvarande prestanda. Jag använder mig av följande verktyg för att kontrollera prestanda och få förslag på möjliga optimeringar: Network i Google Chrome : för att bland annat få koll på antal request, vilken ordning de olika komponenterna hämtas i och hur lång tid de olika momenten tar. Tillägget PageSpeed i Google Chrome: gör en analys av varje sida och ger förslag på vad som kan göras för att optimera respektive sida (se nedan). PageSpeed Insights: I princip så motsvarar denna tjänst PageSpeed-tillägget i Google Chrome. Jag ser dock en fördel med Insights då verktyget tar hänsyn både till prestanda vid inläsning av webbsida via mobil och dator och ger en ranking av optimeringsgraden för de två delarna. Detta är betydelsefullt eftersom min portfolio är byggd med en responsiv design som gör att sidorna anpassar sig efter storlek på skärm. Dessutom finns ett tillägg i Insights (i BETA-version) som visar användarupplevelsen av analyserad sida. I nuläget är denna del dock inte inräknad i optimeringsgraden. Jag anser att användarupplevelsen är minst lika viktig som den tekniska prestandan och ser fram emot när även denna analys blir en del av helhetsintrycket av en sida när man undersöker den i PageSpeed Insights. 4

5 Det första jag gör är att hämta respektive sida i Google Chrome och kontrollera hur detta görs via Network i Googles verktyg för webbutvecklare. För att inte hämtningarna skall störas av cachade bilder etc så tömmer jag browserns cacheminne mellan varje hämtning. Nedan följer resultaten för respektive sida: Antal requests Överförd datamängd Överföringstid index.html kb 776 ms webbdesigner.html kb 228 ms utbildning.html kb 373 ms arbetsliv.html kb 510 ms foreningsliv.html 10 1,7 MB 2.00 s Efter att ha kontrollerat antal requests, överförd datamängd och överföringstid går jag in i PageSpeed Insights och gör en analys av var och en av sidorna. I ursprungsläget får jag följande optimeringsvärden för respektive sida: mobil dator index.html webbdesigner.html utbildning.html arbetsliv.html foreningsliv.html Det jag kan konstatera av dessa inledande analyser är att sidorna som innehåller lite större bilder (index.html och foreningsliv.html) både har en större överförd datamängd och har en lägre optimeringsgrad. Detta ger en första fingervisning om att jag nog behöver se över min hantering av bilder. 5

6 När jag gör en analys av webbsidorna i PageSpeed-tillägget i Google Chrome får jag följande punkter som verktyget vill att jag skall titta närmare på: Minimera nyttolasten - aktivera komprimering -optimera bilder -visa skalade bilder - förminska HTML - förminska CSS Minimera fördröjning vid sidinläsning -ange bilddimensioner -ange teckenuppsättning Optimeringsaktiviteter Jag väljer att genomföra mina optimeringsaktiviteter enligt de anvisningar/förslag som Google PageSpeed visar (se ovan). Minimera nyttolasten Denna del avser att minska datamängden som överförs när en webbsida hämtas. Aktivera komprimering För att minska mängden överförd data kan man ange att webbservern skall komprimera filerna innan överföringen. Detta kan göras via två olika tekniker, gzip och mod_deflate (medium: online, tillgänglig: hämtad: ). I samband med optimeringsarbetet kontaktar jag mitt webbhotell Binero och frågar hur man går tillväga med att aktivera gzip/deflate för hemsidor liggande hos dem. Enligt svaret från kundtjänst skall man in och redigera i den htaccess-fil som ligger bland mina sidor på webbhotellet. I dagsläget anser jag att mina kunskaper för detta inte är tillräckliga och att det är lite riskabelt att börja ändra i filer på serversidan. 6

7 Optimera bilder Min portfolio innehåller enbart ett fåtal bilder eftersom den inte är uppbyggd som en traditionell sådan. I ursprungsversionen (den examinerade) har jag följande storlek på aktuella bilder: pixlar byte tunhem.jpg 3032* kB motetten.jpg 3032* kB logo_linkedin.jpg 35*34 15kB logo_fb.jpg 35*35 19kB helene.png 250* kB Som synes är flera av bilderna stora, både sett till antal pixlar och filstorleken. Det första, självklara steget blir att minska på antal pixlar för de två översta bilderna. Detta gör jag i Photoshop. När jag sparar de förminskade bilderna väljer jag att spara med en lägre kvalitet än vad som tidigare var fallet. Tillsammans med minskade storleken bidrar detta till mindre filstorlek. Efter dessa ändring har aktuella bilder följande storlek: tunhem.jpg 400* kB motetten.jpg 400*225 76kB I nästa steg gör jag en optimering av alla bilderna i verktyget PNGGauntlet (medium: online, tillgänglig: hämtad: ). Storleken minskar så här: tunhem.jpg 108kB oförändrad motetten.jpg 76kB oförändrad logo_linkedin.jpg 15kB 1,26kB PNGGauntlet har omvandlat till.png logo_fb.jpg 19kB 1,42kB PNGGauntlet har omvandlat till.png helene.png 289kB 128kB 7

8 Jag publicerar bilderna med minskad storlek och kör sedan PageSpeed Insights igen med följande resultat: mobil dator index.html webbdesigner.html utbildning.html arbetsliv.html foreningsliv.html Detta visar att optimeringsgraden ökat för samtliga sidor genom att jag minskat storleken på bilderna. Nästa steg blir att köra PageSped i Google Chrome för att kunna utnyttja att denna analys ger förslag på optimerade versioner av de bilder som applikationen anser behöver optimeras. Jag byter ut aktuella versioner av bilderna till de som PageSpeed optimerat. Efter detta får jag en ökning av optimeringsgraden till 77 resp 90 (istf 74 resp 85) för sidan foreningsliv.html Efter att jag optimerat bilderna gör jag en ny mätning Network i Google Chrome och får följande resultat: Antal requests Överförd datamängd Överföringstid index.html kb 750 ms webbdesigner.html 8 82 kb 410 ms utbildning.html 8 80,8 kb 329 ms arbetsliv.html 8 78,8 kb 372 ms foreningsliv.html kb 567 ms En sista åtgärd rörande optimering av bilder blir att jag kollar vad som händer om jag omvandlar bilderna till Base-64 ( Detta innebär att man gör om bilden till text eftersom img-taggen kan hantera både länk till bild och text (kodad med Base64) (medium: online, tillgänglig: hämtad: ). 8

9 Jag gör detta för bilderna på sidan index.html. Efter att ha publicerat denna sida med Base-64- kodade bilder visar det sig att det blir en lägre optimeringsgrad i PageSpeed Insight (från 79 och 92 till 77 och 89). I Network i Google Chrome får jag 9 requests, 244 kb och 833 ms istället för tidigare 9 requests, 201 kb och 784 ms. I det här fallet visar det sig att jag får en sämre prestanda genom att använda mig av Base-64. På grund av detta ändrar jag tillbaka till normal länkning av bild i index.html Visa skalade bilder Detta innebär att originalbilderna har en annan storlek än vad som visas på skärmen och att HTML eller CSS skalar om till önskad storlek. Önskvärt är att man från början sätter rätt storlek på originalbilden. Om man använder flera olika storlekar av samma bild skall man skala bilden så att storleken matchar största versionen av bilden som skall visas (medium: online, tillgänglig: hämtad: ). Som jag nämner i punkten ovan (optimera bilder) så tog jag inte hänsyn till bildernas storlek när jag ursprungligen skapade min portfolio men i samband med optimeringen har jag anpassat storleken. Eftersom jag har en responsiv design och har satt img {max-width: 100%} så har jag valt att göra bilderna något större än de behöver ha vid visning på relativt stor skärm (jag arbetar själv med upplösningen 1600/900 pixlar). Efter optimeringen av bilderna visar PageSpeed inte aktuell punkt längre. Minifiering Ett sätt att minska överförd datamängd kan vara att göra en så kallad minifiering av koden vilket innebär att man tar bort onödiga tecken, radbrytningar, mellanslag och kommentarer etc. Detta kan göras både för HTML-, CSS- och Javascriptkod (medium: online, tillgänglig: cumulus. ei.hv.se/~imsni/kurser/mss200/vt14/m1-introduktion-till-webboptimering, hämtad: ). Förminska HTML-koden: Jag kör minifiering av HTML-koden via tjänsten Jag får följande resultat: Minskning Minskning i % index.html -1,8kB 58% webbdesigner.html -3,51kB 60% utbildning.html -2,4kB 63% 9

10 arbetsliv.html -1,99kB 55% foreningsliv.html -2,6kB 57% Förminska CSS-koden Jag minifierar CSS-koden via Det blir relativt stor skillnad mellan originalfilen och den minifierade eftersom originalfilen är luftig och rik på kommentarer och utformad för att vara lätt att läsa. Storleken på style.css minskar från 8 kb till 3 kb (minskning med 62,5%). Resultat av minifieringen Efter att ha produktionssatt de minifierade filerna (både CSS och HTML) får jag följande resultat när jag kör PageSpeed Insight: mobil dator index.html webdesigner.html utbildning.html arbetsliv.html foreningsliv.html Jag kör sedan Network i Google Chrome Antal requests Överförd datamängd Överföringstid index.html kb 784 ms webbdesigner.html 8 74,9 kb 613 ms utbildning.html 8 73,6 kb 602 ms arbetsliv.html 8 72 kb 493 ms foreningsliv.html kb 595 ms 10

11 Minimera fördröjning vid sidinläsning Efter att en webbsidas komponenter har laddats ner till klienten gäller det för browsern att ladda, tolka och rendera HTML, CSS och JavaScript. Genom att medvetet arbeta med sin kod och ta hänsyn till hur aktuella webbläsare fungerar kan man förbättra prestandan på klientsidan (medium: online, tillgänglig: hämtad: ). Ange bilddimensioner Genom att ange bildernas dimensioner i antingen HTML- eller CSS-koden så kan man snabba på renderingen av en sida eftersom browsern från början kan reservera plats för en bild kanske redan innan bilden har hunnit laddas ner helt (medium: online, tillgänglig: google.com/speed/ docs/best-practices/rendering#specifyimagedimensions, hämtad: ). Här har jag samma problem som i punkten visa skalade bilder. Eftersom jag vill ha en responsiv hantering av bilderna så är det önskvärt att inte sätta fasta storlekar på dem. Detta skulle i och för sig kunna skötas av media queries men jag anser att känslan av responsiv design till viss del skulle gå förlorad genom detta tillvägagångssätt. Ange en teckenuppsättning Detta innebär att man skall ange en teckenuppsättning i HTTP response header för att browsern redan från början skall veta aktuell teckenuppsättning. Ett alternativ är att ange teckenuppsättningen i en meta-tag i HTML-koden (medium: online, tillgänglig: docs/best-practices/rendering#specifycharsetearly, hämtad: ). PageSpeed påpekar att teckenuppsättning skall anges Jag vet inte riktigt vad som menas med att lägga in teckenuppsättningen i HTTP response header däremot har jag <meta charset=utf-8> i HTML-koden sedan tidigare. Minska antal request Ett sätt att optimera sina webbsidor är att se till att ha så få requests som möjligt, dvs. antal komponenter som skall skickas från servern till browsern. Man kan exempelvis lägga ihop externa CSS-filer eller lägga in CSS-kod direkt i HTML-filen (medium: online, tillgänglig: developers.google.com/speed/docs/best-practices/rtt, hämtad: ). Jag har tre CSS-filer inlänkade på mina sidor, nämligen style.css (innehåller stilmallen för sidorna) och två CSS-filer för olika Google Font. I examinationen av portfolion i den tidigare kursen fick jag kritik för att jag lagt in länkning till Google Font i HTML-filerna och inte i CSS-filen. För att tillmötesgå denna kritik så tar jag och gör 11

12 denna ändring i samband med optimeringsarbetet, dvs. kommenterar bort <link> i HTML och lägger i CSS istället. Det visar sig dock att denna förändring sänker optimeringsgraden en aning enligt PageSpeed Insights (jämfört med ursprungsvärdena innan optimeringsarbetet). mobil dator index.html webbdesigner.html utbildning.html arbetsliv.html foreningsliv.html Detta stämmer helt överens med vad Googles Web Performance Best Practice säger, nämligen att man skall undvika att länka in externa CSS-filer i sin egen fil då det ger en sämre prestanda genom att importen hindrar CSS-filerna från att läsas in parallellt. Istället är det att föredra en inlänkning med <link> i HTML-dokumentet(medium: online, tillgänglig: /speed/docs/best-practices/rtt#avoidcssimport, hämtad: ). Utifrån detta tar jag därför beslutet att behålla den lösning jag haft från början, dvs inlänkning av Google Fonts i HTML-koden istället för i CSS-filen. För att få en uppfattning av hur mycket det skulle göra att ta bort Google Fonts från mina sidor gör jag en snabbtest genom att kommentarmarkera länkarna till Google Fonts i filen index.html. Sedan kör jag både PageSpeed Insight och kollar Network i Google Chrome. Där kan jag se en mycket stor skillnad i prestanda. I PageSpeed Insight ökar optimeringsgraden från 79 och 92 till 89 och 96. Dessutom minskar antal request från 9 till 5 och datamängden från 201kB till 137 kb. Att ta bort användningen av Google Fonts skulle alltså bidra till en mycket ökad prestanda men jag anser att detta även skulle ha en stor påverkan på design/utseende på sidorna så jag behåller Google Fonts i sitt ursprungliga skick. Sammanfattning Precis som jag tror innan jag börjar arbetet med optimeringen så finns det mest att göra angående bilderna på mina sidor. När jag ursprungligen lade in bilderna i portfolion ägnade jag inte så mycket tid till att kolla upp storleken på bilderna, varken själva bildstorleken eller filstorleken. Detta har 12

13 medfört att framförallt två bilder (på sidan foreningsliv.html) var väldigt stora i båda avseendena. Optimeringen av dessa bilder bidrar till att minska mängden som laddas ner från 1,7MB till 194KB. Nedladdningstiden minskar från 2 s till 595 ms. Sammanfattningsvis har jag fått följande förbättringar Överförd datamängd Överföringstid före efter före efter index.html 399 kb 201 kb 776 ms 784 ms webbdesigner.html 113 kb 82 kb 228 ms 613 ms utbildning.html 112 kb 80,8 kb 373 ms 602 ms arbetsliv.html 110 kb 78,8 kb 510 ms 493 ms foreningsliv.html 1,7 MB 202 kb 2.00 s 595 ms Det man främst kan se i ovanstående sammanställning är att det skett en relativt stor minskning av överförd datamängd. Angående förändringen av överföringstid är den svår att jämföra då det kan vara olika faktorer som påverkar, exempelvis gjordes inte allt optimeringsarbete på samma dag. I allmänhet kan jag tydligt märka skillnader på prestandan på mitt fasta fiber-bredband från dag till dag och dessutom varierar prestandan/överföringstiden på de sidor jag administrerar på aktuellt webbhotell. Optimeringsgraden i PageSpeed Insight har utvecklats så här: Mobil Dator före efter före efter index.html webbdesigner.html utbildning.html arbetsliv.html foreningsliv.html

14 Optimeringen har inte inneburit färre requests än tidigare. Som jag tidigare nämnt hade borttagning av Google Fonts både minskat antal request och överföringstid och dessutom ökat optimeringsgraden väsentligt men det hade på verkat helhetsintrycket av mina sidor. Optimeringens roll i arbetsflödet Om man utgår från det aktuella arbetet med att optimera min portfolio så ser jag mycket stor vinst i att man från början tar hänsyn till på vilket sätt man behandlar de bilder som skall användas på en webbsida så att dessa blir optimerade så långt som möjligt. Vid detta arbete måste man bland annat ta hänsyn till krav på kvalité, storlek i pixlar och val av lämpligt bildformat. När man sedan länkar in bilderna i HTML-koden måste man se till att koda dessa rätt. För att få till en snabbare rendering av en bild är det bra att ange bildens storlek antingen i HTML-eller CSS-koden. Det är dock viktigt att man inte använder denna storleksangivelse för att skala ner bilden utan att bilden har ungefär samma storlek på riktigt som den man anger (se även Visa skalade bilder och Ange bilddimensioner ovan). I de webbprojekt jag hittills arbetat med har jag enbart använt mig av en inlänkad CSS-fil (med undantag av där jag utnyttjat Google Font). Jag kan tänka mig att det kan bli aktuellt att använda sig av flera CSS-filer i större projekt. Då får man kanske göra en avvägning om man skall gå tillväga på det sättet eller om det är möjligt att slå ihop dem till en CSS-fil. Google Best Practice (medium: online, tillgänglig: hämtad: ) ger rekommendationer om hur man skall hantera detta. Samma som ovan gäller även om man använder sig av externa Javascript. När man kodar sin CSS bör man ta hänsyn till och skapa effektiv kod som hjälper browsern att tolka och rendera webbsidan. Även här finns det information och hjälp att få från Google Best Practice (medium: online, tillgänglig: hämtad: ). En artikel från CSS Wizardry belyser hur man skriver effektiva CSS-selektorer (medium: online, tillgänglig: hämtad: ). I slutet av artikeln diskuteras hur mycket det är värt att lägga ner arbete på att optimera dessa och slutsatsen är att (som för mycket annat) så är det storleken och komplexiteten på en sida/site som avgör detta. En fråga i samband med optimeringsarbetet är om man skall använda sig av minifiering eller ej. Det jag spontant känner är att detta till viss del kan krångla till arbetet/hanteringen av inblandade filer. För att göra det möjligt att arbeta/uppdatera filerna måste man ha tillgång till en läsbar version av 14

15 dessa. Om man bestämt sig för att tillämpa principen med minifierade filer så måste man se till att behålla en läsbar version som man kan bearbeta och sedan skapar man en minifierad version som produktionssätts. Jag har svårt att bedöma om det merarbete detta medför kompenseras med högre optimeringsgrad av den minifierade koden. Som mycket annat borde minifieringen ha större betydelse ju större filer det rör sig om. Optimeringens effekter för användaren Enligt en rapport från KPBC (medium: online, tillgänglig: internet-trends slide 32, hämtad: ) så ökar andelen mobilt användande av internet med en rasande fart. Användarna kan ha olika typer av skärmar och mer eller mindre snabba uppkopplingar. För att tillmötesgå detta krävs att man kontinuerligt tänker på både responsiv/adaptiv design och på webbplatsernas prestanda i form av mängden requests, överförd data och överföringstid. Enligt en undersökning säger 39 % av användarna att en webbsidas prestanda är mycket viktigare än dess funktionalitet (Friedman et al., 2013, s 119). Genom att ta hänsyn till prestandan redan från början i ett webbutvecklingsprojekt ökar möjligheterna till att man möter användarnas krav och förväntningar. Prestandan skall finnas med som ett primärt mål redan i de inledande projektdokumenten och designförslagen (Friedman et al., 2013, s 124ff). Ett sätt att ta det växande mobila användandet av internet i beaktande är att arbeta med trenden flat-and-thin. Denna innebär att sidorna är stilrena och inte överambitiösa och/eller fullmatade och ger en bra grund för arbete med responsiv /adaptiv design som möjliggör mobilanpassning. Mer om denna trend finns att läsa i en artikel av Adrian Taylor i Smashing Magazine (medium:online, tillgänglig: hämtad: ). Genom att låta tanken på prestanda och arbetet med optimering genomsyra alla olika faser i webbutvecklingen läggs en bra grund för att man skall erhålla nöjda användare. 15

16 Referenser Friedman, Vitaly m.fl. (2013) The Smashing Book #4:New Perspectives on Web Design, Freiburg, Germany: Smashing Media GmbH. cssminifier.com/ csswizardry.com/2011/09/writing-efficient-css-selectors/ cumulus.ei.hv.se/~imsni/kurser/mss200/vt14/m1-introduktion-till-webboptimering developers.google.com/speed/ docs/best-practices/ developers.google.com/speed/pagespeed/insights/ htmlcompressor.com/compressor/ pnggauntlet.com/