Symfony 3- en Pricewatch-verbeteringen - Development-iteratie #91

Zojuist heeft het developmentteam iteratie #91 afgerond. In deze sprint hebben we ons gericht op de overgang naar Symfony 3 en diverse kleine verbeteringen in de Pricewatch.

Snelste dalingen in de Pricewatch

Een aantal maanden geleden introduceerden we ‘de snelste Pricewatch-dalers’. Naast veel positieve reacties, kregen we ook interessante feedback over hoe we de dalers nog relevanter konden maken. We laten nu steeds verschillende Prijsdalers zien op de Pricewatch-portal. Daarnaast laten we nu, met dank aan gebruikersreacties op een vorige .plan, dalingen bij hooggeprijsde producten wat zwaarder meewegen, waardoor grote verschillen in euro’s sneller zichtbaar worden, ook al is de procentuele daling misschien niet het sterkst. Als er een groot voordeel te behalen valt in euro’s, zul je deze dalers nu eerder zien.

Shopreviews

Om de betrouwbaarheid van de shopreviews op tweakers te waarborgen, worden deze goed gemonitord. Ook bekijken we regelmatig hoe we de shopreviewervaring verder kunnen verbeteren. In deze iteratie hebben we een aanpassing doorgevoerd in de voorwaarden die te vinden zijn bij het schrijven van de shopreview. We zien de shopreviews niet langer als een algemene winkelbeoordeling, maar het gaat erom dat je ervaring met een webwinkel een afgeronde aankoop betreft. Zo maken we het nu mogelijk om ook twee aankopen die binnen korte tijd na elkaar zijn gedaan los te beoordelen, want de ene aankoop is de andere niet.

Symfony 3

Ondertussen zijn we al enkele sprints bezig met de voorbereiding van een Symfony 3-upgrade. We hebben daarom in de afgelopen sprint opnieuw tientallen formulieren omgezet naar de stijl die sinds deze derde versie noodzakelijk is. Gelukkig is het bijna klaar en moeten we die upgrade, na een uitgebreide test, in een van de komende sprints daadwerkelijk kunnen uitvoeren.

En verder:

• hebben we research gedaan naar lazy loading van afbeeldingen;
• hebben we het weergeven van V&A-ratings op mobiel verbeterd.

Reacties (110)

[Mont2uk]

Mooie ontwikkeling wat betreft de Shopreviews, eerlijk voor de klant en voor de winkel imho.
Lazy loading moet ik daarbij denken aan een soort loadbalancing voor afbeeldingen?

[Inspector]

Nee. Het is een techniek waarbij wordt gekeken of een afbeelding binnen de viewport van de gebruiker ligt. Zodra deze daadwerkelijk op zijn scherm zichtbaar is word pas de afbeelding opgehaald. Zo wordt niet alles in een keer geladen wat de initiële pageload ten goede komt en er voor zorgt dat assets die nooit "bekeken" worden ook niet onnodig worden ingeladen.

[SwiftPengu]

Hoe lossen jullie het potentiële probleem op dat grote assets eerst een tijdje een wit vak zijn, in plaats van dat een gebruiker er direct mee aan de slag zou kunnen?

Of gebruiken jullie een asynchrone queue die na de initiële pageload de rest binnenhaalt?

[AddictIT]

Ik weet niet exact hoe Tweakers dit opneemt, maar je kan meerdere technieken combineren:

• In eerste instantie maak je gebruik van Lazy Image Loading, of zelfs in het algemeen lazy resource loading. Stel dat je meerdere javascript-bestanden moet inladen, maar je hebt ze niet allemaal nodig in het begin, is het beter om dat zo lang mogelijk uit te stellen. Zoals iemand anders verder al aangaf, kan je al beginnen met alle niet-kritische bestanden en stylesheets vlak voor de </body>-tag te plaatsen.
• Een andere techniek die je kan gebruiken heet "Progressive Image Loading". Wat er op dat moment gebeurt, is dat je eerst lage-resolutie beelden gaat downloaden, die progressief beter worden van kwaliteit. Zo krijgt de eindgebruiker al direct een idee wat de inhoud van het plaatje is, en wordt als het ware de indruk gewekt dat de gebruiker alvast aan de slag kan.
• Minification van alle tekstbestanden (waar minification op kan toegepast worden), zorgt er voor dat je minder bytes over de lijn moet gooien, dus een pagina zal sneller laden.

Een combinatie van bovenstaande technieken zorgt voor een optimale gebruikerservaring.

[Sando]

Minification van alle tekstbestanden (waar minification op kan toegepast worden), zorgt er voor dat je minder bytes over de lijn moet gooien, dus een pagina zal sneller laden.

Is dat nog relevant? Volgens mij doet elke browser die überhaupt compatible is met Tweakers wel een request header sturen als ACCEPT_ENCODING: gzip, deflate

Dus gewoon Content-encoding: GZIP ipv minification?

[Rafe]

