Php7 en lazy image loader - Development-iteratie #92

Onze developers hebben de ontwikkeling van iteratie #92 voltooid. In deze iteratie hebben we gewerkt aan een lazy loader voor afbeeldingen en werden de laatste webservers overgezet naar php7.

Php7

In de afgelopen maanden hebben we gewerkt aan het geschikt maken van onze codebase voor de nieuwste versie van php. Een van de voornaamste verbeteringen in php7 is de nieuwe php-ng-engine, die een verdubbeling van de prestaties belooft. Inmiddels hebben alle servers een upgrade ondergaan naar php7. Het verschil in prestaties en het moment van upgraden zijn goed zichtbaar in de onderstaande grafiek van de gemiddelde applicatieresponstijd per server. De groene lijn is van een server die tijdens de meting een upgrade kreeg naar php7 en sindsdien een stuk beter presteert. Het verschil is niet helemaal een halvering in de responstijd, maar dat komt doordat de applicatieresponstijd inclusief het wachten op data uit caches en databases is weergegeven.

Lazy image loader

Om de laadtijden van pagina's te verbeteren en het dataverbruik terug te dringen, hebben we een implementatie gemaakt van een lazy image loader. Afbeeldingen in singlepage-reviews en forumtopics worden vanaf nu via de nieuwe image loader opgehaald. De lazy image loader zorgt ervoor dat afbeeldingen op deze pagina's pas worden geladen op het moment dat ze (bijna) in het zicht van de gebruiker komen. Nooit bekeken afbeeldingen worden niet opgehaald. Vooral in grote fototopics kan dit enorm schelen in datagebruik. Ook zijn afbeeldingen lager op de pagina sneller zichtbaar als je meteen na het openen van de pagina naar beneden scrollt, doordat de browser niet tegelijkertijd alle bovenliggende afbeeldingen zal willen laden. Een voorbeeld van een pagina waarop je de lazy image loader in werking kunt zien, is het topic over vliegtuigfotografie.

En verder hebben we…

• gewerkt aan een oplossing voor een correcte weergave van afbeeldingen die via exif-oriëntatie zijn gekanteld;
• aanpassingen gedaan om de code geschikt te maken voor Symfony 3;
• een bug opgelost die tot gevolg had dat code-highlighting niet werkte in tweakblogs.

Reacties (77)

[biglia]

Lazy loading in forumtopics is ideaal. Maar gaat het bij singlepage-reviews geen negatief effect op SEO veroorzaken?

[Olaf van der Spek]

Lazy loading in forumtopics is ideaal.

Is dit niet iets wat de browser, indien gewenst, ook gewoon zelf zou kunnen doen?

[xoniq]

Zou kunnen, echter gebeurt dit nog altijd niet. Het voordeel is dat als je heel snel scrolled je enkel in een fractie van een seconde witte vlakken ziet. En waar je stopt met scrollen, of langzaam scrolled, laden de foto's 'on demand' in. Normaal gesproken zat je redelijk lang te wachten tot je überhaupt kon scrollen (dus wachten tot de foto's volledig werden ingeladen.)

[matroosoft]

Nadeel is wel dat ik vaak een pagina laad als ik weet dat ik daarna even geen internet heb, zodat ik gewoon verder kan lezen. Dat gaat nu nog steeds, maar dan wel zonder afbeeldingen.

[Rannasha]

Mee eens. Ik reis dagelijks met de bus over de grens en heb een deel van de tijd geen mobiele data. Regelmatig open ik dan voordat ik begin met roamen een stuk om te lezen (bv een single page review). Met lazy loading verlies ik in zo'n geval de plaatjes, wat wel jammer zou zijn.

[Devian]

Ik gebruikte de singlepage-reviews juist omdat het eerste stuk van de trein een slechte dataverbinding heeft.

Op die manier werd het hele artikel binnen gehaald, en kon ik rustig in de trein lezen.

Nu gaat het dus gebeuren dat ik een artikel begin te lezen en ik de plaatjes niet ga zien vanwege de slechte dataverbinding...

