15 ms·

300ms Faster: Reducing Wikipedia's total blocking time

509 points by janpio 3y ago

e63f67dd-065b 3y ago
300ms is on a low-end android phone, which is nice, but I wonder what's the performance impact on something more modern, like a 2 year-old iPhone.
- silvestrov 3y ago
  On high end phones it is more of a "battery impact" than a "delay impact".
  - dredmorbius 3y ago
    I've been using an e-ink device extensively for the past few years. It's nominally an e-book reader, though in truth it's an Android tablet with an e-ink display. I use it for both reading books and websites. I'd recently looked at battery usage and found that my preferred browser (Einkbro) uses ten times as much battery per hour of reading than Neoreader (the Onyx BOOX stock ebook reader). Einkbro is a solo-developer effort (based on the FOSS browser), so I'm not sure how much energy-usage optimisation it has or is lacking. It's sufficiently pleasant to use (relative to other Android browser options) that I don't use other browsers significantly ("Neobrowser", a re-branded Chromium, and Firefox Fennec are both installed, and used occasionally). But it really sucks down juice. That's on top of the fact that many web pages are larger (storage, memory use) than a full-length book. Typical e-pubs run ~500 kB -- 5 MB, with graphics-heavy or scanned-in books running up to 100+ MB. I also find that reading pre-formatted, laid-out content with pagination and navigation is increasingly far more pleasant than scrolling through a Web document. HTML as presently instantiated has some pretty sharp corners and limitations.
exabrial 3y ago
The better question is: Why use Javascript at all for a static website?
- janpio 3y ago
  The article mentions the functionality that the Javascript is used for: Expanding and collapsing sections, adding the media viewer on thumbnails shown in the page. Both seems like reasonable use cases for interactivity that is (better) achieved using Javascript.
  - exabrial 3y ago
    None of those things actually enhance the website. The only time people "use" them is by accident.
    - muspimerol 3y ago
      Hard disagree, I use the hover-to-preview-article feature all the time. Sometimes I just want to peek at a page to see what it is instead of opening it.
    - janpio 3y ago
      I don't think that is true. On Wikipedia's mobile view, collapsed sections are super useful (as the table of contents is not visible via the sidebar) and media viewer makes it possible to view details of an image/thumbnail without navigating away from the page.
      - iggldiggl 3y ago
        > collapsed sections are super useful (as the table of contents is not visible via the sidebar) Yes and no. On the hand some sort of table of contents is useful (but note that you could also just display it inline, the way it used to be done in previous desktop skins), on the other hand those collapsed sections break scroll position restoring when reloading the page after somebody (your browser or directly the OS) kicked it out of your RAM. This is because your (absolute) scroll position depends on which sections where expanded and which collapsed, and that information gets lost when the page reloads – all sections end up collapsed again and the scroll position your browser remembered no longer makes sense. (There is some sort of feature that tries to restore the section state, but a) it only works within the current session, but not if the OS low memory killer kicked the whole browser out of your phone's RAM and b) even when it does work, it runs too late in relation to the browser attempting to restore the previous scroll position.) So now that the mobile Wikipedia's full JavaScript no longer runs on e.g. older Firefoxes (e.g. one of the last pre-Webextension versions), the lack of a TOC is somewhat annoying, but other than that, somewhat ironically my browsing experience has become much, much better now that my browser can finally reliably restore my previous scroll position because now all sections are permanently expanded.
lucgagan 3y ago
Unrelated, but I love how fast your website loads. I looked at the source code, and it looks like it uses Astro. I debated whether to go with Astro or Next.js for my new blog, but because I've not had experience with the new React server components, I decided to try Next.js. I've had a goal of making it have the least bloat possible, so it is kinda interesting to compare these side by side now. I picked random two posts that have similar amount/type of content: * https://www.nray.dev/blog/using-media-queries-in-javascript/ https://www.nray.dev/blog/using-media-queries-in-javascript/ [total requests 13; JavaScript 2.3 kB; Lighthouse mobile performance 100] * https://ray.run/blog/api-testing-using-playwright https://ray.run/blog/api-testing-using-playwright [total requests 19; JavaScript 172 kB; Lighthouse mobile performance 100] It looks like despite predominantly using only RSCs, Next.js is loading the entire React bundle, which is a bummer. I suspect it is because I have one 'client side' component. One other thing I noticed, you don't have /robots.txt or /rss.xml. Some of us still use RSS. Would greatly appreciate being able to follow your blog!
- Rauchg 3y ago
  Do note that while Astro is a fine choice, your blog has much snappier page transitions with speculative prefetching and pre-rendering, while maintaining an equally good Lighthouse score. As projects scale this matters more. For example, hard page transitions will accrue the cost of re-initializing the entire application’s scripts for every click.
  - crooked-v 3y ago
    Also, being able to split things across pages with almost zero extra overhead in navigation time and bundle time makes it way easier to structure big, complicated sites or web apps.