Compressie zorgt voor de grootste winst qua filesize, maar je kan beide toepassen door eerst te minifyen en daarna dat te gzippen voor maximale winst. Moderne web frameworks hebben daar een asset pipeline voor, Symfony gebruikt vziw Assetic.

[Reactie gewijzigd door Rafe op 24 juli 2024 12:07]

[Cartman!]

Assetic is niet perse standaard aanwezig maar wel relatief simpel te gebruiken met Symfony.

[Verwijderd]

Wat kleine aanvullingen...

Je eerste punt is deels waar. Browsers hebben echter ook een look ahead parser:

http://andydavies.me/blog...-makes-pages-load-faster/

Voordat een pagina echt grondig parsed wordt, kijkt dit aparte proces alvast vooruit naar resources (img, css, js) en begint in veel gevallen alvast het downloaden daarvan. Vaak zal dat wel in volgorde van markup gebeuren, maar dat is geen garantie meer. Browser bouwen op basis van intelligentie een eigen priority tree en die kan wel degelijk anders zijn dan de volgorde in markup.

Het is daarom niet fout om niet-essentiele JS laag in de markup te zetten, dat blijft een goed advies. Het is echter geen garantie dat de uitvoering op die manier plaatsvind.

Verder omtrent progressive image loading kan dit in veel gevallen ook op basis van een enkel progressive JPEG image die meerdere scans heeft. Een grappig techniek aangezien die ontworpen is voor de traagheid van dialup in de 90s, en nu weer relevant is.

[crisp]

Onze 'proof of concept' heeft wel al wat slimmigheidjes, zoals na het checken van direct zichtbare afbeeldingen alvast plaatjes die 1 pagina-scrollengte verder staan ook na een kleine delay alvast ophalen. Daarnaast willen we voor 'grote' resources zoals iframes (bijvoorbeeld een videoplayer) ook een throbber tonen zolang deze nog niet geladen is. Voor jpegs willen we in de toekomst ook naar progressive rendering gaan kijken

[ruben06]

Lekkere feature! Is dit eigen code of een tooltje dat jullie ergens gevonden hebben?

Om even voor te gaan over de initiële pageload: hebben jullie ook al eens geprobeerd om het merendeel van de stylesheets en de scripts in te laden juist voor het einde van de body-tag? Dit kan ook nog wel wat schelen in de snelheid van de pageload. Ik heb hier namelijk geleerd om enkel de meest belangrijke stylesheet in de head-tag te plaatsen en al de rest juist boven de closing body-tag

[crisp]

Dan krijg je een zogenaamde 'flash of unstyled/unbehaved content' wat ook weer onwenselijk is. En bij stylesheets krijg je dan ook nog een vrij heftige reflow. Sommige scripts laden we echter wel asynchroon of on-demand in. Onze standaard JS toolkit is gelukkig wel behoorlijk klein

[ruben06]

Naar mijn ervaring valt die flash behoorlijk goed mee. Dan moet de internetverbinding al van slechte kwaliteit zijn om dit te verkrijgen.

Ik minimaliseer dan natuurlijk wel alles, zowel alle stylesheets als alle scripts plus caching kan ook wel wat doen uiteraard

[Amdk6II]

Als er iets is waar ik mij aan irriteer is het een pagina die vrijwel ingeladen is en net op het moment dat ik iets aantik verschuift de pagina en layout een stukje. want hij was nog bezig met opbouwen. Natuurlijk klik ik dan net mis en moet ik nogmaals klikken of klik ik per ongeluk een link aan ofzo. In mijn optiek is het beter om dat laatste restje performance te laten liggen ten behoeve van een betere gebruikservaring (let wel mijn mening).

Nu weet ik niets van lazy loading, dus ben wel benieuwd hoe dat in de praktijk aanvoelt.

[RadioKies]

Ik deel je mening, bij Youtube is dit ook zeer ergerlijk. Je klikt bijvoorbeeld op een kanaal, die laat de "homepage" zien van de gebruiker. Ik wil op het tabje video's klikken, maar als ik klik dan heb ik vaak genoeg dat hij net klaar is met inladen van een laatste iets en het menu iets verplaatst, waardoor ik niet op video maar op iets anders (een link) klik.

Dat lazy loading zou wel leuk uit kunnen pakken in sommige topics waar bijvoorbeeld veel plaatjes staan zoals HGGPT, HGAGT en IDDQD

[Cosimo]

Heel goed punt. Dit is bij heel veel websites een probleem tegenwoordig.

[crisp]

Maar ook daar (trage verbindingen) moet je rekening mee houden. Aan de andere kant worden pagina's zelf al groter en zwaarder en duren daarmee langer om te renderen. Het hele idee om een proof of concept te doen met lazy loading images is gekomen vanuit het feit dat sommige pagina's gewoonweg te log en zwaar worden om in 1 keer soepel in te laden (met name op mobiele devices).

Zaken als minificatie, http-compressie en aggressief cachen doen we uiteraard al jaren

[Verwijderd]

Je kunt het ongewenst verklaren, maar steeds meer wordt de "flash of unstyled content" juist aangeraden, daarmee bedoelende dat het alsnog beter is dan een gebruiker die naar een wit scherm staart.

