Waarom laad tweakers zo goed?

[Verwijderd]

Hallo,

Het is misschien een rare vraag, maar waarom laad tweakers zo goed? Mijn internet zit nu op smallband met 0.4 download (door te veel te downloaden). En tweakers hoort bij de enige sites die nog direct laad. Zelf google laat het afweten.

Blijf doen wat je doet tweakers .

[jorisvdelsen]

Heb je Tweakers.net bij favorieten staan?

[WoutF]

Omdat onze devvers efficiënte code en snelle laadtijden hoog op de prioriteitenlijst hebben staan

[Verwijderd]

jorisvdelsen schreef op donderdag 14 augustus 2014 @ 14:36:
Heb je Tweakers.net bij favorieten staan?

Ja, Maar ik wist niet dat google chrome deze pagina's extra caches?

[The Eagle]

Ik denk dat het ook wel eens te maken zou kunnen hebben met een caching proxy die er tussen zit. is het toevallig mobiel sitegebruik waar je over praat?

[Verwijderd]

The Eagle schreef op donderdag 14 augustus 2014 @ 14:44:
Ik denk dat het ook wel eens te maken zou kunnen hebben met een caching proxy die er tussen zit. is het toevallig mobiel sitegebruik waar je over praat?

Nope Computergebruik, Maar ik ben niet zeker of het mobiel gebruik verschil maakt. Als je je venster verkleint neemt het responsive design het over en switch de site naar de mobiele versie.

[Dido]

Dus... je bent net uitgefoeterd bent door je baas omdat de site die je hebt opgeleverd niet vooruit te branden is.

En je hebt geen idee hoe je de site sneller moet krijgen...

[_David_]

Omdat:

1. Tweakers zijn javascript en css minified, zie http://tweakimg.net/x/min/framework.css
ipv http://tweakimg.net/x/framework.css