- changethe 3y ago
  the fact that you can use whatever component framework you want and mix and match is pretty awesome. been hooked on astro ever since trying it out once :) another low-hanging fruit for optimisation that nray.dev is not using, is the new inline-stylesheets option: https://docs.astro.build/en/reference/configuration-reference/#experimentalinlinestylesheets https://docs.astro.build/en/reference/configuration-referenc... using the 'auto' option usually reduces it to a single global sheet and page-specific inlined css. especially if you are writing a lot of short style blocks in your components, this is very very handy to reduce the amount of served css files.
wolrah 3y ago
If the author or anyone else with the ability to update Wikipedia's code itself is reading this, I have a suggestion for some low-hanging fruit that wastes a lot more than 300ms for all sorts of users, not just those on low-end mobile devices. Wikipedia, like many web sites, makes it really easy for mobile users to get redirected to a mobile-specific version running on a mobile-specific domain. The problem is that this mobile-specific version is not good for browsing on a full computer. It's not even great on a tablet. But there's no easy way to switch back when I've been sent a mobile-specific link other than editing the link by hand. Mobile links end up everywhere thanks to phone users just copy/pasting whatever they have, and desktop users suffer as a result. Please, anyone who develops web sites, stop doing the mobile-specific URL nonsense. Make your pages adaptable to just work properly on all target devices. If you insist on doing things this way with mobile-specific URLs, at least make it equally easy for desktop users to get off the mobile URLs as you make it for phone users to get on them.
- yorwba 3y ago
  Scroll down to the bottom, click "Desktop". Not easy to notice that this is an option, not too hard to use once you've found out.
  - lloydatkinson 3y ago
    And yet practically very little effort for Wikipedia to serve the correct version
    - jvm___ 3y ago
      But how do you determine the users intent? They asked for the mobile version - but they're on desktop. Do you serve what the asked for? Or what you think they should want? What if they actually want the mobile version - if you always send desktop to desktop, then they can't get mobile...
      - jakear 3y ago
        Not sure why the downvotes, this is a reasonable question. (As evidenced by all the other answers...) The simple answer is that you don't encode device specific intent in the URI, you put in in style sheets where it belongs.
jonatron 3y ago
https://davidwalsh.name/event-delegate https://davidwalsh.name/event-delegate By David Walsh on March 7, 2011 One of the hot methodologies in the JavaScript world is event delegation, and for good reason.
samsquire 3y ago
From the sounds of the article, that 300 milliseconds wasn't much addition or math or number crunching but essentially book keeping and querying. A lot of that crunching is either whittling through DOM traversals. I've heard that rule of thumb that there are 5-9 machine instructions before JMP or CALL which you can find if you search "instructions per branch cpu" If I had a database of 4,000 links and instantiated a function event handler to each one, that would be slow. But if I could invert the problem and test if the clicked object is inside an active query resultset, that could be fast. It could be automatic.
Reason077 3y ago
I've noticed that Wikipedia is, now days, extremely fast if I'm not logged in. Just about any article loads near-instantaneously, it might even be faster than Hacker News! But if I'm logged in its much slower - there's perhaps a second or so lag on every page view. Presumably this is because there's a cache or fast-path for pre-rendered pages, which can't be used when logged in?
- robin_reala 3y ago
  This is fairly typical, and applies to HN too – you’ll see dang suggesting that people log out when there’s breaking news that gets a lot of engagement here.
  - remram 3y ago
    The difference is that HN stays very fast. Being logged in is more costly for the backend, but doesn't degrade your experience as a user. On Wikipedia you really suffer for being logged in.
    - electroly 3y ago
      When HN is slammed, you just get the "sorry, HN is having problems" message. This is when dang suggests logging out. On many occasions that turns not being able to see the site at all into the site working quickly.
      - remram 3y ago
        Sure, past some threshold HN goes down, and at that point there is a (big) difference between the logged-in and logged-out experience. My point is that, the rest of the time, there is not, whereas for Wikipedia, the logged-in experience is always significantly worse than the logged-out experience. This encourages people to not log in which is a problem.
- znpy 3y ago
  If you’re not logged you’re getting the pre-rendered, cached page. If you’re logged, a number of things have to be recomputed before the page can be rendered. I run mediawiki at home, the difference is even more stark (i have a small home server).
robin_reala 3y ago
Incidentally, if you’re interested in the performance cost of jQuery, GOV.UK posted last year an analysis of the performance gain seen when they removed jQuery in favour of vanilla JS: https://insidegovuk.blog.gov.uk/2022/08/15/the-impact-of-removing-jquery-on-our-web-performance/ https://insidegovuk.blog.gov.uk/2022/08/15/the-impact-of-rem...
- mtmail 3y ago
  HN discussion of that blog post https://news.ycombinator.com/item?id=32480755 https://news.ycombinator.com/item?id=32480755
- zapt02 3y ago
  I would like to see a similar blog post, but for React.
