Optimaliseren van webshop

[hendrilankamp]

Hoi!

Ik ben al een tijdje bezig met een webshop maar krijg het maar niet snel.
De website (*snip* spam / niet relevant) is gehost bij strato.

Ik heb doormiddel van Google Page speed al het een ander geprobeerd zonder succes.
Maak al gebruik van een CDN voor de afbeeldingen en heb de pluginn WP Fast cache ook al geïnstalleerd.

Volgens Google page speed moet ik gebruik maken van een pre load



Het volgende heb ik dan ook in de header geplakt:
<link rel='preload' href="https://www.domein.nl/wp-content/themes/shop-isle/assets/fonts/flexslider-icon.woff" as="font" type="font/woff" crossorigin>

ook zonder type werkt het niet naar behoren:

<link rel='preload' href="https://www.domein.nl/wp-content/themes/shop-isle/assets/fonts/flexslider-icon.woff" as="font" t>

Iemand enig idee wat ik mis doe? en enige tips om de snelheid te maximaliseren?

[ Voor 9% gewijzigd door RobIII op 14-01-2019 20:53 ]

[Wolfboy]

Ik zou beginnen met een cdn te pakken. Bij die screenshot zie je dat het laden van je flexslider-icon.woff bestand 1.1 seconde kost wat wel belachelijk is. Nu zijn mijn persoonlijke ervaringen bij Strato ook niet bijzonder goed maar als dit tegenwoordig de norm is bij hun hosting dan zou ik toch ook echt gaan zoeken naar een hosting partij die z'n servers minder aan het overbelasten is.

Hoe dan ook, dat specifieke bestand is ook via cdnjs in te laden: https://cdnjs.com/libraries/flexslider
En vermoedelijk zijn er wel meer bestanden waarbij je dat kan doen, dat kan al enorm schelen.

[hendrilankamp]

Wolfboy schreef op maandag 14 januari 2019 @ 21:27:

Hoe dan ook, dat specifieke bestand is ook via cdnjs in te laden: https://cdnjs.com/libraries/flexslider
En vermoedelijk zijn er wel meer bestanden waarbij je dat kan doen, dat kan al enorm schelen.

Helaas geeft dit ook geen prestatie winst.
Een tijd juist gekozen voor strato aangezien deze volgens verschillende website's aardig in de top zat.

[n9iels]

Als ik de website snel bekijk ziet alles er prima uit. De browser caching is ingeschakeld en goed geconfigureerd, je gebruikt Gzip en al je assets (css, js) zijn netjes minified en laden zeer snel. Enige verbeterpunt is dat de bestandsgrootte van de afbeeldingen wat kleiner zou kunnen.

De initiële page load is echter heel verschillend, tussen de 4s en 125ms. De ~5s komt voor bij het open van de pagina voor de eerste keer, de 125ms bij het herladen van deze pagina. De Network tab van Google Chrome laat zien dat dit vooral de TTFB (Time To First Bit) is, oftewel de response tijd van de server. Of dit een niet (correct) geconfigureerde cache of een slechte server is durf ik niet te zeggen. Ik zou contact opnemen met je hoster hiervoor.

[Room42]

hendrilankamp schreef op maandag 14 januari 2019 @ 22:48:
[...]


Helaas geeft dit ook geen prestatie winst.
Een tijd juist gekozen voor strato aangezien deze volgens verschillende website's aardig in de top zat.

[Afbeelding]

In de top met wat? En heb jij dan ook de juiste performance gekozen? Je kunt daar verschillende pakketten en opties kiezen die invloed kunnen hebben op de performance Daarnaast heeft natuurlijk het aantal (en de kwaliteit van de) plugins in Wordpress veel invloed op de performance van de site. Zoals @niels.veer aangeeft is het vaak de tijd voor het opbouwen van de HTML de grootste tijdvreter.
Wat voor pakket heb je bij Strato?

En wat zegt je browser console over de preloads en zo? Krijg je errors of zie je hem netjes geladen worden en welke snelheid zie je daarbij? Dit kun je op de verschillende tabs van de console zien, zoals netwerk.

[ Voor 14% gewijzigd door Room42 op 14-01-2019 23:08 ]