In het geval van Tweakers gaat die vlieger denk ik niet op, omdat de site al behoorlijk snel is, maar ook omdat je het gelukt hebt dat het merendeel van je publiek geografisch extreem dichtbij is, en ook nog eens in een regio met top snelheden.

De reflow is browser afhankelijk en kun je niet als feit stellen. In sommige browsers is CSS render blocking, in andere weer niet.

[Rafe]

Voor lazy loading bestaan al veel libraries als je het wiel niet opnieuw wil uitvinden. Het is een bekende techniek.

Die optimalisaties die je noemt zijn best tricky. JS aan het einde van je HTML blokkeert nog steeds rendering zonder een aync attribuut bijvoorbeeld.

[Reactie gewijzigd door Rafe op 24 juli 2024 12:07]

[ruben06]

Hier geeft google toch wel tegenstrijdige uitleg dan. Als je een webpagina door de pagespeed insights tool haalt, raadt Google hier altijd aan alles 'onder de vouw' te plaatsen...

Het is natuurlijk ook te zien welke functies er allemaal in javascript uitgevoerd worden bij rendering

[Rafe]

Pagespeed Insights is geloof ik wat verouderd aan het raken. Meeste footers geven als laatste bijwerkdatum 2014 of begin 2015. Er wordt bijvoorbeeld nog gejubeld over spdy zonder een woord over HTTP/2 te reppen

[Reactie gewijzigd door Rafe op 24 juli 2024 12:07]

[ruben06]

Ik loop precies wat achter

Wat er al niet verandert op het jaar dat ik geen websites meer ontwikkel maar enkel een interne web app

[Verwijderd]

Het klopt dat het advies outdated is, het werkelijke advies zou moeten zijn om alles zoveel mogelijk async te laden.

[Mont2uk]

Bedankt voor de opheldering (ook alle replyers hieronder).

Slimme oplossing, zal veel bandwith kunnen schelen waarschijnlijk.
Dit werkt ook goed voor mobiele devices?

[NLAnaconda]

En wat is het resultaat/conclusie van deze research? Of is jullie research facility een soort Area 51

[stefanhendriks]

enig nadeel is dat je mogelijk het 'laden' dan ziet. Dat zou je evt kunnen oplossen door images te laden als ze 'bijna' in viewport zitten

[Nindustries]

Lazy Load delays loading of images in long web pages. Images outside of viewport are not loaded until user scrolls to them. This is the opposite of image preloading.

[TimmiX]

Afbeelding pas inladen op het moment dat deze 'in beeld' zijn in plaats van alle afbeeldingen initieel al in te laden. Scheelt bij lange pagina's met veel afbeeldingen laadtijd.

[L00_Cyph3r]

Lazyloading houdt in dat er elementen (voornamelijk afbeeldingen) later via bijv. JavaScript worden ingeladen.
Dit zorgt ervoor dat de belangrijkste content (text Enzo) sneller zichtbaar is, en dat de afbeeldingen op de achtergrond worden opgehaald.

[BobV]

Lazy loading houdt in dat de betreffende afbeeldingen niet direct in het object worden gezet zodra de data uit de database komt. Je hebt dus je object met weliswaar de referentie naar de afbeelding (meestal een path), maar er zit nog geen image object in. Dit scheelt memory als je de afbeelding van plan bent om te gebruiken op dat moment. Dit kan bijvoorbeeld handig zijn bij het opstellen van lijsten, waarbij de afbeelding van de onderste niet nodig is.

EDIT: Blijkbaar is het hier lazy loading vanuit de gebruikers kant: ik had het gekoppeld aan de SF3 kant.

[Reactie gewijzigd door BobV op 24 juli 2024 12:07]

[friggler]

Ik heb er al een keer een topic over geopend, maar heb toen helaas geen enkele reactie gehad van iemand. Mij zou het een mooie oplossing lijken als je bij het lezen van shopreviews kunt kiezen voor alleen shopreviews van mensen die al x jaar actief zijn hier (of xxx karma hebben), zodat je de meeste neppe reviews gemaakt door mensen die zich alleen maar aanmelden hier om de review te maken er daardoor automatisch uit kunt filteren. Ik zie dan ook een slider voor me met verschillende opties waar je zelf die keuze kunt maken.

[ruben06]

Wat zou ik graag de source code van de gebruikte symfony 3 code willen zien! Ik ben mezelf hierin aan het bijscholen, en het lijkt me leuk om een voorbeeld zoals de website van Tweakers te kunnen bekijken/gebruiken

Zijn er prestatieverschillen te merken tussen symfony 2 en symfony 3?

[Inspector]

We kunnen natuurlijk lang niet alles laten zien maar als je in de buurt woont en interesse hebt mag je best eens langskomen voor een kop koffie waarna we je wel e.e.a. kunnen laten zien. De prestatie verschillen van Symfony2 naar 3 zijn voor zover ik weet verwaarloosbaar. Het verschil van onze upgrade naar PHP7 overigens des te meer! Hier komen we ook zeker nog eens op terug.