- austin-cheney 3y ago
  Not super impressive. I was able to get SPA state restoration down to the first 80ms of page time on old hardware. Provided the same techniques I have no doubt this site can achieve page load times under 0.5 seconds. https://github.com/prettydiff/wisdom/blob/master/performance_frontend.md#execution-performance---browser https://github.com/prettydiff/wisdom/blob/master/performance...
  - piranha 3y ago
    I haven't read your report completely, but it's very interesting. I would love to hear a bit more details about query selector performance. Could you maybe provide some details or a pointer where this was tested? Also about websockets vs HTTP calls: HTTP calls do not open separate socket connection even when you're using HTTP/1.1 with keep alive, with HTTP/2 it's a default way of working, so should not be a problem. I guess something else is a culprit here?
    - austin-cheney 3y ago
      Query Selector perf test - https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc Compare the results of that in Firefox versus Chrome as the results are interesting. As for HTTP the issue is two-fold. The first thing is that HTTP imposes a round trip: request and response. That means the connection traffic starts with a request, waits for the application at the remote end to do what it needs, the application at the remote end sends a response whether you want it or not. Secondly, in the case with keep alive all requests on that socket must wait for the prior round trip to fulfill before sending the next request. The primary advantage of HTTP 2 over HTTP 1 is more massively parallel requests, which greatly flatten the waterfall chart of asset requests and thus speeds page load time. In HTTP 1.1 there is typically a maximum of 8 parallel requests. The advantage of Web Sockets is two fold. First, there is no round trip. Each message is fire and forget. This allows messages to be sent more rapidly without waiting (with a caveat). Secondly, Web Sockets is completely bidirectional. The local end and distant end can send messages independently of each other or other timing. The big limitation of Web Sockets is message processing speed. In the Web Socket library I wrote for Node.js performance is memory bound and I can send messages as fast as 470,000 per second on my laptop with DDR4 memory per socket. The problem is not sending, but receiving. Firefox tends to separate frame headers from frame body so you have to account for that. If messages come in too rapidly Node.js will concatenate multiple messages together, so you have to account for that. In TLS the maximum message frame size is 16384 bytes irrespective of the actual message size, so you have to account for that too. There are a few other scenarios to be aware. This processing takes time to parse the binary frame headers and examine the message body length. Even still I can process up to 9000 messages per second on the same machine. The greatest limitation with web sockets though is message queuing. I solved for this on the Node side because there is an event, the drain event, to account for a message leaving the buffer associated with the socket on the local end. As a result I know when to send a message immediately or queue for sending after the current messages completely leave the buffer. Without a queue any message that comes into a socket before a prior message drains from the buffer will overwrite the prior. On the browser side there is no queue and no event to indicate when to send from a queue, so you just have to manually slow things down with a timer.
6510 3y ago
My motto is: It isn't fast until you have to disable gnu zip
est 3y ago
Google's homepage, just a simple text box with a search button is over 1MB.
- Twirrim 3y ago
  Decades ago they relentlessly optimised that page, shaving it down smaller and smaller. Then suddenly they stopped caring, round about the time they gave people customised landing pages with extra junk littering the page. It must have made a palpable difference to their connectivity and serving costs when they did that. That we're back down to a "paltry" 1.9MB (from a quick test I just did) is remarkable.. and yet so much more than it used to be.
  - ppeetteerr 3y ago
    Do people visit the Google homepage anymore? I feel like the address bar of every browser is now the default means by which to search on Google.
  - tlug 3y ago
    It's unbelievable. I used too work for Google back in 2005 and they had a custom to welcome all Nooglers (new Googlers) on Friday general meeting, where Larry/Sergey were present an people could ask them any questions. So one guy stood up and asked why our main page is not compliant with W3C guidelines (doesn't pass HTML validator test). L&S answered that they need to shave off any unnecessary byte, so that it loads faster. That's why they didn't care about closing tags etc. How the world and perception has changed since that time... It's just sad that one needs a huge JS framework just to build a simple website these days. Oh and the size of the homepage was in the order of 20 KB then, IIRC.
cubefox 3y ago
I'm generally not picky with page load times (some cookie nags are far worse), but sometimes even my patience gets tested. The worst offender is substack combined with many comments. I tried opening a Scott Alexander blog post in mobile Chrome on my aging mid range phone: https://astralcodexten.substack.com/p/mr-tries-the-safe-uncertainty-fallacy https://astralcodexten.substack.com/p/mr-tries-the-safe-unce... It's not that it's rendering slowly, it apparently doesn't finish rendering at all. At first a few paragraphs render, then everything disappears. I basically can't read articles on this blog. This website says the above has a total blocking time of 15.7 seconds: https://gtmetrix.com/reports/astralcodexten.substack.com/3y8KoFtI/ https://gtmetrix.com/reports/astralcodexten.substack.com/3y8... That's on more modern hardware I assume. I also tried https://pagespeed.web.dev/ https://pagespeed.web.dev/ but unfortunately it timed out before it finished. Great.
- post-it 3y ago
  > https://astralcodexten.substack.com/p/mr-tries-the-safe-uncertainty-fallacy https://astralcodexten.substack.com/p/mr-tries-the-safe-unce... This doesn't load fully in Safari on an M1 Pro either. I scroll down and the content just ends. It hijacks the scroll bar too.
  - refulgentis 3y ago
    Fine on M2 Pro: forced obsolescence! :P EDIT: _not_ fine on M2 Pro: Chrome works, Safari doesn't. As long as I'm here...so much ink has been spilled on Safari and it's a bitter debate. I really, really, really wanted to make Safari work for a web app and had to give up after months of effort. So many workarounds and oddities that simply aren't present in other browsers. After 15 years orbiting Apple dev...I've finally acquiesced to the viewpoint that carefully filing & maintaining a backlog of bug reports, checking for fixes, and providing a broken experience isn't worth it to me or users
    - toast0 3y ago
      > As long as I'm here...so much ink has been spilled on Safari and it's a bitter debate. Kind of silly to debate over such things. On desktop, the built in browser's only job is to let you download a better browser.
