Wat voor frontend/web performance optimalisatie geldt, geldt ook voor PHP. Op beide vlakken zou geoptimaliseerd moeten worden, en de mate waarin dit kan, hangt af van het gebruikte framework of CMS, en de aanwezige kennis op deze vlakken.
Dit is een vervolg op PHP optimalisatie in Wordpress CMS
Vroegtijdig optimaliseren
Een frontend programmeur zal zich voornamelijk bezig houden met client side talen als HTML, CSS en JavaScript. De backend programmeur zou de juiste bagage moeten hebben om aan de server side optimalisaties door te voeren (indien van toepassing).
Direct optimaliseren? Het houdt je niet alleen van je kernteken (functies programmeren), ook is het eenvoudiger om correcte code te optimaliseren, dan geoptimaliseerde code te corrigeren. En soms gaat onderhoudbaarheid, boven kwaliteit.
Echter, dit zou je er niet van moeten weerhouden om op zijn minst best practices mee te nemen of eenvoudige issues bij voorbaat te voorkomen. Achteraf optimaliseren van veel substantiële delen code die op voorhand tot de aanwezige kennis had moeten behoren, kan ook een doorn in het oog zijn. De grote bottlenecks optimaliseer je achteraf.
De meer bekende PHP optimalisaties
Al bij het schrijven van mijn eerste CMS, nam ik alle stof dat ik opdeed, mee. Bijvoorbeeld booleans en null-aanduidingen in kleine letters uittypen. Booleans uitgetypt in kleine letters, is sneller dan wanneer je hier hoofdletters voor gebruikt. Echo versus print, en string concatenatie voor variabelen, in plaats van de variabelen inlinen in double quotes zijn andere voorbeelden.
Single quotes vs double quotes
De keuze hoeft tegenwoordig niet meer voort te komen uit snelheids-winst. Inmiddels lijkt het verschil te zijn glad gestreken, en zal het gebruik van single of double qutoes bij meerendeel van de PHP programmeurs inmiddels een kwestie van voorkeur in combinatie met leesbaarheid zijn.
Het verschil is in bovenstaande gevallen per stuk uiteraard verwaarloosbaar. Totdat je een uit de klauwen gewassen framework gebruikt. Bovendien ben ik voor elke vorm van optimalisatie door de gehele PHP applicatie. Aan het eind van de rit heb je (verhoudingsgewijs) wellicht een wereld van verschil gewonnen aan tijd.
Langzame functies
In mijn eerste dagen in PHP (inmiddels 13 jaar geleden), was ik niet bekend met alle functies, en viel ik terug op functies die ik kende. Niet zo gek, PHP telt heden ten dage bijvoorbeeld ruim 5.500 functies.
Ik gebruikte functies, die in eerste instantie geschikt leken voor het doel, maar het tegendeel bleek soms waar. Zo gebruikte ik explode in combinatie met array_pop om een bestands-extensie op te halen (en ja: geen notice toentertijd die zei dat het resultaat van explode niet direct hergebruikt mocht worden als functie-parameter).
$extension = array_pop( explode('.', $filename ) );
Niet veel later ontdekte ik dat strpos in combinatie met substring sneller was. Maar al die tijd was er een speficieke functie voor dit doel: pathinfo in combinatie met de PAHTINFO_EXTENSION-flag.
Ook reguliere expressies zou vermeden moeten worden wanneer mogelijk en zelfs in array gebruik valt soms winst te behalen door op andere wijze controles of mutaties te doen (later meer). Eigen dompers meegemaakt, of functies die je voor bepaalde doelen misbruikte?