[guanche]

Maar goed dat je deze .plan gelezen hebt dan! Nu weet je dat als je je cache wilt vullen eerst even moet scrollen en dan pas gaat lezen

[xDiglett]

Nee, Google kan Javascript al gewoon volgen:
https://webmasters.google...ing-web-pages-better.html

[crisp]

De plaatjes staan wel in de content in een <noscript> tag. Dus bots en non-js clients zullen de plaatjes ook gewoon 'zien'

[djwice]

TIP: idealiter is het vervangende pixel in de verhouding van het nog niet gegelade element, ik zie op mijn mobiel nog steeds verspingingen.

TIP 2
Klopt het dat soms ook quotes lazy geladen worden? Vond ik best onhandig..
Kun je voorkomen dat dit gebeurd met quotes waar plaatjes in zitten?

[crisp]

Ter aanvulling: normaliter worden plaatjes in quotes ook niet herhaald maar vervangen door een link

[djwice]

Ja, daarom verbaaste het mij dat de tekst in quotes later pas verschijnt.

[Reactie gewijzigd door djwice op 24 juli 2024 23:58]

[ACM]

Zie ook reacties van collega crisp elders op deze pagina, maar:

ad 1. De lazy-loading wordt alleen toegepast zodra in de html-broncode zowel de hoogte als breedte van de afbeelding bekend zijn. Kortom; het is dus per definitie precies de goede verhouding.
Echter zijn er ook afbeeldingen waarvan de hoogte niet bekend is, die worden niet via lazy-loading geladen, maar behouden hun oude gedrag.
Dat oude gedrag veroorzaakt helaas verspringingen omdat pas bij het downloaden bekend is hoe groot de afbeelding is...

ad 2. Het is voor de lazy-load code niet bekend of er een specifieke context is, zoals quotes. Dat zou het ook erg complex maken. Overigens worden die specifieke plaatjes natuurlijk wel heel snel geladen, want ze zitten al in je browser-cache als ze meerdere keren op een pagina voorkomen en je ze al eerder bent tegengekomen.

[Ircghost]

Topwerk mannen! Als mobiele gebruiker ben ik ook zeker te spreken over de potentiele databesparing door de lazy loader .

[Verwijderd]

Ik stel m'n vragen bij dit, want je zal een topic met meerdere pagina's bijv toch naar beneden willen scrollen, en trigger je automatisch het laden van images.

Tenzij je op de PC, direct op "End" drukt zodat je naar de laatste reactie gaat, dan skip je de rest.

[crisp]

Zolang je blijft scrollen worden er nog geen plaatjes geladen. Dat wordt pas gedaan als je even 'stilstaat'

[ATS]

Ik was even bang dat de content zou gaan verspringen, maar nee. Ik zie dat jullie een wit vlak met de juiste maat reserveren voor nog niet geladen afbeeldingen. Prima verbetering! Scheelt jullie vast ook in data gebruik.

[Reactie gewijzigd door ATS op 24 juli 2024 23:58]

[xoniq]

Of als je langzaam scrolled :-). Dan komen ze wel voorbij flitsen, maar als je op iOS bijvoorbeeld momentum scrolling doet (harder vegen is harder scrollen) dan blijven ze gewoon wit tot je langzaam scrolled of stopt.

[Nogne]

Je kan op je telefoon toch ook naar beneden gaan dmv de pijl. Blijft wel als je alle reacties afgaat (omdat je iets zoekt) dan trigger je het downloaden van de afbeeldingen wel want ze komen in beeld.

[xoniq]

Die pijl zit bij iOS heel naar gepositioneerd. Dan moet je eerst bij die pijl stukken, maar als je bij iOS onderin drukt, dan komt de UI van Safari tevoorschijn, waarna het pijltje verspringt, en dan pas kan je erop drukken. Als die pijl 40 pixels omhoog wordt geplaatst is het wat toegankelijker.

[Ircghost]

