Alhoewel een voortborduursel op reguliere expressies, behoort DomDocument in mijn optiek niet meer tot de categorie micro-optimalisatie. Daar is het relatief gezien te langzaam voor, maar daar krijgen we een betrouwbare methode voor HTML manipulatie voor terug!
Dit is een vervolg op PHP optimalisatie: reguliere expressies
DomDocument nadelen
DomDocument library is jaren getest en doorontwikkeld, wat het voor HTML manipulatie en ontleding betrouwbaarder maakt dan reguliere expressies. Het nadeel van DomDocument is dat een gehele ingeladen DOM structuur direct geparsed wordt, wat het een beduidend langzamer alternatief kan maken dan het gebruik van reguliere expressies. Zeker wanneer er voor meerdere doeleinden DomDocument wordt gebruikt, heeft dit de nodige impact op de laadtijd van een webpagina, doordat het een directe invloed kan hebben op de TTFB. De TTFB dient voor pagespeed namelijk zo beperkt mogelijk gehouden te worden.
DomDocument nadelen inperken
Hoe wij hier op inspringen, is door DomDocument met mate op specifieke plekken te gebruiken. Op de volgende manieren vindt de afweging plaats:
- bij html manipulaties in plaats van ontleding
Moet een stuk HTML ontleedt worden, om enkel een bepaalde attribuut-waarde, zoals een youtube-url uit een stuk HTML te filteren, of om een enkel HTML element te vervangen? Dan zullen we zeker wanneer de code intern opgebouwd wordt, reguliere expressies boven DomDocument verkiezen. In het ander geval kiezen we voor DomDocument; - op plekken waar foutgevoeligheid op de loer ligt
Moeten grotere stukken HTML gemanipuleerd worden, of is er kans op fouten bij gebruik van reguliere expressies? Dan kiezen we voor DomDocument. Wanneer code extern verkregen wordt en we bijvoorbeeld weinig invloed op die code hebben, is DomDocument ook de betere keuze; - resultaten cachen
Door de uitkomsten van DomDocument te cachen, wordt voorkomen dat applicatie gebruikers of website bezoekers 'hinder' ondervinden van het gebruik van DomDocument. Manipulatie voor DomDocument gebeurt dan niet herhaaldelijk bij elk pagina bezoek. Hiermee behalen we binnen het LightBolt CMS laadtijden van 0.0014 seconden
DomDocument toepassingen
Ter verduidelijking van wanneer DomDocument de betere oplossing is om HTML te ontdelen of manipuleren, hieronder enkele voorbeelden:
Accelerated Mobile Pages
Het LightBolt CMS ondersteunt Google's AMP framework, in tegenstelling tot bijvoorbeeld Wordpress, voor alle pagina's. Dit gaat echter niet vanzelf, doordat de HTML opzet van een AMP-website, anders is dan reguliere HTML. Om te voorkomen dat een website beheerder extra handelingen moet doen om een website AMP te laten ondersteunen, hebben we gebruik gemaakt van DomDocument voor HTML manipulatie. Denk aan het vervangen van afbeeldingen, video en audio-bestanden.
Jouw website nog niet AMP of ontbreekt het in een eigen CMS aan AMP ondersteuning? Neem gerust contact op om ons een AMP-schil te laten programmeren.
Afbeeldingen vervangen
We gebruiken DomDocument onder meer om afbeeldingen te vervangen. Niet alleen voor AMP doeleinden, maar ook voor lazy-load doeleinden. Op die manier hoeven frontend en backendprogrammeurs die met onze systemen werken, in de programmatuur geen rekening te houden met optimalisatie-technieken.
Anchors uitlezen
Voor een nieuwsbrief tool, wordt DomDocument ingezet om alle links uit een mailbericht te ontleden. Deze worden vervolgens vervangen door unieke links, waarmee gebruik vanuit een ontvangen nieuwsbrief meetbaar wordt. De oorspronkelijke links worden in de database opgeslagen, nadat DomDocument zijn werk heeft gedaan. Dit proces speelt zich in cronjobs af, waardoor pagespeed geen rol speelt.
Formulier verwerking
Het LightBolt CMS kent een formulierenmodule. De kunst bij de bouw van een goede formulierenmodule is dat ingevoerde data (ongeacht input, textarea, of select) intact blijft zodra een formulier verstuurd wordt, maar er ondertussen fouten zijn opgetreden. Het feit dat de door het CMS geproduceerde HTML code kan verschillen door gebruik van specifieke browsers, maakt dit uitdagender. Bovendien worden specifieke velden middels attributen voorzien van restricties. Denk aan required, accept, pattern.
Echter, deze attributen kunnen eenvoudig via browser-opties weggehaald worden, om deze formulier-beperkingen te omzeilen. Door gebruik te maken van DomDocument, kunnen deze controles nog eens op server side niveau (never trust user input!) toegepast worden, waarbij de opzet van een formulierenmodule dynamisch kan blijven.
DomDocument en pagespeed
Eigen kanttekeninen of nadelen van DomDocument ondervonden, met betrekking tot pagespeed? Of op zoek naar tips omtrent pagespeed en DomDocument? We horen het graag!