[ruben06]

Dank je voor de uitnodiging Tweakers

Het is enkel een anderhalf uurtje rijden geloof ik maar moest ik ooit eens een tripje Amsterdam boeken, dan is een uitstap naar Tweakers het eerste wat op de planning staat!

Ikzelf ben in symfony 3 gevlogen omwille van de nieuwste features die het biedt, niet de LTS die je wel hebt bij 2.8. Vind het tot nu toe echt een prachtig framework en ik heb er waarschijnlijk nog maar enkele procenten van benuttigd

Edit: weekendje Amsterdam wordt tripje Amsterdam

[Reactie gewijzigd door ruben06 op 24 juli 2024 12:07]

[s.stok]

Als je vandaag de dag zou moeten kiezen, kan je beter kijken naar 3.x. Er zijn van nieuwe features en verbeteringen. 2.8 is LTS omdat er veel software is die hier nog op draait en afhankelijk is van bug fixes en security patches, je kan die moeilijk dwingen om nu direct over te stappen op naar 3.x. Maar qua stabiliteit zijn 2.8 en 3.x vrijwel gelijk.

Zie ook: https://symfony.com/doc/c...g/community/releases.html
Uiteindelijk zal voor 3.x ook een LTS komen, wanneer 4.0 het levenslicht ziet.

[Zayl]

Of LTS een goed concept is voor frameworks is, valt nog te betwijfelen. Voor end-products is het zeker een goed concept, maar niet voor code waar je dependencies op hebt.

[HashIT]

Misschien is het voor frameworks en libraries nog wel belangrijker dan voor eindproducten. Je wil namelijk als ontwikkelaar een bepaalde mate van zekerheid hebben dat de frameworks waar jij jouw product op baseert, op zijn minst net zo lang ondersteund wordt als jouw eindproduct ondersteund moet worden.

[Zayl]

Behalve dat er constant nieuwe features worden uitgebracht. Vaak kan je die features toch goed gebruiken.

Een upgrade van een minor: nieuwe features en mogelijk deprecations.
Een upgrade van een major: geen nieuwe features en backwards compatibility layer wordt verwijderd.

Met de huidige release cycle wordt er elke 6 maanden een minor uitgegeven tot aan 3.4. Deze zal qua feature set hetzelfde zijn als 4.0 minus de BC laag. Dat betekend als je op LTS blijft hangen, de drempel om te upgraden steeds hoger wordt: Je hebt meer deprecations te fixen in minder tijd, er zijn een hoop nieuwe features bij gekomen, wat je misschien al had kunnen gebruiken en toch maar zelf wat in elkaar geklust . Je gaat dus steeds meer af op een big bang release.

Naast het feit dat ik hoop dat Symfony het LTS concept gewoon helemaal dropt natuurlijk! Momenteel moeten er sommige bugs in 2.7, 2.8, 3.0, 3.1 en de master worden gepatched. Gelukkig gaat dat met het omhoog mergen vrij goed, maar geeft wel aan hoe veel versies er maintained moeten worden. Straks komen 3.4 en 4.0 uit, dan moeten 2.7, 2.8, 3.1, 3.2, 3.3, 3.4 en 4.0 onderhouden worden... Dat zijn 7!!! versies! Bron: http://symfony.com/doc/cu...ases.html#version-history

Okay sommige security only, maar geeft wel aan wat het probleem van LTS is. Het geeft eigenlijk geen echte voordelen voor de meeste projecten.

Voor Frameworks en Libraries is goede support belangerijk, maar niet in de vorm van LTS. Deze blog post geeft aan waarom het voor Symfony eigenlijk ook geen goed idee is: https://stovepipe.systems...sioning-and-compatibility

[s.stok]

Heel goed punt, bedankt voor de link (ga ik is even lezen) een LTS onderhouden vergt inderdaad veel werk (en discipline). Ik zou mezelf bij wijze van spreken nog liever letterlijk de voet schieten, dan zo'n monster van een planning te moeten onderhouden gelukkig kan Symfony dit hebben, omdat de releases door één persoon worden gedaan en alle andere ontwikkeling met name door een groot team en vrijwilligers word gedaan.

Een ander punt is de ondersteuning voor andere bundles, Symfony kan wel LTS aanbieden maar als de bundle ontwikkelaar weigert om nog langer ondersteuning te bieden voor oudere versies, dan hang je alsnog

En dan eindigt de LTS nog niet eens volledig, bedrijven die echt niet willen/kunnen upgraden kunnen altijd nog extended support aanvragen maar geld uiteraard niet voor andere bundles.

[Zayl]

maar geld uiteraard niet voor andere bundles

Dit is idd nog een reden dat LTS niet altijd werkt. Als het kan, support ik graag alle onderhouden versies van Symfony in mijn open-source pakketjes. Echter drop ik support mocht ik nieuwe features nodig hebben. Dit kan zeer nadelig zijn voor een hoop projecten die wel de LTS releases volgen. Vaak kan je wel een BC laag bouwen maar je hebt liever gewoon developers die updaten.

