SymLinksIfOwnerMatch performance
Persistente connecties kom je vaak nog wel omheen omdat je dit op twee manieren kunt doen. Met de eerder genoemde Content-Length header, maar ook met Content-Transfer-Encoding: chunked. De laatste is gebruikelijker, en dit is ook wat PHP standaard doet.
Stel we hebben (laten we het even simpel houden) 3 afzonderlijke html/php files waarmee we een pagina opbouwen: header.phtml, page.phtml en footer.phtml
Is het nu beter/slimmer om vanuit een index.php deze pagina's achter elkaar te includen, of is het beter om ze te bufferen en dan in 1x te flushen?
Ozzie PHP op 02/06/2016 15:03:03:
Is het nu beter/slimmer om vanuit een index.php deze pagina's achter elkaar te includen, of is het beter om ze te bufferen en dan in 1x te flushen?
None of the above. Het is geen simpele keuze tussen A of B, maar iets dat je moet profilen.
Dat begint met de waterval in de developer tools van je browser, want daarin kun je meestal vrij snel zien wat de bottleneck is.
Als je naar verschillende use cases kijkt, zie je bijvoorbeeld op de lange lijn van piepkleine respons naar supergrote respons vaak ergens een omslagpunt waar een andere vorm van buffering en compressie sneller wordt. Het laden van een grafisch zware portfoliosite vol foto's is appels en een Ajax-request beantwoorden is peren: die kun je niet met elkaar vergelijken.
Compressie vereist bovendien content negotiation: de client bepaalt welke smaak compressie te behappen is. En niet elke client is hetzelfde, ook dat nog.
Als je ruimere vuistregels zoekt, zijn er wel wat breekpunten waarop je de buffer kunt flushen en content naar de client moet verzenden.
• De Time to First Byte (TTFB) is kritiek voor de beleefde snelheid. De TTFB is mede daarom belangrijk voor SEO. Aangezien je éérst headers moet verzenden en pas daarna content, kun je de outputbuffer flushen na de laatste aanroep van header().
• Je benut parallelle connecties op de client beter als je die zo snel mogelijk aan het werk zet. Dat geldt vooral voor het ophalen van CSS- en JavaScript-bestanden in de <link>- en <script>-tags: heb je die compleet, dan kun je de outputbuffer flushen. Het kan daarnaast wat ander ongemak beperken, zoals een FOUC (Flash Of Unstyled Content).
• Voor de user experience is het belangrijk dat bezoekers zo snel mogelijk beeld hebben. Nou ligt de paginavouw typisch ook zelden op elk device op dezelfde plek, maar zodra je één scherm vol beeld hebt boven de vouw, kun je de outputbuffer flushen.
• Browsers kunnen pagina's sneller renderen als de DOM-documentstructuur eerder compleet is. Ook daarin zit een mooi breekpunt voor het flushen van de outputbuffer: DOM compleet, dan direct aanbieden.
Gewijzigd op 02/06/2016 15:55:39 door Ward van der Put
Moet ik me dan voorstellen dat je eerst ob_start() gebruikt, dan een aantal requires/includes doet en dan ob_flush()? En dan weer verder met ob_start(), weer wat requires/includes en dan weer ob_flush() enz. ?
Quote:
Wel interessant om me eens beter in te verdiepen.
Doe dat dan ook, en kom dan met vragen.