[BarôZZa]

Heb je door dat hij hem twee keer laadt van verschillende locaties?

Eentje van je eigen server en eentje van een CDN

[gitaarwerk]

Ik kan je site niet zien, maar ik heb wel redelijk ervaring met optimalisatie van een grote webshop.
Wat je zou kunnen overwegen is static page generation, als dat mogelijk is. Ik ben bang dat dit niet zo makkelijk gaat voor je. En als je niet zelf veel programmeert of je eigen software is, kan dat nogal een drempel zijn.

Een CDN is tegenwoordig zeker niet meer een oplossing voor alles. Als je HTTP/2 hebt ingeschakeld, kan dit mogelijk ook veel schelen.

Je zou ook kunnen denken aan alle afbeeldingen progressive JPG te maken en geen PNGs voor productafbeeldingen gebruiken. Ook technieken als lazy-loading kan interessant zijn, maar ook dat is vrij specifiek per scenario. Je hebt dan namelijk minder controle over hoe de browser het belangrijkste eerst laad.

Dit is erg front-end gebaseerd. Misschien zijn er meerdere plugins die ook je backend beter maken. Ik kan zo wel wat bedenken aan verbeteringen, maar dan moet je code gaan herschrijven.. en als je je software wilt updaten is dit niet altijd even handig.

Wat je sowieso zou kunnen doen is https://www.webpagetest.org/ gebruiken, en die regelmatig draaien een aantal keer nadat je code is aangepast, zodat je ziet wat er ook gebeurd.

Ook de browserplugin Lighthouse van Google kan handig zijn.

Oh ja; Google raad heel snel AMP (accelerated mobile pages) aan, maar dat is niet altijd beter ;-).

Dingen als fonts zou je ook lokaal kunnen cachen, of met service workers gaan werken, maar dan waan je jezelf in een moeilijk gebied. Dat zijn meer latere stappen.

Ook Javascript onderin laden is een optie, en eventueel derde domeinen prefetchen (van DNS bijvoorbeeld). Dan kan het javascript wat je later inlaad, al een DNS-handshake minder hebben. Alle beetjes helpen.

[ Voor 26% gewijzigd door gitaarwerk op 15-01-2019 16:56 ]

[hendrilankamp]

Room42 schreef op maandag 14 januari 2019 @ 23:05:
[...]

In de top met wat? En heb jij dan ook de juiste performance gekozen? Je kunt daar verschillende pakketten en opties kiezen die invloed kunnen hebben op de performance Daarnaast heeft natuurlijk het aantal (en de kwaliteit van de) plugins in Wordpress veel invloed op de performance van de site. Zoals @niels.veer aangeeft is het vaak de tijd voor het opbouwen van de HTML de grootste tijdvreter.
Wat voor pakket heb je bij Strato?

Tegenwoordig zijn alle pakketen unlimited qua bandbreedte, resources worden niet genoemd.
Het gaat om het Powerweb basic pakket.

Room42 schreef op maandag 14 januari 2019 @ 23:05:
[...]

En wat zegt je browser console over de preloads en zo? Krijg je errors of zie je hem netjes geladen worden en welke snelheid zie je daarbij? Dit kun je op de verschillende tabs van de console zien, zoals netwerk.

Krijg vaak de melding dat de TTFB erg langs is.
Toevallig geeft page speed deze melding nu niet, ik heb zo'n vermoeden dat het te maken heeft met de shared hosting.

BarôZZa schreef op dinsdag 15 januari 2019 @ 12:01:
Heb je door dat hij hem twee keer laadt van verschillende locaties?

Eentje van je eigen server en eentje van een CDN

Ik zie het inderdaad! heb me op Cloudflare aangemeld om gebruik te maken van hun snelle CDN.
Koppeling is nu verbroken, page score valt hierdoor ook 10 punten hoger uit!

gitaarwerk schreef op dinsdag 15 januari 2019 @ 16:51:

Een CDN is tegenwoordig zeker niet meer een oplossing voor alles. Als je HTTP/2 hebt ingeschakeld, kan dit mogelijk ook veel schelen.

