Laadtijd beperken
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
18 reacties op 'Laadtijd beperken'
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 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 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 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 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 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.
- Details
Door:
Wim Mari- 6 jaar geleden
- 1.071 x bekeken
- PHP tutorials opties
- Berekeningen
- Nieuwste PHP tutorials
- PHP tutorial toevoegen
PHP hulp
0 seconden vanaf nu