[koku]

Hier kiezen we niet specifiek voor LTS releases. We ontwikkelen continu aan de site en voordat de ondersteuning verloopt zitten we alweer op de volgende versie. Als je wacht met upgraden totdat de support op de LTS-release verloopt, dan moet je in een keer een hele hoop code refactoren om compatible te zijn met de nieuwe versie (als je pech hebt ). We proberen gewoon te upgraden naar de nieuwste versie, zodat de wijzigingen klein blijven. Helaas was het bij de upgrade naar Symfony 3 wat meer werk dan gehoopt, vanwege de manier van formulieren opbouwen die wij gebruikte vanaf het moment dat we Symfony gingen gebruiken. In dat geval reserveren we wat extra tijd om de upgrade te kunnen doen. Want uiteindelijk moet je toch een keer over

[plofkip]

De kans is denk ik dik aanwezig dat de devs van tweakers in het weekend ook daadwerkelijk weekend hebben ;-)

[AW_Bos]

Is het misschien een idee om er ook eens een keer een review aan te wijden? En dan vooral de gebruiktte bundles en de opzet van de site op de Symfony-core?

Gezien Symfony zeer polulair is, denk ik dat veel mensen er baat bij kunnen hebben.

[Inspector]

Leuk idee! Zal het eens polsen hier. Mocht je suggesties hebben van een onderdeel dat je concreet zou willen zien, let us know. We gebruiken lang niet alles van Symfony maar wel veel. Ik weet niet of we er echt een review mee kunnen vullen maar een artikeltje zou wellicht ook al leuk zijn

[Antrax]

Ik wil gewoon een dagje mee devven op HQ

[CH4OS]

Dat zal lastig worden; als zoiets al kan, is het praktisch vrij nutteloos. De codebase van Tweakers (ook al wordt er Symfony gebruikt) is anders dan die van een willekeurige andere site die ook draait op dezelfde versie van Symfony. Eer je echt iets kan gaan bijdragen in code, ben je een paar maanden verder. Dat heb ik althans bij mijn werk, waar we werken met Zend Framework.

[stefanhendriks]

Als het maanden duurt om productief te zijn in een codebase is er ook wel iets mis met de codebase?

Of bedoel je dat de tooling/frameworks ook een leercurve hebben?

Neem aan dat iemand die de frameworks beheerst er snel productief in kan zijn? (dagen ipv weken?)

[CH4OS]

Als het maanden duurt om productief te zijn in een codebase is er ook wel iets mis met de codebase?

Nee, de codebase is dan gewoon dusdanig groot, dat het echt zo lang duurt eer je het systeem enigszins kent. Wil je het systeem van voor te achter kennen, dan ben je gewoon jaren zoet, of je moet het zelf van begin tot eind opgebouwd hebben.

Zo ben ik zelf sinds mei aan het werk als webdeveloper en na ongeveer een maand of 1,5 kwam ik langzaam pas 'los' voordat ik langzaamaan dingen zelf kon oppakken en oplossen.

Neem aan dat iemand die de frameworks beheerst er snel productief in kan zijn? (dagen ipv weken?)

Dat verschilt natuurlijk per applicatie / omgeving.

[Reactie gewijzigd door CH4OS op 24 juli 2024 12:07]

[koku]

Dit is inderdaad wel een beetje hoe het werkt in de praktijk Uiteraard zijn en soms hele kleine losstaande dingetjes die je kan fixen, maar over het algemeen heb je de eerste paar maanden toch regelmatig wat hulp nodig.

[stefanhendriks]

solliciteer? ;-) misschien mag je dan wel 'elke dag' mee devven

[Verwijderd]

Hij heeft er volgens mij gewerkt vroegah

[Antrax]

Nee, helaas kan ik dat niet zeggen. Lijkt mij wel leuk om daar te werken maar helaas vis ik constant achter het net qua development vacatures.

[stefanhendriks]

Jammer! Maar wel tof dat je het probeert. Wie weet schiet je een keer raak!

[Zayl]

Ik persoonlijk ben wel geïnteresseerd in de controllers en template opzet. Heel veel herhalende stukjes (denk aan menu en footer) worden op elke pagina getoond. Om dit weer te geven doe ik sub-requests (ivm esi mogelijkheiden mochten we dit gebruiken), maar ben eigenlijk wel benieuwd hoe jullie dit afhandelen.

Hetzelfde geldt eigenlijk voor formulieren, gebruiken jullie het thin controllers concept of zijn controllers vrij groot? Hebben jullie bv gekeken naar form handlers of gebruiken jullie een command-bus principe?

ORM/DBAL is ook een laag apart waar een hoop over te vertellen valt

[stefanhendriks]

Geen idee hoe het met symfony werkt enzo. (Of uberhaupt php). Maar herbruik van templates lijkt me, view models, command pattern wellicht. Dunne controllers met services. Zoiets zou ik verwachten

[Zayl]

Je zal je verbazen hoe veel websites er op Symfony draaien en hoe weinig de juiste patterns implementeren ^^