2. er geen onnodig veel javascript wordt ingeladen (zoals bijvoorbeeld jquery en andere library's)

3. omdat images en andere static content allemaal van verschillenden domeinen komen (tweakimg.net) en er zo dus meerdere dingen tegelijk geladen worden

en nog wel andere dingen zoals het gebruik van varnish, performance is a feature, etc

als je er geinteresseerd in bent dan moet je is kijken naar dingen zoals google pagespeed en Yslow, die geven aan wat je kan optimaliseren zodat je website sneller wordt.

[ Voor 6% gewijzigd door _David_ op 14-08-2014 15:16 ]

[Cyphax]

WoutF schreef op donderdag 14 augustus 2014 @ 14:36:
Omdat onze devvers efficiënte code en snelle laadtijden hoog op de prioriteitenlijst hebben staan

Dus Tweakers is zo'n snelle site omdat de devvers er een snelle site van hebben gemaakt?

Ik zie bij een request Via: Varnish terugkomen. Dat lijkt me een hele belangrijke factor. Mijn ervaringen met Varnish zijn ook dat het de sloomste pagina bloedsnel maakt. Iets minder dynamisch over het algemeen, maar bizar snel.

[Kees]

Cyphax schreef op donderdag 14 augustus 2014 @ 15:12:
[...]

Dus Tweakers is zo'n snelle site omdat de devvers er een snelle site van hebben gemaakt?

Ik zie bij een request Via: Varnish terugkomen. Dat lijkt me een hele belangrijke factor. Mijn ervaringen met Varnish zijn ook dat het de sloomste pagina bloedsnel maakt. Iets minder dynamisch over het algemeen, maar bizar snel.

Varnish doet helemaal niets met de dynamische pagina's, alleen doorgeven. Varnish cached wel de images, css en javascript en die geeft hij dan ook vlotjes door aan de gebruikers. Verder is onze code gewoon behoorlijk snel. Op NewRelic staan we vrijwel altijd in de top-5 snelste websites in onze groep. Soms baal ik wel van al die dynamische pagina's want die zijn niet te cachen

Maar een van de allerbelangrijkste dingen om een site goed en snel op een langzame verbinding weer te geven is goede clientside caching. Als je tweakers 2x opvraagt dan zul je zien dat bij die tweede keer je maar 5 requests doet. 1 keer op de frontpage, 2 op een google-analytics script, 1 op een bannerboer en 1 op webtrekk analytics. En die laatste 4 gebeuren asynchroon.

Dus de pagina kan al gerenderd worden zodra de frontpage binnen is; wat gemiddeld ~60KB is die na ~60ms je kant op komt. Op een smallband met 0,4 (mbit?) dus ~50KB/s kost het je dus gemiddeld 1,2 seconde om de data binnen te krijgen en dan kan de pagina weergeven worden. Verder gebruiken we niet standaard https, dus je hebt (in het ergste geval) maar 42 roundtrips nodig over een langzame verbinding.

Als ik op google een refresh doe, dan wil hij 140KB aan data binnenhalen voor de frontpage. Wat ook nog eens over over SSL gaat. Dus om de connectie op te zetten heb je al een aantal RTT's nodig en daarna kost het je minimaal 2,8 seconden en (in het ergste geval) 94 roudtrips om de data binnen te halen. Daarna kan je browser pas gaan renderen.

Maar als je dan ook nog eens ingelogt bent op google+ dan is het helemaal een feest. Google haalt dan bij mij bijna 2MB aan data binnen (waarvan een javascript van bijna 1,2MB groot, wtf?). Met 50KB/s doe je daar dus gewoon 40 seconden over.

Qua performance zijn er nog dingen die beter kunnen bij ons, zoals bijvoorbeeld foto's op de frontpage standaard door een tool als kraken.io halen (de layout-plaatjes zijn al optimized).

[ Voor 3% gewijzigd door Kees op 14-08-2014 15:53 ]

[ThinkPad]

Viel mij ook op toen ik op vakantie was en op een overbelaste WiFi-hotspot zat. Sites als Google e.d. duurden een eeuwigheid, terwijl Tweakers bijna net zo snel als thuis was

[Kees]

ThinkPadd schreef op donderdag 14 augustus 2014 @ 15:47:
Viel mij ook op toen ik op vakantie was en op een overbelaste WiFi-hotspot zat. Sites als Google e.d. duurden een eeuwigheid, terwijl Tweakers bijna net zo snel als thuis was

Ja, toen ik in Sudan zat laatst was Tweakers eigenlijk de enige website met een beetje snelheid. Dat voelt dan wel goed

Een site als nu.nl is helemaal leuk. Na een vervolg-view doet die gewoon weer doodleuk 40+ requests van bijna 500KB waaronder een hele stapel images die gewoon gecached moeten worden en verder veel te veel trackers en kavascript.. Waarom zou je in vredesnaam 4x exact dezelfde JS op willen halen vanaf doubleclick per pageview? Of 3x javascript vanaf ad.370yield.com. Of twee scorecardresearch pixels. etc, schoolvoorbeeld van hoe het niet moet. (sowieso, scorecardresearch voor STIR hoeft niet meer, niemand de memo gekregen?)

[ Voor 4% gewijzigd door Kees op 14-08-2014 15:57 ]

[Verwijderd]

Database optimaliseren, indexes en caching > werkt retesnel.

[Kees]

Verwijderd schreef op donderdag 14 augustus 2014 @ 15:55:
Database optimaliseren, indexes en caching > werkt retesnel.

Database zo min mogelijk gebruiken -> nog sneller

[Cyphax]

Kees schreef op donderdag 14 augustus 2014 @ 15:43:
[...]

Varnish doet helemaal niets met de dynamische pagina's, alleen doorgeven. Varnish cached wel de images, css en javascript en die geeft hij dan ook vlotjes door aan de gebruikers. Verder is onze code gewoon behoorlijk snel. Op NewRelic staan we vrijwel altijd in de top-5 snelste websites in onze groep. Soms baal ik wel van al die dynamische pagina's want die zijn niet te cachen

Cachet Varnish bijvoorbeeld zo'n nieuwsbericht helemaal niet? Reacties zijn sowieso dynamisch maar daar zijn wel oplossingen voor. Je zult het niet voor niets inzetten.
Snelle code, snelle netwerkverbindingen, het is allemaal belangrijk. Het zal toch wel een combinatie van factoren zijn lijkt me?

[Kees]

Cyphax schreef op donderdag 14 augustus 2014 @ 16:09:
[...]

Cachet Varnish bijvoorbeeld zo'n nieuwsbericht helemaal niet? Reacties zijn sowieso dynamisch maar daar zijn wel oplossingen voor. Je zult het niet voor niets inzetten.
Snelle code, snelle netwerkverbindingen, het is allemaal belangrijk. Het zal toch wel een combinatie van factoren zijn lijkt me?

Uiteraard is het een combinatie van alle factoren. Netwerk, switches, netwerkopzet, onderlinge verbindingen, hardware, databases, welke database voor welke job, waar kun je cachen, hoe kun je het beste cachen, snelle code, weinig externe js libraries, plaatjes optimizen, cdn inzetten, etc etc.

Gewoon een lijstje van gebruikte software waar een pagina mee te maken heeft: Apache/PHP/APC, Tomcat/JAVA, Varnish, Percona/MySQL, Mongodb, ActiveMQ, Memcache, Omega, Lighttpd, etc

Maar een nieuwsbericht kan nog steeds niet gecached worden. Die pagina is voor bijna elke user anders, bijvoorbeeld je username bovenaan de pagina in de header. Varnish kan aan het cookie niet zien of het een niet-ingelogde gebruiker is en het zou te complex zijn om het heel selectief te cachen en die cache ook nog eens fatsoenlijk laten expiren als er iets op de pagina veranderd.

Dus cachen we wat we kunnen en proberen de rest zo snel mogelijk te houden. Onderaan de paginasource van elke pagina kun je wel ongeveer zien wat we doen

[ Voor 6% gewijzigd door Kees op 14-08-2014 16:35 ]

[The Eagle]

Kees schreef op donderdag 14 augustus 2014 @ 15:43:
[...]

...
Maar een van de allerbelangrijkste dingen om een site goed en snel op een langzame verbinding weer te geven is goede clientside caching. Als je tweakers 2x opvraagt dan zul je zien dat bij die tweede keer je maar 5 requests doet. 1 keer op de frontpage, 2 op een google-analytics script, 1 op een bannerboer en 1 op webtrekk analytics. En die laatste 4 gebeuren asynchroon.
...

Wat ik me dan weer afvraag: welke kost het meeste tijd / resources, en welke wil je vanuit performance oogpunt dus het eerste kwijt? Er is een stemmetje in mijn hoofd dat naar die bannerboer neigt

Kees schreef op donderdag 14 augustus 2014 @ 15:51:
[...]

Ja, toen ik in Sudan zat laatst was Tweakers eigenlijk de enige website met een beetje snelheid. Dat voelt dan wel goed
...

Sudan? Op zoek naar een nieuwe op diesel aggregaats lopende failover locatie voor GoT?

[_David_]

The Eagle schreef op donderdag 14 augustus 2014 @ 16:43:
[...]


Wat ik me dan weer afvraag: welke kost het meeste tijd / resources, en welke wil je vanuit performance oogpunt dus het eerste kwijt? Er is een stemmetje in mijn hoofd dat naar die bannerboer neigt

Bannerboer dus maar dat maakt toch niet zoveel uit omdat zoals Kees al zei, die requests gaan asychroon dus de browser wacht niet met renderen totdat de banners geladen zijn (daarom verspringt de pagina ook soms als je geen abo bent, de ads worden er pas later bij ingeladen)