pachico 3y ago
> Remember, the fastest way to speed up a site is to remove JavaScript. I'm not entirely sure this can be so axiomatic...
- KerrAvon 3y ago
  Pretty sure the cases where this isn’t true are the scenarios that are impossible to create without JavaScript, like infinite scrolling. Do you have counter-examples?
  - pachico 3y ago
    Server side issues? Images being too big? Maybe slow CSS, if there's such thing?
    - bawolff 3y ago
      > Maybe slow CSS, if there's such thing? That can definitely be a thing. However JS is usually a much bigger issue.
  - gwern 3y ago
    There's a demo somewhere of infinite-scrolling without JS. The hack is you just never close/finish the request/connection so it keeps sending new content!
  - LegionMammal978 3y ago
    Recently, https://garden.bradwoods.io/notes/css/blend-modes https://garden.bradwoods.io/notes/css/blend-modes was linked to, which, using Firefox on Android, takes hundreds of milliseconds to paint the new screen whenever I scroll. I can also notice the behavior on my desktop if I scroll quickly enough, even if I disable JavaScript. So it most likely has to do with an advanced CSS feature, perhaps the blend modes it is showcasing.
jesprenj 3y ago
The link hower popups were incredibly slow on my older laptop on palemoon. I just disabled javascript on wikipedia because it's written quite poorly performance wise in my opinion.
floatboth 3y ago
Seeing "Sizzle" in that profile made me feel shocked. Uhhh Wikipedia actually still uses an ancient build of jQuery that does not take advantage of native querySelector at all?!?
- MatmaRex 3y ago
  No, jQuery falls back to Sizzle when a selector is not supported by native querySelector, either due to using jQuery-specific extensions, or due to lacking browser support.
winrid 3y ago
heh, event delegation was like my first interview question in software. Amazing that I've I've using Wikipedia all this time with this issue :P
cutler 3y ago
Can someone please do the same for Hacker News? For a text-based site it's dog slow.
- lkbm 3y ago
  Now this is interesting...I just and it was 106ms for the main document, and ~60ms for the rest (including favicon). But then I tested in Incognito, and it was 350ms for the main document. Disabling cache doesn't make a difference. I tried logging in on Incognito and boom, fast again. Somehow the backend is 3x the speed when logged in. I'm guessing anon users have to go through some extra bot checking or something.
  - dredmorbius 3y ago
    If anything, anon users should consume fewer resources, as dang's occasionally suggested people log out during heavy usage: <https://news.ycombinator.com/item?id=31027882 https://news.ycombinator.com/item?id=31027882>
    - lkbm 3y ago
      Yeah, it's definitely counter-intuitive. Anon users should be able to benefit from caching in a way that logged in can't. That's why I assume it's bot detection or something along those lines.
dcj4 3y ago
Just disable javascript like any sane person. Wikipedia, like most websites, has no use case for javascript whatsoever.
- pfg_ 3y ago
  Citation previews are nice, much more convenient than clicking the citation and then trying to find the back button. Link previews on desktop are useful too.
- dredmorbius 3y ago
  Speaking as someone who's generally strongly critical of JS abuse and overuse, Wikipedia with JS enabled offers a number of useful positives: - Dynamic tables which can be sorted by column. (This is a feature I'd love to see baked in to HTML browsers generally.) - The recent site redesign offering either visible floating or collapsed page navigation. - Previews of both articles (Wikipedia links) and citations, such that these can be viewed without having to click through to a new page, or scroll the current article. There are a number of others, I'm sure, but these three alone are quite handy.
flaburgan 3y ago
But is event delegation such a good idea? Sure, you're not paying the cost of attaching an event to every thumbnail. But then you're going to execute some code for every single click on the page, even if totally unrelated. Sounds inefficient to me.
- tuukkah 3y ago
  If the user clicks on something where nothing should happen, it does not matter if nothing happens 1ms slower. OTOH if something else should happen, that event handler can call event.stopPropagation(). This stops the event from reaching the delegated event handler, so no inefficiency there.
zodzedzi 3y ago
Unrelated, but this style he draws the timelines in: is it hand-written/hand-drawn, or software-generated? It certainly has the overall feel and appeal of being done by hand, but I'm not sure. If it's software, does anyone know which software, what's the name of this style, etc?
- giraffe-flavor 3y ago
  [dead]