[mrfu]

Routing, load balancing (want wij hebben nog moeite met http/2) en misschien search (gebruiken jullie al Elastic ?) Dat zouden wel leuke onderdelen zijn voor een highlight.

[goodfella]

Het doet mij deugd dat Tweakers nog steeds hobbyisten in dienst heeft die hun passie graag delen.

In 1998 werd ik lid maar helaas moest een herinschrijving plaatsvinden in 2001 (database reset? weet het niet meer zo goed). Anyway, tot op de dag van vandaag is het mijn meestbezochte site voor nieuwtjes, weetjes, pricewatch enz. Maar gelukkig ook voor het hobby-achtige voor mensen zoals Ruben06. Chapeau.

[AW_Bos]

Big Crash 3 in 2001. Waardoor maanden aan data verloren was door een gecrashte schijf. De RAID-setup was ook twijfelachtig te noemen, herinner ik mij nog.

[Rvanlaak]

Zo'n kop koffie lijkt me ook uiterst interessant. Zit nu met hetzelfde probleem, ben vooral heel benieuwd naar hoe jullie het aangepakt hebben met eventuele bundles waarvan de compatibility op zich laat wachten.

[Inspector]

Vanwege de hoge interesse zal ik kijken of we dit eens kunnen behandelen in een achtergrond artikel of andere vorm. Thnx voor de input.

[menzo.io]

Ik ben wel benieuwd of jullie Tweakers als een monolith hebben opgezet, of meer in aparte services. Is er misschien een thread met meer info hier over?

[Ruubster]

Eerlijk gezegd denk ik dat hier misschien wel meer interesse voor is. Het is misschien lastig om dit als een soort presentatie of kennissessie te doen, want de een heeft andere interesses (misschien ook meer ervaring), maar ik zou dit ook erg interessant vinden.

Ik ben zelf vanuit hobby begonnen en werk nu sinds 2 jaar als web developer bij een bedrijf (heb eigenlijk laboratorium-opleiding gehad). Veel bijgeschoold en nu vind ik het cool dat ik werk voor klanten die vrijwel iedereen wel kent. Vanuit mijn werk gebruiken we geen Symfony, maar CodeIgniter (pfff mag van mij wel veranderen), zelf gebruik ik Laravel en Laravel gebruikt Symfony-dingen. Ik ben om me heen aan het kijken qua baan, dus wie weet moet ik er ooit mee werken!

Maar goed, misschien spreek ik alleen voor mijzelf als nerd die deze shit interessant vindt

[Zayl]

Hangt er van af, hier heb je wat meer informatie over hoe de releases werken: https://stovepipe.systems...sioning-and-compatibility