Ik gebruik op mijn mobiel ook de variant op home en end door de virtuele knop die verschijnt bij het scrollen.

[D-Three]

Ik vreesde een beetje dat de 'Lazy image loader' voor traag ladende afbeeldingen zou zorgen. Maar het lijkt prima te werken en is vriendelijk voor het mobiel datagebruik. Well done!

[Reactie gewijzigd door D-Three op 24 juli 2024 23:58]

[Room42]

Mwah, ik vind het wel degelijk te traag laden. Ik vind het idee wel leuk maar de uitvoering laat vaak te wensen over. De afbeelding wordt pas geladen als deze in beeld scrolt. Dat is te laat! Hij moet juist vlak voordat hij in beeld scrolt al geladen zijn.

[crisp]

Je wilt tijdens het scrollen zelf geen code uitvoeren om plaatsbepaling te doen omdat het scrollen zelf dan erg 'sluggish' gaat worden. Daarom wordt er pas op het moment dat je even 'stilstaat' gekeken welke plaatjes opgehaald moeten worden.

Vergeet niet dat zonder lazy loading je praktisch hetzelfde effect hebt als je naar het midden van een pagina scrolled als nog niet alle images zijn opgehaald. Je browser is dan nog druk bezig met het laden van eerdere plaatjes.

De lazy loader is wel zo slim om ook alvast plaatjes die 1 'scroll-lengte' verderop staan op te halen. In het scenario dat je dus rustig door een pagina scrolled en ook af en toe stilstaat om de content te bekijken zou je dus nauwelijks 'last' moeten hebben van het vertraagde laden

[Rafe]

Aanvullend: de term voor die traagheid is 'jank' en op http://jankfree.org/ staat een boel info om het te voorkomen. Niet alleen voor gamers is strakke 60fps belangrijk

Facebook heeft trouwens een mooie techniek bedacht voor achtergronden door eerst een miniversie van de afbeelding base64-encoded in de HTML zelf mee te sturen en deze blurred te tonen terwijl de grote versie wordt binnengehaald. Op https://css-tricks.com/th...oading-background-images/ wordt het uitgelegd.

[crisp]

We willen sowieso gaan kijken naar progressive jpegs voor onze eigen images (voor zover het jpegs zijn natuurlijk). De methode van Facebook is inderdaad erg fancy, maar dat heeft wel erg veel voeten in aarde om dat te realiseren (zeker ook voor externe images), en uiteindelijk ben ik bang dat de kosten bij ons niet opwegen tegen de baten - zeker niet gezien onze schaarse tijd...

[pekeltje]

En een oplossing als modpagespeed als reverse proxy dan?
Optimaliseert ook erg veel, en gaat automatisch.

[crisp]

Ik denk dat dat voor ons weinig toe zou voegen en misschien zelfs wel averechts zal werken op onze performance...

Performance moet 'built-in' zijn, niet 'add-on'

[Reactie gewijzigd door crisp op 24 juli 2024 23:58]

[xoniq]

Anderzijds, als jij dus een groot topic hebt, en je wilt alleen de laatste reactie lezen, dan wil je die plaatjes helemaal niet hebben. Kost data op mobiel, en globaal laadtijd van de pagina.
Nu krijg je ze weliswaar iets langzamer, maar die tijd had je anders gewacht tot de pagina zelf was geladen. Dus qua laadtijd maakt het geen ruk uit, wel qua data verbruik.

[DavidAxe]

Wel een kleine opmerking over de lazy image loader:
Kunnen jullie de plaatjes alvast de juiste ruimte in laten nemen? Indien ik nu tot halverwege de voorbeeld pagina scroll en dan naar boven, dan verspringt de content eronder omdat de afbeelding die geladen wordt, meer (of minder?) plek inneemt dan gereserveerd was.
Wordt de afbeelding size wel correct doorgegeven aan de loader of placeholder?

Kleine aanvulling: dit gebeurt op Android/Chrome, niet op m'n desktop.

[Reactie gewijzigd door DavidAxe op 24 juli 2024 23:58]