aiff308 3y ago
[flagged]
aiff308 3y ago
[flagged]
lumb63 3y ago
I continue to wonder how much computing power and human time is wasted on grotesquely sub optimal code.

509 points by janpio 3y ago

300ms is on a low-end android phone, which is nice, but I wonder what's the performance impact on something more modern, like a 2 year-old iPhone.

silvestrov 3y ago
On high end phones it is more of a "battery impact" than a "delay impact".
- dredmorbius 3y ago
  I've been using an e-ink device extensively for the past few years. It's nominally an e-book reader, though in truth it's an Android tablet with an e-ink display. I use it for both reading books and websites. I'd recently looked at battery usage and found that my preferred browser (Einkbro) uses ten times as much battery per hour of reading than Neoreader (the Onyx BOOX stock ebook reader). Einkbro is a solo-developer effort (based on the FOSS browser), so I'm not sure how much energy-usage optimisation it has or is lacking. It's sufficiently pleasant to use (relative to other Android browser options) that I don't use other browsers significantly ("Neobrowser", a re-branded Chromium, and Firefox Fennec are both installed, and used occasionally). But it really sucks down juice. That's on top of the fact that many web pages are larger (storage, memory use) than a full-length book. Typical e-pubs run ~500 kB -- 5 MB, with graphics-heavy or scanned-in books running up to 100+ MB. I also find that reading pre-formatted, laid-out content with pagination and navigation is increasingly far more pleasant than scrolling through a Web document. HTML as presently instantiated has some pretty sharp corners and limitations.

exabrial 3y ago

The better question is: Why use Javascript at all for a static website?

janpio 3y ago
The article mentions the functionality that the Javascript is used for: Expanding and collapsing sections, adding the media viewer on thumbnails shown in the page. Both seems like reasonable use cases for interactivity that is (better) achieved using Javascript.
- exabrial 3y ago
  None of those things actually enhance the website. The only time people "use" them is by accident.
  - muspimerol 3y ago
    Hard disagree, I use the hover-to-preview-article feature all the time. Sometimes I just want to peek at a page to see what it is instead of opening it.
  - janpio 3y ago
    I don't think that is true. On Wikipedia's mobile view, collapsed sections are super useful (as the table of contents is not visible via the sidebar) and media viewer makes it possible to view details of an image/thumbnail without navigating away from the page.
    - iggldiggl 3y ago
      > collapsed sections are super useful (as the table of contents is not visible via the sidebar) Yes and no. On the hand some sort of table of contents is useful (but note that you could also just display it inline, the way it used to be done in previous desktop skins), on the other hand those collapsed sections break scroll position restoring when reloading the page after somebody (your browser or directly the OS) kicked it out of your RAM. This is because your (absolute) scroll position depends on which sections where expanded and which collapsed, and that information gets lost when the page reloads – all sections end up collapsed again and the scroll position your browser remembered no longer makes sense. (There is some sort of feature that tries to restore the section state, but a) it only works within the current session, but not if the OS low memory killer kicked the whole browser out of your phone's RAM and b) even when it does work, it runs too late in relation to the browser attempting to restore the previous scroll position.) So now that the mobile Wikipedia's full JavaScript no longer runs on e.g. older Firefoxes (e.g. one of the last pre-Webextension versions), the lack of a TOC is somewhat annoying, but other than that, somewhat ironically my browsing experience has become much, much better now that my browser can finally reliably restore my previous scroll position because now all sections are permanently expanded.

lucgagan 3y ago

Unrelated, but I love how fast your website loads. I looked at the source code, and it looks like it uses Astro. I debated whether to go with Astro or Next.js for my new blog, but because I've not had experience with the new React server components, I decided to try Next.js. I've had a goal of making it have the least bloat possible, so it is kinda interesting to compare these side by side now. I picked random two posts that have similar amount/type of content: * https://www.nray.dev/blog/using-media-queries-in-javascript/ https://www.nray.dev/blog/using-media-queries-in-javascript/ [total requests 13; JavaScript 2.3 kB; Lighthouse mobile performance 100] * https://ray.run/blog/api-testing-using-playwright https://ray.run/blog/api-testing-using-playwright [total requests 19; JavaScript 172 kB; Lighthouse mobile performance 100] It looks like despite predominantly using only RSCs, Next.js is loading the entire React bundle, which is a bummer. I suspect it is because I have one 'client side' component. One other thing I noticed, you don't have /robots.txt or /rss.xml. Some of us still use RSS. Would greatly appreciate being able to follow your blog!

Rauchg 3y ago
Do note that while Astro is a fine choice, your blog has much snappier page transitions with speculative prefetching and pre-rendering, while maintaining an equally good Lighthouse score. As projects scale this matters more. For example, hard page transitions will accrue the cost of re-initializing the entire application’s scripts for every click.
- crooked-v 3y ago
  Also, being able to split things across pages with almost zero extra overhead in navigation time and bundle time makes it way easier to structure big, complicated sites or web apps.