Mocht je vragen hebben, join gerust op IRC (Freenode#symfony), ik ben daar te vinden met mijn echte naam: Iltar. #symfony-off is trouwens ook leuk voor andere dev related discussions!

[Yamotek]

De pricewatch is inderdaad heel handig! Toch zou ik zelf heel graag nog een functie zien die je bepaalde winkels laat verbergen (als je ingelogd bent). Immers als je niet bij die winkel wilt bestellen om wat voor persoonlijke reden dan ook, zou het fijn zijn om deze prijzen tijdens de overzichten niet te zien.

Bij sommige producten wordt de prijs door bepaalde winkels incorrect weergeven waardoor vergelijken lastiger is. Het zou handiger zijn om dan een winkel te kunnen verbergen die vaak incorrecte prijzen weergeeft om zo vergelijken makkelijker (en persoonlijker?) te maken.

[moozzuzz]

Kan je een voorbeeld geven van valse truckjes die winkels hanteren?

[Yamotek]

Pre-orders, het zijn niet 'valse' truukjes maar meer dat er een foutieve prijs staat (goedkoop) terwijl het product eigenlijk helemaal niet op voorraad is bij de desbetreffende winkel.

Tijdens het zoeken in de pricewatch naar verschillende uitvoeringen van videokaarten wordt het heel lastig eruit halen welke versie van een bepaalde videokaart nou goedkoper is (bijvoorbeeld alle versies van de RX 480, of alle versies van de 1060 van Nvidia).

Over het algemeen is het dezelfde winkel die het foutief vermeld en zou ik deze graag willen verbergen, maar dit is dus niet mogelijk. De winkel meenemen maakt toch niet uit, omdat ik er niet wil bestellen.

[sfranken]

Dat zou inderdaad fijn zijn. Ik krijg soms resultaten voor shops uit het buitenland die daadwerkelijk op kostprijs goedkoper zijn, maar met verzend en inklaringskosten is het duurder. Die zou ik, als het even kan, inderdaad niet willen zien.

[robvanwijk]

Ik krijg soms resultaten voor shops uit het buitenland die daadwerkelijk op kostprijs goedkoper zijn, maar met verzend en inklaringskosten is het duurder.

Ga eens naar het prijsoverzicht van een willekeurig product en kijk in de linkerbalk. Daar kun je een betaalmethode en een verzendmethode aangeven. Het is niet perfect (in het ideale geval zou je de prijs van ophalen bij de winkel om de hoek willen vergelijken met de prijs van bezorgen voor winkels ver weg), maar je komt een heel eind.

Inklaren zou niet van toepassing mogen zijn, toch? Ik kan geen mooi lijstje vinden, maar ik dacht dat er alleen winkels in Nederland en België (en misschien een handvol uit Duitsland, Frankrijk en/of Engeland) in de Pricewatch staan? Zolang je binnen de EU blijft (en consument bent) heb je dan geen last van de douane.

[Reactie gewijzigd door robvanwijk op 24 juli 2024 12:07]

[MazeWing]

Klopt het dat de weergave op mobiele apparaten anders is geworden? Het lijkt erop dat de tekst net iets kleiner is geworden en de zaken net iets dichter op elkaar staan.

Niet hinderlijk, maar viel me wel op.

[Inspector]

Nee daar is nu net niets aan veranderd Heb je een concreet voorbeeld?

[The_Worst]

De uitlijning bij de top-stories, de rij met afbeeldingen op de frontpage, klopt helemaal niet. Tekst zweeft aan de bovenkant.

[Inspector]

Thnx, e.e.a. is gefixed mocht je nog meer zien hoor ik het graag

[-The_Mask-]

Ik had op mijn mobiel altijd bij devicedetect 15" geforceerd zodat alles niet zo extreem groot was. Gewoon de desktop weergave dus, maar dat werkt nu niet meer. Er veranderd niks als ik een andere weergave forceer.

Daarmee is de layout van mijn userreviews trouwens ook stuq. Dus als je daar ook nog een oplossing voor weet mag je het zeggen.

productreview: Corsair CX450M review door -The_Mask-

[Inspector]

Is helaas momenteel even stuk maar zijn we druk mee bezig.

[The_Worst]

Ik merkte hetzelfde. Bij mij valt voornamelijk de uitlijning op in de reacties. De gebruikersnaam lijkt te hoog te staan in verhouding tot de avatar en dan voornamelijk in reacties op een reactie (dus niet top-level).

Edit: het lijkt ook te gebeuren op de desktop maar daar valt het minder op.
Afbeelding

[Reactie gewijzigd door The_Worst op 24 juli 2024 12:07]

[Verwijderd]

Als dat 'lazy loading' er komt, dan aub met een optie om het uit te zetten, persoonlijk echt geen fan van namelijk, waarom wachten met het inladen van plaatjes tot ik naar dat punt op de pagina scroll? ik wil juist dat als ik scroll het plaatje er al staat.

En als we dan verder doorgaan, naar lazy loading 'wat de pagina langer maakt' (wat gelukkig niet de insteek lijkt te zijn) dan begin ik al helemaal te schuimen, degene die dat heeft bedacht is wat mij betreft een idioot, het zal wel aan mij liggen maar ik vind het bij zulke sites altijd super irritant dat je scrollbar steeds veranderd. (verplaatst/opnieuw schaalt)

(zoals uit beide punten een beetje naar voren komt, ik word oud haha, al die nieuwerwetse fratsen storen me)

[Reactie gewijzigd door Verwijderd op 24 juli 2024 12:07]

[Soggney]

Het hangt er vanaf hoe het is geïmplementeerd. maar alsmen de viewport definiëerd als net wat langer en breder is dan je scherm, dan is het plaatje ingeladen als je er naartoe scrolt en wordt het eerstvolgende plaatje ingeladen. Tenzij je supersnell scrollt op een brakke verbinding, zou je hier niks van mogen merken.

Het 2de dat je beschrijft kan ook al opgevangen worden door middel van metadata. Als de placeholders van de plaatjes al een width en height krijgen in de pagina, maar het plaatje zelf is nog niet geladen, zal je scrollbar na het inladen van de initiële load niet meer veranderen. De plaatjes komen dan in de placeholder te staan als je dicht genoeg bent, zonder dat dit de lengte van de pagina aanpast.

Maar dat zijn aandachtspunten die sommige websitebouwers niet willen of kunnen toevoegen. Maar het niveau van tweakers qua website bouw kwaliteit steekt toch met kop en schouders boven de meeste websites uit.

[Hmmbob]

Ik denk dat hij meer doelt op een concept zoals Twitter, waarbij verder naar beneden scrollen ervoor zorgt dat de pagina langer wordt en dus de scrollbar weer verspringt.

[Inspector]

Dat wordt ook wel een "infinite scroll" of "endless scroll" genoemd en ik denk inderdaad dat hij daar de associatie mee legt. Dat is overigens niet iets waar wij naar toe willen. Onze PoC is enkel het lazy loaden van afbeeldingen. Daarbij willen we al gaan laden als ze in de buurt van de viewport komen.

Als we het implementeren is het enkel goed als niemand het door heeft maar het wel een positieve impact op de performance heeft. Dat zal dan ook het streven worden.

Edit: Mobile typo's

[Reactie gewijzigd door Inspector op 24 juli 2024 12:07]

[HashIT]

Met als superlatief van irritant de brakke implementaties die een footer onderaan een dergelijke pagina hebben staan. Scroll je naar beneden om iets in de footer te lezen, verdwijnt die weer uit beeld...

[BikkelZ]

Hoe werkt lazy loading nou precies met Google indexatie vraag ik me af. Kun je bijvoorbeeld een <noscript><img src="" /></noscript> declareren of scraped Google het op een intelligente manier? Als je een site met foto's hebt kun je best wel wat traffic genereren via Google Image Search.

[Verwijderd]

Google kan tegenwoordig bijna alles scrapen, zelfs sites/web apps die vrijwel geheel uit JS bestaan om content te renderen.

[BikkelZ]

Sinds wanneer is dat verbeterd? Want het werd aangekondigd maar er waren toch redelijk wat sites die niet goed geïndexeerd werden als ze het puur in JS deden. Maar er is zoveel tegenstrijdigheid te vinden op het web over dit thema dat ik voor de zekerheid alles ook statisch te indexeren maak als het echt draait om clicks === geld

[Reactie gewijzigd door BikkelZ op 24 juli 2024 12:07]

[Verwijderd]

Dat is al jaren zo. Als voorbeeld: Google analyseert actief hoe "mobile friendly" je site is. Het meet hoe groot click targets zijn. Het weet ook wat er allemaal "above the fold" is. De enige manier waarop het dan kan weten, is door je site volledig te renderen, dus met JS.

Je hebt wel gelijk dat het een black box is waarin veel aannames gedaan worden, en Google laat verder weinig los. Om die reden is het slim wat je doet om voor de zekerheid zoveel mogelijk zonder JS te renderen.

[CLB]

Ligt het aan mij of is het sinds vandaag niet meer mogelijk om de 'schermgroottes' te schalen?
Zowel in Chrome en Firefox mobile staat deze optie nu op 'automatisch schalen' en kan ik geen enkele andere optie selecteren die dan vast blijft staan? Ik gebruik altijd 'desktops (16" en groter)' maar zie nu dus de mobiele lay-out. Hopelijk een foutje (aan mijn kant) en dus tijdelijk, anders is het wel knarsetanden Plaatje van Chrome: https://tweakers.net/ext/f/YwnsxZmas57BnYQwHSatr0Nj/full.jpg

EDIT: Ook op de desktop kan ik niet schalen (never tried before)

[Reactie gewijzigd door CLB op 24 juli 2024 12:07]

[Xav]

Haha, geen zorgen dit is een foutje die gerelateerd is aan bovenstaande issues. Wij hebben de oorzaak al gevonden en zijn bezig met een hotfix. Even volhouden nog...

[Only]

Ik snap niet eens waarom mensen uberhaupt die mobiele weergave zouden willen gebruiken, echt verschrikkelijk om te gebruiken op een telefoon en laat staan op een tablet..

[Blokker_1999]

Omdat die is geoptimaliseerd voor de kleine schermen? Ik moet er niet aan denken om de desktop versie op mijn telefoonschermpje te zetten. Veel te veel scrollen in dat geval.

[Only]

Ehh, jij moet juist meer scrollen nu he..minder content in beeld.

[Dingen]

Ik vind de mobiele layout wel goed juist! Ik kan me niet voorstellen dat de desktopversie lekker werkt op een 4" schermpje.

[Reactie gewijzigd door Dingen op 24 juli 2024 12:07]

[Chotto Toire]

Toen de "vergelijk"-knop op elke Pricewatchpagina verscheen dacht ik: "Nu is de Pricewatch af." En nu de dalers zijn toegevoegd weet ik, tot mijn grote verbazing, dat hij dus nóg beter kan. Nee, het is niet m'n bedoeling om te slijmen; ik ben gewoon echt onder de indruk. De Pricewatch is een heel bijzondere functie geworden. Mijn complimenten!

[koku]

Dankjewel, op naar de volgende Website van het Jaar Award voor de Pricewatch!

[BLACKfm]

"Where are my dragons!?!"

Ik ben de tracker aan de zijkant van me scherm kwijt ...

Edit: Blijkbaar hebben ze bij het devteam geen ultra-wide schermen, want als ik het browserscherm verklein komt die weer in beeld. #bug

Als het browserscherm breder is dan 2000 pixels gaat de tracker weg. Dus dat is wat makkelijker zoeken denk ik .

Edit: Fixed i see.

[Reactie gewijzigd door BLACKfm op 24 juli 2024 12:07]

[Xav]

Gaan wij even naar kijken!

[Verwijderd]

Overschakelen naar http2, dan is worden de assets over 1 connectie binnengehaald.
Hiermee Los je al een groot probleem van de pageload op want met http1 wordt voor elke asset opnieuw een connectie opgezet en dat is een grote tijdskost in je pageload.

[Inspector]

We draaien al op http2. Dat lost overigens het probleem niet op. Op een mobiele data connectie haal je nog steeds alle assets op of dat nu asynchroon gaat of niet wat zonde is van de bandbreedte. Daarnaast heeft niet iedereen beschikking over http2.