[crisp]

Alleen plaatjes waarvan de afmetingen al vast staan (kunnen) worden gelazy-load. Het komt wel eens voor dat er ook plaatjes in de content staan zonder afmetingen of alleen met een bepaalde breedte. Deze worden niet gelazy-load, maar vertonen inderdaad wel het gedrag dat je beschrijft.

Er is al een ticket om dat soort gevallen te verminderen c.q. voorkomen. Niet alleen om het verspringen van de content te voorkomen, maar juist ook zodat we deze plaatjes dan ook kunnen 'lazy-loaden'

[DavidAxe]

Begon me ook af te vragen of het een probleem is van Android/Chrome. Op de PC (ook met Chrome) werkt het prima! Kan het niet zo zijn dat Chrome op mobiel minder ruimte reserveert dan is aangegeven? Om te grote lege vlakken te voorkomen.
Op mijn mobiel heb ik met nu.nl ook altijd een vergelijkbaar probleem. Bijvoorbeeld als ik vrij snel na het laden van de hoofdpagina op een link wil klikken, verspringt de content ineens waardoor ik op de verkeerde link klik

[crisp]

nu.nl springt altijd de eerste paar minuten alle kanten op door alle reclame die geladen wordt...

[Abbu-kun]

Je zou bijna een adblocker gaan gebruiken. Behalve dat ik die net aanzette op de mobiele site van nu.nl en het nog steeds rondsprong, cookiemelding dit, Android app zo etc.

Waarom zou ik geloven dat de app uberhaupt bruikbaar is als de site zo incompetent is dat een basis functie van het www l i n k e n iets onmogelijks is geworden?

[TimmiX]

Mooie update! Lekkere vooruitgangen blijven jullie boeken.

Wel een klein bugje. Reacties op artikelen (oa. bij dit artikel) vallen iets over de sidebar heen. Dit lijkt nu gefixed. Was wellicht cache bij mij..

Kunnen jullie trouwens aangeven wat jullie beleid is wat betreft de suggesties in het forum 'mooie features'? Ik heb hier meer dan een jaar geleden al eens een suggestie geplaatst maar er is nooit op gereageerd. Wordt hier wel naar gekeken? Lijkt mij handig om dan even een reactie te plaatsen, ook als jullie er niets in zien. Dan kan het topic iig als 'behandeld' worden beschouwd en kan deze worden gesloten.

[Reactie gewijzigd door TimmiX op 24 juli 2024 23:58]

[Femme]

Op dit moment hebben we helaas niet de capaciteit om feature requests op het forum op een goede manier te verwerken. We vinden dit zelf ook een doorn in het oog en gaan proberen om een oplossing te bedenken die voor iedereen beter werkt. Reageren in topics is één ding, het aanmaken van tickets, bedenken van oplossingen (voor zover nodig), inplannen, bouwen en testen van nieuwe features kost veel tijd

[ATS]

Waarom zetten jullie niet gewoon je/de Jira open voor suggesties?

(Of welke issue tracker jullie dan ook gebruiken...)

[crisp]

Onze backlog in Jira is ook al enorm groot We willen dus juist wel een vorm van filtering hebben voordat er ueberhaupt een ticket aangemaakt wordt. Verder moet een ticket ook aan bepaalde eisen voldoen, dus dat doen we toch liever zelf

[BLACKfm]

Met andere woorden; Er zijn nog wat vacatures beschikbaar?

[webkiller71]

Met andere woorden; Er zijn nog wat vacatures beschikbaar?

Er is vast behoefte aan meer developers, maar dat wil niet zeggen dat daar budget voor is.

[BLACKfm]

Leuk als stageplek of desnoods vrijwillige basis (al verwacht ik niet dat er (goede) developers) in de WW of Steun zitten).

Je moet als betaald medium niet schromen om ook 'gratis' personeel aan te nemen.
Wie weet wat er nog van kan komen.

[webkiller71]

