Laadtijd beperken
Door Wim Mari, 21 jaar geleden, 7.144x bekeken
Het beperken van de laadtijd doet veel. Geef nu zelf toe, je komt liever op een website die onmiddelijk geladen is, dan eentje die er 2 seconden over doet!
Een online voorbeeld: http://gdx.be/time.vars.php
Gesponsorde koppelingen
Inhoudsopgave
Er zijn 18 reacties op 'Laadtijd beperken'
0 
-0 
-0
Als je die uitkomsten in het voorbeeld even deeld door bijv 1000 is het wat makkelijker te zien wat nou precies het verschil is.
0 -0
-0
Is het niet zo dat deze enorm kleine verschillen niet volledig wegvallen waneer je bijvoorbeeld een plaatje meer of minder op de website zet? Of dat er 3 in plaats van 4 pagina's op het zelfde moment moeten worden geserveerd?
Wat ik wil zeggen is, snelheidswinst zit hem in de opbouw van de layout (divs zijn sneller dan tabellen, weinig plaatjes sneller dan veel, veel externe bestanden weer langzaam, want er worden maar 2 tegelijkertijd binnen gehaald etc. etc.) en in de intensieve delen. Een lus die 1000+ rondjes draait, die wil je effici?nt hebben. Een database-query. Externe bestanden inladen (include etc.)
Wat ik wil zeggen is, snelheidswinst zit hem in de opbouw van de layout (divs zijn sneller dan tabellen, weinig plaatjes sneller dan veel, veel externe bestanden weer langzaam, want er worden maar 2 tegelijkertijd binnen gehaald etc. etc.) en in de intensieve delen. Een lus die 1000+ rondjes draait, die wil je effici?nt hebben. Een database-query. Externe bestanden inladen (include etc.)
0 -0
-0
Ja, inderdaad. Wat Jelmer zegt mis ik nog in je tutorial... Verder die kleine details wist ik niet..
0 -0
-0
Inderdaad... Als je een .css bestand bijvoorbeeld appart inlaad duurt dit langer als dat je gewoon de css code ook in het .html bestand zet... en dan spreek ik niet over een paar milliseconden maar soms zelfs al over 100 miliseconden per css bestand... Kijk maar eens rond in FireBug in FF daar staat er altijd bij hoe snel een bestand laad...
0 -0
-0
Deze tutorial gaat duidelijk over het beperken van code laadtijd.
Het feit dat 'downloaden en verwerken' van minder bestanden/data een kortere laadtijd heeft lijkt me logisch..
Het feit dat 'downloaden en verwerken' van minder bestanden/data een kortere laadtijd heeft lijkt me logisch..
0 -0
-0
Ja IDD dat lijkt mij erg logiche..
maar het blijft wel hoe sneller je website geladen is en geladen word hoe langer de bezoekers zullen blijfen en ze zullen dan minder snel uit irritatie je site verlaten van de wachttijden.
Groetjes.
maar het blijft wel hoe sneller je website geladen is en geladen word hoe langer de bezoekers zullen blijfen en ze zullen dan minder snel uit irritatie je site verlaten van de wachttijden.
Groetjes.
0 -0
-0
ik mis nog echt veel te veel om dit een goede tut te vinden, ook door wat hierboven staat , maar ook wat je nog zou kunnen beperken in de code (kijk maar eens het verschil tussen een "string" en een 'string', je zal zien dat de 2e vele malen zo snel is.
Ook een mysql_fetch_* heb je nog verschillende laad-tijden van..
en zo zijn er nog wel een paar..
Ook een mysql_fetch_* heb je nog verschillende laad-tijden van..
en zo zijn er nog wel een paar..
Edit:
typo
0 -0
-0
Terence: wordt door de loop van deze week geupdate, mss vanavond al, anders waarschijnlijk in het weekend! (heb momenteel examens)
0 -0
-0
Eerlijk gezegd vind ik dit een matige tutorial. Wellicht is je ervaring op dit gebied nog niet zo breed maar er zijn nog veel meer dingen die je kunt doen om performance te verbeteren, en zelfs met grote stappen:
- Cachen (Zend_Cache bijvoorbeeld)
- Profilen van stukken code
- Kiezen van loop structuren (while,foreach,for,switch, etc)
- Typecasten
- Declareren van variabelen en gebruiken van references
- Het vrijmaken van resources (bestanden, GD resources, objecten) en het gebruik maken van constructors
- Gebruik van recursieve functionaliteit
- Includen van bestanden
- Voor compilen van je code
En zo kan ik nog ff doorgaan :p, maar ik wil ook niet te zeikerig overkomen het is een begin en dat is goed!
Misschien dat ik een complete tutorial maak binnenkort, of ik stuur wat op naar je zodat je deze aan kan vullen.
Groeten,
Kees.
- Cachen (Zend_Cache bijvoorbeeld)
- Profilen van stukken code
- Kiezen van loop structuren (while,foreach,for,switch, etc)
- Typecasten
- Declareren van variabelen en gebruiken van references
- Het vrijmaken van resources (bestanden, GD resources, objecten) en het gebruik maken van constructors
- Gebruik van recursieve functionaliteit
- Includen van bestanden
- Voor compilen van je code
En zo kan ik nog ff doorgaan :p, maar ik wil ook niet te zeikerig overkomen het is een begin en dat is goed!
Misschien dat ik een complete tutorial maak binnenkort, of ik stuur wat op naar je zodat je deze aan kan vullen.
Groeten,
Kees.
0 -0
-0
Leuk dat er aandacht wordt besteed aan performance. Helaas is het wel zo dat genoemde onderdelen nauwelijks invloed hebben op de beleving van de bezoeker. Of je nu 0.0001 of 0.1 seconden moet wachten (factor 1000 verschil), het is in beide gevallen voor een bezoeker 'onmeetbaar' en nog steeds razendsnel.
Het downloaden van pagina's (alle plaatjes, html, css en js) kost vele malen meer tijd dan wat je met een variabele buiten quotes kunt winnen. Dit geldt ook voor het gebruik van databases, het maken van een verbinding met de database kost relatief veel tijd. Een slecht datamodel of een slecht opgestelde query kunnen ook dodelijk zijn voor de performance.
Met netjes scripten is natuurlijk niets mis, maar het zal op zich niet zo heel veel uitmaken voor de beleving van de website.
En vergeet niet: Meten is weten! Ga dus eerst benchmarken en daarna pas de boel optimaliseren.
Externe css, externe js, totale pagina niet groter dan 50kb, dat zijn de onderdelen waarmee je punten kunt scoren!
Het downloaden van pagina's (alle plaatjes, html, css en js) kost vele malen meer tijd dan wat je met een variabele buiten quotes kunt winnen. Dit geldt ook voor het gebruik van databases, het maken van een verbinding met de database kost relatief veel tijd. Een slecht datamodel of een slecht opgestelde query kunnen ook dodelijk zijn voor de performance.
Met netjes scripten is natuurlijk niets mis, maar het zal op zich niet zo heel veel uitmaken voor de beleving van de website.
En vergeet niet: Meten is weten! Ga dus eerst benchmarken en daarna pas de boel optimaliseren.
Externe css, externe js, totale pagina niet groter dan 50kb, dat zijn de onderdelen waarmee je punten kunt scoren!
0 -0
-0
Hier nog een aantal aanvullingen: http://trac.devpoint.be/wiki/Tutorials/PHP_Optimalisatie
0 -0
-0
@mebus, toch is aparte .css bestanden vaak sneller omdat die in de cache blijven staan
0 -0
-0
Even als reactie op Frank,
Ik heb wel degelijk veel performance kunnen winen met een van mijn projecten code technisch gezien. Dit gaat om hele tienden maar heeft wel veel te maken met de keuze uit loops, cachen van stukken code, efficienter omgaan met arrays etc.
Daarnaast sluit ik je wel aan bij het punt betreft databases. Sterker nog daar zijn bij vooral grotere applicaties enorme winst boekingen te halen. Zo kun je met het maken van goede indexen, kiezen van goede datatypes, etc soms hele seconden besparen!
Maar aan de andere kant, effiecient / netjes programmeren en dus positief in performance beeld geeft ook de server minder belasting wat zeker van belang kan zijn als het om bijvoorbeeld een server gaat waar een applicatie draait voor meerdere gebruikers.
Wat ook een optie is, wellicht een enorm dure optie is Zend Platform dit is een zeer uitgebreide tool voor het profilen van scripts, database queries etc.
Ik pleit eigenlijk voor een completere tutorial die de volgende onderwerpen aanpakt:
- Database performance
- Code performance (PHP)
- HTML performance
- CSS
- Afbeeldingen
Een soort van guideline voor het sneller maken van je website.
Owja output buffering ook vergeten net.
Ik heb wel degelijk veel performance kunnen winen met een van mijn projecten code technisch gezien. Dit gaat om hele tienden maar heeft wel veel te maken met de keuze uit loops, cachen van stukken code, efficienter omgaan met arrays etc.
Daarnaast sluit ik je wel aan bij het punt betreft databases. Sterker nog daar zijn bij vooral grotere applicaties enorme winst boekingen te halen. Zo kun je met het maken van goede indexen, kiezen van goede datatypes, etc soms hele seconden besparen!
Maar aan de andere kant, effiecient / netjes programmeren en dus positief in performance beeld geeft ook de server minder belasting wat zeker van belang kan zijn als het om bijvoorbeeld een server gaat waar een applicatie draait voor meerdere gebruikers.
Wat ook een optie is, wellicht een enorm dure optie is Zend Platform dit is een zeer uitgebreide tool voor het profilen van scripts, database queries etc.
Ik pleit eigenlijk voor een completere tutorial die de volgende onderwerpen aanpakt:
- Database performance
- Code performance (PHP)
- HTML performance
- CSS
- Afbeeldingen
Een soort van guideline voor het sneller maken van je website.
Owja output buffering ook vergeten net.
Mod edit:
Link weggehaald (kan ook gezegd worden zonder link)
0 -0
-0
qua caching heb ik hier ook al een classe gepost.
Maar, aan iedereen die zegt het zijn slechts honderden van seconden, je hebt gelijk! Half dan toch!
In een scriptje van 100 lijnen zal dit niet veel uitmaken, maar kijk naar een groot project, en dan kan het soms heel wat verschillen.
Ook als je gebruik maakt van sockets (bvb een php server draaien die luisterd op een bepaalde poort), dan gaat het verschil soms wel merkbaar zijn, aangezien client en servern in php gescript kunnen zijn.
Stel, een script is zo groot dat er 0.01seconde vertraging opzit. Nu moeten er 100 pakketjes verzonden worden (wat uiteindelijk veel is, maar eventueel wel mogelijk). De laadtijd is dan al 1 seconde langer! (denk bvb aan Telnet StarWars, open maar eens een telnet connectie naar towel.blinkenlights.nl)
Maar, aan iedereen die zegt het zijn slechts honderden van seconden, je hebt gelijk! Half dan toch!
In een scriptje van 100 lijnen zal dit niet veel uitmaken, maar kijk naar een groot project, en dan kan het soms heel wat verschillen.
Ook als je gebruik maakt van sockets (bvb een php server draaien die luisterd op een bepaalde poort), dan gaat het verschil soms wel merkbaar zijn, aangezien client en servern in php gescript kunnen zijn.
Stel, een script is zo groot dat er 0.01seconde vertraging opzit. Nu moeten er 100 pakketjes verzonden worden (wat uiteindelijk veel is, maar eventueel wel mogelijk). De laadtijd is dan al 1 seconde langer! (denk bvb aan Telnet StarWars, open maar eens een telnet connectie naar towel.blinkenlights.nl)
0 -0
-0
Hier een voorbeeldje van een website en de omvang van de bestanden:
Zoals je kunt zien, heeft 1 pagina 355 kb nodig (volgens FireFox). Dat is flink wat, persoonlijk probeer ik 50 kb aan te houden. Wil je deze pagina gaan optimaliseren, dan is het zaak om eerst de grootste jongens aan te pakken, de images (182 kb) en de scripts (95 kb).
Stel dat je de kb's van de images weet te halveren (91 kb), dan heb je al een 25% gewonnen. Reken er maar op dat je daarmee ook flinke tijdswinst pakt!
En wat betreft de database, mijn ervaring is dat je in PostgreSQL flink tijd kunt winnen door slim gebruik te maken van stored procedures. Wat je anders via PHP met tig queries moet oplossen (tig keer dataverkeer tussen de webserver en de databaseserver) kun je dan met 1 aanroep via een procedure doen. Die regelt vervolgens alles intern in de database.
De HTML kun je opschonen door alle overbodige spaties, tabs en enters eruit te gooien. De browser doet er toch niets mee en voor de bezoeker maakt het geen ene moer uit dat de html-code nauwelijks leesbaar is.
Minder dataverkeer levert een snellere site op en lagere kosten. Dataverkeer is tenslotte niet gratis. Oh ja, niet te vergeten, tevreden bezoekers!
Code (php)
1
2
3
4
5
6
2
3
4
5
6
Documents (8 files) 36 kb (97 kb uncompressed)
Images (42 files) 182 kb
Objects (0 files)
Scripts (12 files) 95 kb (110 kb uncompressed)
Style Sheets (8 files) 42 kb
Total 355 kb (431 kb uncompressed)
Images (42 files) 182 kb
Objects (0 files)
Scripts (12 files) 95 kb (110 kb uncompressed)
Style Sheets (8 files) 42 kb
Total 355 kb (431 kb uncompressed)
Zoals je kunt zien, heeft 1 pagina 355 kb nodig (volgens FireFox). Dat is flink wat, persoonlijk probeer ik 50 kb aan te houden. Wil je deze pagina gaan optimaliseren, dan is het zaak om eerst de grootste jongens aan te pakken, de images (182 kb) en de scripts (95 kb).
Stel dat je de kb's van de images weet te halveren (91 kb), dan heb je al een 25% gewonnen. Reken er maar op dat je daarmee ook flinke tijdswinst pakt!
En wat betreft de database, mijn ervaring is dat je in PostgreSQL flink tijd kunt winnen door slim gebruik te maken van stored procedures. Wat je anders via PHP met tig queries moet oplossen (tig keer dataverkeer tussen de webserver en de databaseserver) kun je dan met 1 aanroep via een procedure doen. Die regelt vervolgens alles intern in de database.
De HTML kun je opschonen door alle overbodige spaties, tabs en enters eruit te gooien. De browser doet er toch niets mee en voor de bezoeker maakt het geen ene moer uit dat de html-code nauwelijks leesbaar is.
Minder dataverkeer levert een snellere site op en lagere kosten. Dataverkeer is tenslotte niet gratis. Oh ja, niet te vergeten, tevreden bezoekers!
0 -0
-0
Ik zal je geen ongelijk gaan geven want bepaalde methodes zullen onder php sneller werken. Maar hoe concreet is je tijds meting, is dit een gemiddelde van diverse run's of een gegeven van 1x testen en dan de waardes opschrijven?
0 -0
-0
Ik vindt dit een zeer leerzaam stuk, toevallig was ik met zoiets in C bezig. Maar hoe dan ook, dit stuk is handig om te lezen en toe te passen, alhoewel de impact laag is.
0 -0
-0
Zet de volgende regels even in je .htaccess en Apache zal de boel gaan comprimeren. Scheelt weer ietjes.
Voor de details mag je de handleiding van Apache er even op naslaan.
Een html-pagina van 20162 bytes wordt afhankelijk van het level gecomprimeerd tot:
Geef je geen level op, dan wordt standaard level 6 genomen.
Compressie kost wel iets performance van de cpu, maar dat mag geen naam hebben.
Code (php)
1
2
2
php_flag zlib.output_compression On
php_value zlib.output_compression_level 5
php_value zlib.output_compression_level 5
Voor de details mag je de handleiding van Apache er even op naslaan.
Een html-pagina van 20162 bytes wordt afhankelijk van het level gecomprimeerd tot:
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
6779 bytes
6690 bytes
6591 bytes
6264 bytes
6147 bytes
6134 bytes
6127 bytes
6127 bytes
6125 bytes
6690 bytes
6591 bytes
6264 bytes
6147 bytes
6134 bytes
6127 bytes
6127 bytes
6125 bytes
Geef je geen level op, dan wordt standaard level 6 genomen.
Compressie kost wel iets performance van de cpu, maar dat mag geen naam hebben.
Om te reageren heb je een account nodig en je moet ingelogd zijn.
PHP hulp
0 seconden vanaf nu