changethe 3y ago
the fact that you can use whatever component framework you want and mix and match is pretty awesome. been hooked on astro ever since trying it out once :) another low-hanging fruit for optimisation that nray.dev is not using, is the new inline-stylesheets option: https://docs.astro.build/en/reference/configuration-reference/#experimentalinlinestylesheets https://docs.astro.build/en/reference/configuration-referenc... using the 'auto' option usually reduces it to a single global sheet and page-specific inlined css. especially if you are writing a lot of short style blocks in your components, this is very very handy to reduce the amount of served css files.

wolrah 3y ago

If the author or anyone else with the ability to update Wikipedia's code itself is reading this, I have a suggestion for some low-hanging fruit that wastes a lot more than 300ms for all sorts of users, not just those on low-end mobile devices. Wikipedia, like many web sites, makes it really easy for mobile users to get redirected to a mobile-specific version running on a mobile-specific domain. The problem is that this mobile-specific version is not good for browsing on a full computer. It's not even great on a tablet. But there's no easy way to switch back when I've been sent a mobile-specific link other than editing the link by hand. Mobile links end up everywhere thanks to phone users just copy/pasting whatever they have, and desktop users suffer as a result. Please, anyone who develops web sites, stop doing the mobile-specific URL nonsense. Make your pages adaptable to just work properly on all target devices. If you insist on doing things this way with mobile-specific URLs, at least make it equally easy for desktop users to get off the mobile URLs as you make it for phone users to get on them.

yorwba 3y ago
Scroll down to the bottom, click "Desktop". Not easy to notice that this is an option, not too hard to use once you've found out.
- lloydatkinson 3y ago
  And yet practically very little effort for Wikipedia to serve the correct version
  - jvm___ 3y ago
    But how do you determine the users intent? They asked for the mobile version - but they're on desktop. Do you serve what the asked for? Or what you think they should want? What if they actually want the mobile version - if you always send desktop to desktop, then they can't get mobile...
    - jakear 3y ago
      Not sure why the downvotes, this is a reasonable question. (As evidenced by all the other answers...) The simple answer is that you don't encode device specific intent in the URI, you put in in style sheets where it belongs.

jonatron 3y ago

https://davidwalsh.name/event-delegate https://davidwalsh.name/event-delegate By David Walsh on March 7, 2011 One of the hot methodologies in the JavaScript world is event delegation, and for good reason.

samsquire 3y ago

From the sounds of the article, that 300 milliseconds wasn't much addition or math or number crunching but essentially book keeping and querying. A lot of that crunching is either whittling through DOM traversals. I've heard that rule of thumb that there are 5-9 machine instructions before JMP or CALL which you can find if you search "instructions per branch cpu" If I had a database of 4,000 links and instantiated a function event handler to each one, that would be slow. But if I could invert the problem and test if the clicked object is inside an active query resultset, that could be fast. It could be automatic.

Reason077 3y ago

I've noticed that Wikipedia is, now days, extremely fast if I'm not logged in. Just about any article loads near-instantaneously, it might even be faster than Hacker News! But if I'm logged in its much slower - there's perhaps a second or so lag on every page view. Presumably this is because there's a cache or fast-path for pre-rendered pages, which can't be used when logged in?

robin_reala 3y ago
This is fairly typical, and applies to HN too – you’ll see dang suggesting that people log out when there’s breaking news that gets a lot of engagement here.
- remram 3y ago
  The difference is that HN stays very fast. Being logged in is more costly for the backend, but doesn't degrade your experience as a user. On Wikipedia you really suffer for being logged in.
  - electroly 3y ago
    When HN is slammed, you just get the "sorry, HN is having problems" message. This is when dang suggests logging out. On many occasions that turns not being able to see the site at all into the site working quickly.
    - remram 3y ago
      Sure, past some threshold HN goes down, and at that point there is a (big) difference between the logged-in and logged-out experience. My point is that, the rest of the time, there is not, whereas for Wikipedia, the logged-in experience is always significantly worse than the logged-out experience. This encourages people to not log in which is a problem.
znpy 3y ago
If you’re not logged you’re getting the pre-rendered, cached page. If you’re logged, a number of things have to be recomputed before the page can be rendered. I run mediawiki at home, the difference is even more stark (i have a small home server).

robin_reala 3y ago

Incidentally, if you’re interested in the performance cost of jQuery, GOV.UK posted last year an analysis of the performance gain seen when they removed jQuery in favour of vanilla JS: https://insidegovuk.blog.gov.uk/2022/08/15/the-impact-of-removing-jquery-on-our-web-performance/ https://insidegovuk.blog.gov.uk/2022/08/15/the-impact-of-rem...