Eens, maar het kan lastig zijn om iemand in een team op te nemen. Daar zitten vaak nog verborgen kosten voor een bedrijf. Binnen open source kan dit makkelijker omdat je dan de code gewoon online kan hebben en mensen kunnen one-off fixes submitten. Met een gesloten code base, zoals de meeste bedrijven dat hebben, gaat dat veel lastiger.

[Rafe]

Zijn er nog andere interessante verbeteringen te merken met PHP7? Bijv. lager cpu/geheugengebruik?

[Femme]

Even snel bij Kees gecheckt: het geheugengebruik van php is met zo'n 15 procent gedaald en het cpu-gebruik van php is grofweg van 80 naar 50 procent gegaan (de webservers hebben 16 cores dus max 1600 procent cpu-belasting).

[Jan-E]

Kan goed kloppen, want de PHP devs hebben bij het ontwikkelen van de nieuwe Zend engine tot op de byte bekeken hoe het geheugengebruik verminderd kon worden. Een deel van de snelheidswinst is daar ook uit te verklaren.

[hackerhater]

Hmm interessante statistieken voor mijn eigen werk.
De huidige server kraakt onder de CPU belasting

[webkiller71]

We zien bij onze hostingklanten dat het heel veel scheelt. Er zijn nog klanten die wordpress op PHP 5.3 draaien en upgraden naar PHP 7 is een gigantische performance boost die praktisch gratis is als ze een beetje geupdate hebben.

[ge-flopt]

Ik zie dat de tweakblog ook een update(je) heeft gehad. Mag ik vragen of daar nog veel aan ontwikkeld wordt? Ik zie namelijk weinig daarover vermeld worden tijdens de itteraties blogjes.

[Femme]

Tweakblogs behoort wat ons betreft niet tot de hoofdbestemmingen van de site (zoals nieuws, reviews, Pricewatch en het forum). We doen het hoognodige onderhoud van Tweakblogs maar verder wordt er niet actief aan ontwikkeld. We hebben de beschikbare capaciteit nodig om onze corefunctionaliteit op niveau te houden.

[ge-flopt]

THX. Zoiets had ik al wel het idee.

[defixje]

Mooie iteratie weer.

Alleen 1 opmerking bij de lazy-loader, ik merk dat deze pas echt gaat laden als de tag van het plaatje in je scherm scrolled.

Kan het niet zo gemaakt worden dat het al laad als het nog net een paar regels onder de view-line zit? Zodat je, bij een iets tragere verbinding, niet hoeft te wachten tot je het plaatje ziet omdat het net iets te laat laad?

[crisp]

Dat gebeurt al, nadat de direct zichtbare plaatjes zijn ingeladen worden de plaatjes die 1 scroll-lengte terug of verder staan ook alvast ingeladen. Je scrolled dus waarschijnlijk te snel verder

[defixje]

Nou gister zat ik op een trage verbinding, en soms wachtte ik even en alsnog pas als het de img-tag in het midden van mijn scherm stond werd het plaatje pas geladen.

Vandaar mijn vraag eigenlijk, maar zie nu dat dat inderdaad al wordt gedaan.

[_David_]

Afbeeldingen in singlepage-reviews en forumtopics worden vanaf nu via de nieuwe image loader opgehaald.

Zo te zien werkt dit nog niet bij User reviews? Want daar is het namelijk hard nodig...

Alle respect voor mensen die heel veel tijd en moeite steken in hun review, maar de belachelijk hoeveelheid images die er tegenwoordig ingedrukt worden weerhoud mij ervan om user reviews te openen op een mobiele verbinding.

[Reactie gewijzigd door _David_ op 24 juli 2024 23:58]

[crisp]

Voor gebruikersreviews willen we het zeker ook gaan implementeren. We constateerden echter dat doordat er daar nog geen mechanisme is om afmetingen bij plaatjes automatisch in te vullen het nu nog minder effectief zou zijn (de imageloader vereist dat hoogte en breedte bekend zijn). Daar is dus nog wat extra werk voor nodig