adeneo
Medlem
For det første, så vil du nesten aldri oppnå noe voldsomt gode resultater i slike sidelastningstester med et CMS som PrestaShop.
For det andre, så er ikke slike tester nødvendigvis fasiten, det er opplevd tid for å laste inn sidene som er viktig, ikke hva YSlow mener.
For det tredje, er noen av de punktene enkle å fikse, andre noe verre, og andre igjen helt unødvendige.
Make fewer HTTP requests
Det er jo ikke alltid så lett å pakke ressurser å gjøre færre forespørsler i et CMS, det kan faktisk være nesten umulig, selv om det sikkert finnes ymse plugins til PrestaShop også, hvorvidt det virkelig hjelper på lastetidene er diskutabelt.
Det er også slik at HTTP/2 etterhvert vil gjøre dette punktet langt mindre viktig, i mange tilfeller helt unødvendig, ettersom HTTP/2 langt på vei løser mange av problemene med å laste mange små ressurser samtidig.
Add Expires headers
Dette bør være relativt enkelt å fikse, så fremt det er snakk om ressurser fra egen server. Det er kun å legge til et sett header's som sier noe om hvor lenge ressursen skal caches.
Compress components with gzip
Komprimering bør jo normalt være slått på som default, og er også enkelt å implementere, og bør gjøres.
Use a Content Delivery Network (CDN)
Dette er et av de tåpeligste YSlow punktene, det er jo ikke slik at alle absolutt må bruke en CDN for statisk innhold.
Det er enkelt å implementere dette, men det koster jo litt å skulle betale for CDN løsninger.
Med mindre siden har forholdsvis store mengder trafikk, er dette helt unødvendig.
Use cookie-free domains
Samme som ovenfor, enkelt å sette opp, men koster litt.
Det er snakk om løsninger hvor alle statiske ressurser leveres over et eget domene for å unngå overhead'en med cookies, som jo sendes i alle forespørsler, også når en .css fil skal hentes eller lignende, som er unødvendig sending av bytes.
For eksempel benytter Finn "finncdn . no" for statisk innhold, Google benytter "sstatic . com" eller noe sånt, men det betyr jo ikke at bloggen til Ola Normann bør gjøre det på den måten, det er for det meste helt unødvendig for mindre nettsider.
Reduce DNS lookups
Dette betyr rett og slett at det gjøres for mange oppslag i DNS.
Et oppslag i DNS gjøres hver gang et domene må "mappes" til en IP adresse, for at nettleseren skal finne frem.
Mange lenker til statiske ressurser på forskjellige domener, fører til mange DNS oppslag.
I dag er dette vanskelig å redusere, særlig i et CMS, ressurser som hentes fra Google, Facebook, Twitter, og en hel haug med andre steder, er styggedom, men vanskelig å gjøre noe med, og jo flere forskjellige domenenavn som må slås opp i DNS, jo lengre tid tar ting.
Reduce the number of DOM elements
Dette er et punkt som er nærmest umulig å gjøre noe med i et CMS, man har jo ingen mulighet til å redusere antall elementer, og de fleste slike CMS spytter ut elementer i enorme mengder.
Alt i alt, så er det eneste du egentlig MÅ gjøre på den listen, å få orden på cachingen og komprimeringen av statiske ressurser.
Merk dog at YSlow, og selv Google's egen PageSpeed, gir den "expires headers" meldingen selv om du har alt i orden, men for eksempel benytter Google Analytics, ettersom Google selv har manglende Expires headere på Analytics scriptet sitt, det samme gjelder enkelte andre slike filer fra eksterne nettsteder.
For det andre, så er ikke slike tester nødvendigvis fasiten, det er opplevd tid for å laste inn sidene som er viktig, ikke hva YSlow mener.
For det tredje, er noen av de punktene enkle å fikse, andre noe verre, og andre igjen helt unødvendige.
Make fewer HTTP requests
Det er jo ikke alltid så lett å pakke ressurser å gjøre færre forespørsler i et CMS, det kan faktisk være nesten umulig, selv om det sikkert finnes ymse plugins til PrestaShop også, hvorvidt det virkelig hjelper på lastetidene er diskutabelt.
Det er også slik at HTTP/2 etterhvert vil gjøre dette punktet langt mindre viktig, i mange tilfeller helt unødvendig, ettersom HTTP/2 langt på vei løser mange av problemene med å laste mange små ressurser samtidig.
Add Expires headers
Dette bør være relativt enkelt å fikse, så fremt det er snakk om ressurser fra egen server. Det er kun å legge til et sett header's som sier noe om hvor lenge ressursen skal caches.
Compress components with gzip
Komprimering bør jo normalt være slått på som default, og er også enkelt å implementere, og bør gjøres.
Use a Content Delivery Network (CDN)
Dette er et av de tåpeligste YSlow punktene, det er jo ikke slik at alle absolutt må bruke en CDN for statisk innhold.
Det er enkelt å implementere dette, men det koster jo litt å skulle betale for CDN løsninger.
Med mindre siden har forholdsvis store mengder trafikk, er dette helt unødvendig.
Use cookie-free domains
Samme som ovenfor, enkelt å sette opp, men koster litt.
Det er snakk om løsninger hvor alle statiske ressurser leveres over et eget domene for å unngå overhead'en med cookies, som jo sendes i alle forespørsler, også når en .css fil skal hentes eller lignende, som er unødvendig sending av bytes.
For eksempel benytter Finn "finncdn . no" for statisk innhold, Google benytter "sstatic . com" eller noe sånt, men det betyr jo ikke at bloggen til Ola Normann bør gjøre det på den måten, det er for det meste helt unødvendig for mindre nettsider.
Reduce DNS lookups
Dette betyr rett og slett at det gjøres for mange oppslag i DNS.
Et oppslag i DNS gjøres hver gang et domene må "mappes" til en IP adresse, for at nettleseren skal finne frem.
Mange lenker til statiske ressurser på forskjellige domener, fører til mange DNS oppslag.
I dag er dette vanskelig å redusere, særlig i et CMS, ressurser som hentes fra Google, Facebook, Twitter, og en hel haug med andre steder, er styggedom, men vanskelig å gjøre noe med, og jo flere forskjellige domenenavn som må slås opp i DNS, jo lengre tid tar ting.
Reduce the number of DOM elements
Dette er et punkt som er nærmest umulig å gjøre noe med i et CMS, man har jo ingen mulighet til å redusere antall elementer, og de fleste slike CMS spytter ut elementer i enorme mengder.
Alt i alt, så er det eneste du egentlig MÅ gjøre på den listen, å få orden på cachingen og komprimeringen av statiske ressurser.
Merk dog at YSlow, og selv Google's egen PageSpeed, gir den "expires headers" meldingen selv om du har alt i orden, men for eksempel benytter Google Analytics, ettersom Google selv har manglende Expires headere på Analytics scriptet sitt, det samme gjelder enkelte andre slike filer fra eksterne nettsteder.