mtmail 3y ago
HN discussion of that blog post https://news.ycombinator.com/item?id=32480755 https://news.ycombinator.com/item?id=32480755
zapt02 3y ago
I would like to see a similar blog post, but for React.
austin-cheney 3y ago
Not super impressive. I was able to get SPA state restoration down to the first 80ms of page time on old hardware. Provided the same techniques I have no doubt this site can achieve page load times under 0.5 seconds. https://github.com/prettydiff/wisdom/blob/master/performance_frontend.md#execution-performance---browser https://github.com/prettydiff/wisdom/blob/master/performance...
- piranha 3y ago
  I haven't read your report completely, but it's very interesting. I would love to hear a bit more details about query selector performance. Could you maybe provide some details or a pointer where this was tested? Also about websockets vs HTTP calls: HTTP calls do not open separate socket connection even when you're using HTTP/1.1 with keep alive, with HTTP/2 it's a default way of working, so should not be a problem. I guess something else is a culprit here?
  - austin-cheney 3y ago
    Query Selector perf test - https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc Compare the results of that in Firefox versus Chrome as the results are interesting. As for HTTP the issue is two-fold. The first thing is that HTTP imposes a round trip: request and response. That means the connection traffic starts with a request, waits for the application at the remote end to do what it needs, the application at the remote end sends a response whether you want it or not. Secondly, in the case with keep alive all requests on that socket must wait for the prior round trip to fulfill before sending the next request. The primary advantage of HTTP 2 over HTTP 1 is more massively parallel requests, which greatly flatten the waterfall chart of asset requests and thus speeds page load time. In HTTP 1.1 there is typically a maximum of 8 parallel requests. The advantage of Web Sockets is two fold. First, there is no round trip. Each message is fire and forget. This allows messages to be sent more rapidly without waiting (with a caveat). Secondly, Web Sockets is completely bidirectional. The local end and distant end can send messages independently of each other or other timing. The big limitation of Web Sockets is message processing speed. In the Web Socket library I wrote for Node.js performance is memory bound and I can send messages as fast as 470,000 per second on my laptop with DDR4 memory per socket. The problem is not sending, but receiving. Firefox tends to separate frame headers from frame body so you have to account for that. If messages come in too rapidly Node.js will concatenate multiple messages together, so you have to account for that. In TLS the maximum message frame size is 16384 bytes irrespective of the actual message size, so you have to account for that too. There are a few other scenarios to be aware. This processing takes time to parse the binary frame headers and examine the message body length. Even still I can process up to 9000 messages per second on the same machine. The greatest limitation with web sockets though is message queuing. I solved for this on the Node side because there is an event, the drain event, to account for a message leaving the buffer associated with the socket on the local end. As a result I know when to send a message immediately or queue for sending after the current messages completely leave the buffer. Without a queue any message that comes into a socket before a prior message drains from the buffer will overwrite the prior. On the browser side there is no queue and no event to indicate when to send from a queue, so you just have to manually slow things down with a timer.

6510 3y ago

My motto is: It isn't fast until you have to disable gnu zip

est 3y ago

Google's homepage, just a simple text box with a search button is over 1MB.

Twirrim 3y ago
Decades ago they relentlessly optimised that page, shaving it down smaller and smaller. Then suddenly they stopped caring, round about the time they gave people customised landing pages with extra junk littering the page. It must have made a palpable difference to their connectivity and serving costs when they did that. That we're back down to a "paltry" 1.9MB (from a quick test I just did) is remarkable.. and yet so much more than it used to be.
- ppeetteerr 3y ago
  Do people visit the Google homepage anymore? I feel like the address bar of every browser is now the default means by which to search on Google.
- tlug 3y ago
  It's unbelievable. I used too work for Google back in 2005 and they had a custom to welcome all Nooglers (new Googlers) on Friday general meeting, where Larry/Sergey were present an people could ask them any questions. So one guy stood up and asked why our main page is not compliant with W3C guidelines (doesn't pass HTML validator test). L&S answered that they need to shave off any unnecessary byte, so that it loads faster. That's why they didn't care about closing tags etc. How the world and perception has changed since that time... It's just sad that one needs a huge JS framework just to build a simple website these days. Oh and the size of the homepage was in the order of 20 KB then, IIRC.

cubefox 3y ago

I'm generally not picky with page load times (some cookie nags are far worse), but sometimes even my patience gets tested. The worst offender is substack combined with many comments. I tried opening a Scott Alexander blog post in mobile Chrome on my aging mid range phone: https://astralcodexten.substack.com/p/mr-tries-the-safe-uncertainty-fallacy https://astralcodexten.substack.com/p/mr-tries-the-safe-unce... It's not that it's rendering slowly, it apparently doesn't finish rendering at all. At first a few paragraphs render, then everything disappears. I basically can't read articles on this blog. This website says the above has a total blocking time of 15.7 seconds: https://gtmetrix.com/reports/astralcodexten.substack.com/3y8KoFtI/ https://gtmetrix.com/reports/astralcodexten.substack.com/3y8... That's on more modern hardware I assume. I also tried https://pagespeed.web.dev/ https://pagespeed.web.dev/ but unfortunately it timed out before it finished. Great.