Interessant! heb al aardig wat gehoord over HTTP/2, heb eerlijk gezegd geen idee of strato hier klaar voor is. Ik ga eens op onderzoek uit!

gitaarwerk schreef op dinsdag 15 januari 2019 @ 16:51:
Je zou ook kunnen denken aan alle afbeeldingen progressive JPG te maken en geen PNGs voor productafbeeldingen gebruiken. Ook technieken als lazy-loading kan interessant zijn, maar ook dat is vrij specifiek per scenario. Je hebt dan namelijk minder controle over hoe de browser het belangrijkste eerst laad.

Op dit moment gebruik ik een plugin waarmee ik gemakkelijk producten kan uploaden, het handmatig uploaden van de afbeeldingen zou erg tijdrovend zijn.

Wel kan ik onderzoek doen of er een andere tool is om deze afbeeldingen in een ander formaat te uploaden.

gitaarwerk schreef op dinsdag 15 januari 2019 @ 16:51:
Dit is erg front-end gebaseerd. Misschien zijn er meerdere plugins die ook je backend beter maken. Ik kan zo wel wat bedenken aan verbeteringen, maar dan moet je code gaan herschrijven.. en als je je software wilt updaten is dit niet altijd even handig.

Wat je sowieso zou kunnen doen is https://www.webpagetest.org/ gebruiken, en die regelmatig draaien een aantal keer nadat je code is aangepast, zodat je ziet wat er ook gebeurd.


Dingen als fonts zou je ook lokaal kunnen cachen, of met service workers gaan werken, maar dan waan je jezelf in een moeilijk gebied. Dat zijn meer latere stappen.

Het verbeteren van de back end ben ik al mee bezig, op dit moment gebruik ik een plugin welke volgens mij ook veel resources gebruikt, helaas heeft het uitschakelen geen effect op de snelheid volgens Googles Page Speed.

Webpagetest.org is helaas momenteel niet te gebruiken. Zal het vandaag nog eens proberen.

[Wolfboy]

hendrilankamp schreef op maandag 14 januari 2019 @ 22:48:
[...]


Helaas geeft dit ook geen prestatie winst.
Een tijd juist gekozen voor strato aangezien deze volgens verschillende website's aardig in de top zat.

Ik heb even naar je site gekeken en het probleem met dat woff bestand is niet de trage hosting van strato maar dat de pagina niet bestaat en dat 404's (pagina niet gevonden) blijkbaar extreem traag is bij je wordpress installatie.

Een cdn zou daarvoor dus sowieso helpen omdat je dan dus niet meer die 404 krijgt.

Sowieso wel een goed plan om eens een 404 detectie plugin toe te voegen aan wordpress (of zit dat er standaard in?).

[gitaarwerk]

404s betreft assets zorgen dat je pagina erg lang laad. 404s zijn echt killing.

Google Fonts is op sich wel fijn. De edge routers zullen dit in alle delen van de wereld snel serveren.

[DJMaze]

hendrilankamp schreef op woensdag 16 januari 2019 @ 08:46:
Krijg vaak de melding dat de TTFB erg langs is.
Toevallig geeft page speed deze melding nu niet, ik heb zo'n vermoeden dat het te maken heeft met de shared hosting.

Nee, dat heet WordPress. Hier een WooCommerce:
- zonder poespas: 8s TTFB
- dedicated + FPM: 2s TTFB
- cache (varnish/cloudflare/etc): 100ms - 2s

Het is heel normaal in de wereld van WordPress....

gitaarwerk schreef op donderdag 17 januari 2019 @ 10:28:
Google Fonts is op sich wel fijn. De edge routers zullen dit in alle delen van de wereld snel serveren.

Geen fonts is nog fijner, die serveer je nog sneller omdat die al lokaal op de PC staan.

[gitaarwerk]

DJMaze schreef op donderdag 17 januari 2019 @ 10:55:

[...]

Geen fonts is nog fijner, die serveer je nog sneller omdat die al lokaal op de PC staan.

Ik wilde die bijna opperen, maarja, style is soms ook wel belangrijk. Dan kun je ook stoppen met een hoop andere dingen Je zou fonts kunnen delegeren naar een later request en die dan in localstorage opslaan (of service workers)