post-it 3y ago
> https://astralcodexten.substack.com/p/mr-tries-the-safe-uncertainty-fallacy https://astralcodexten.substack.com/p/mr-tries-the-safe-unce... This doesn't load fully in Safari on an M1 Pro either. I scroll down and the content just ends. It hijacks the scroll bar too.
- refulgentis 3y ago
  Fine on M2 Pro: forced obsolescence! :P EDIT: _not_ fine on M2 Pro: Chrome works, Safari doesn't. As long as I'm here...so much ink has been spilled on Safari and it's a bitter debate. I really, really, really wanted to make Safari work for a web app and had to give up after months of effort. So many workarounds and oddities that simply aren't present in other browsers. After 15 years orbiting Apple dev...I've finally acquiesced to the viewpoint that carefully filing & maintaining a backlog of bug reports, checking for fixes, and providing a broken experience isn't worth it to me or users
  - toast0 3y ago
    > As long as I'm here...so much ink has been spilled on Safari and it's a bitter debate. Kind of silly to debate over such things. On desktop, the built in browser's only job is to let you download a better browser.

pachico 3y ago

> Remember, the fastest way to speed up a site is to remove JavaScript. I'm not entirely sure this can be so axiomatic...

KerrAvon 3y ago
Pretty sure the cases where this isn’t true are the scenarios that are impossible to create without JavaScript, like infinite scrolling. Do you have counter-examples?
- pachico 3y ago
  Server side issues? Images being too big? Maybe slow CSS, if there's such thing?
  - bawolff 3y ago
    > Maybe slow CSS, if there's such thing? That can definitely be a thing. However JS is usually a much bigger issue.
- gwern 3y ago
  There's a demo somewhere of infinite-scrolling without JS. The hack is you just never close/finish the request/connection so it keeps sending new content!
- LegionMammal978 3y ago
  Recently, https://garden.bradwoods.io/notes/css/blend-modes https://garden.bradwoods.io/notes/css/blend-modes was linked to, which, using Firefox on Android, takes hundreds of milliseconds to paint the new screen whenever I scroll. I can also notice the behavior on my desktop if I scroll quickly enough, even if I disable JavaScript. So it most likely has to do with an advanced CSS feature, perhaps the blend modes it is showcasing.

jesprenj 3y ago

The link hower popups were incredibly slow on my older laptop on palemoon. I just disabled javascript on wikipedia because it's written quite poorly performance wise in my opinion.

floatboth 3y ago

Seeing "Sizzle" in that profile made me feel shocked. Uhhh Wikipedia actually still uses an ancient build of jQuery that does not take advantage of native querySelector at all?!?

MatmaRex 3y ago
No, jQuery falls back to Sizzle when a selector is not supported by native querySelector, either due to using jQuery-specific extensions, or due to lacking browser support.

winrid 3y ago

heh, event delegation was like my first interview question in software. Amazing that I've I've using Wikipedia all this time with this issue :P

cutler 3y ago

Can someone please do the same for Hacker News? For a text-based site it's dog slow.

lkbm 3y ago
Now this is interesting...I just and it was 106ms for the main document, and ~60ms for the rest (including favicon). But then I tested in Incognito, and it was 350ms for the main document. Disabling cache doesn't make a difference. I tried logging in on Incognito and boom, fast again. Somehow the backend is 3x the speed when logged in. I'm guessing anon users have to go through some extra bot checking or something.
- dredmorbius 3y ago
  If anything, anon users should consume fewer resources, as dang's occasionally suggested people log out during heavy usage: <https://news.ycombinator.com/item?id=31027882 https://news.ycombinator.com/item?id=31027882>
  - lkbm 3y ago
    Yeah, it's definitely counter-intuitive. Anon users should be able to benefit from caching in a way that logged in can't. That's why I assume it's bot detection or something along those lines.

dcj4 3y ago

Just disable javascript like any sane person. Wikipedia, like most websites, has no use case for javascript whatsoever.

pfg_ 3y ago
Citation previews are nice, much more convenient than clicking the citation and then trying to find the back button. Link previews on desktop are useful too.
dredmorbius 3y ago
Speaking as someone who's generally strongly critical of JS abuse and overuse, Wikipedia with JS enabled offers a number of useful positives: - Dynamic tables which can be sorted by column. (This is a feature I'd love to see baked in to HTML browsers generally.) - The recent site redesign offering either visible floating or collapsed page navigation. - Previews of both articles (Wikipedia links) and citations, such that these can be viewed without having to click through to a new page, or scroll the current article. There are a number of others, I'm sure, but these three alone are quite handy.

flaburgan 3y ago

But is event delegation such a good idea? Sure, you're not paying the cost of attaching an event to every thumbnail. But then you're going to execute some code for every single click on the page, even if totally unrelated. Sounds inefficient to me.

tuukkah 3y ago
If the user clicks on something where nothing should happen, it does not matter if nothing happens 1ms slower. OTOH if something else should happen, that event handler can call event.stopPropagation(). This stops the event from reaching the delegated event handler, so no inefficiency there.

zodzedzi 3y ago

Unrelated, but this style he draws the timelines in: is it hand-written/hand-drawn, or software-generated? It certainly has the overall feel and appeal of being done by hand, but I'm not sure. If it's software, does anyone know which software, what's the name of this style, etc?

giraffe-flavor 3y ago
[dead]

aiff308 3y ago

[flagged]

aiff308 3y ago

[flagged]

lumb63 3y ago

I continue to wonder how much computing power and human time is wasted on grotesquely sub optimal code.