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?
Logged out users get served by varnish cache on a server geo-located near you.
Logged in users still get cached pages, but the cache is only part of the page, its not as fast a cache, the servers are not geolocated (they are in usa only for main data center), and depending on user prefs you may be more likely to get a cache miss even on the partial cache.
I wonder if you could fetch the logged-out page first and then re-render client-side what's missing for a logged-in user.
Also, Firefox container tabs might be a nice solution: normally browse in a container where I'm logged out, then to edit, change the tab to my Wikipedia container where I'm logged in.
Well it could be the entire page and then you would get a giant flash or repaints. It is not clear that is any better.
The main things that are different:
* the user links (shows what user you are logged in)
* whether you have a new message notification
* your skin preferences (this will totally change the entire html)
* your language preference (normally this only affects the UI not page content, but some pages it affects page content)
* other misc preferences can affect wikipage content (e.g thumbnail size), although there has been a general effort to avoid adding new ones and remove existing ones that arent used.
* some stuff makes assumptions about logged in users not being varnish (e.g. how csrf tokens work for js based actions), but most of those can be changed if push came to shove.
That said there might be a reasonable argument that much of this isnt needed and it would be a net benefit to kill most of those features.
Yeah, if you use a user setting such as a non-default skin, you should arguably instead install a browser extension or use a client app built on top of PCS (the Page Content Service API): https://en.wikipedia.org/api/rest_v1/#/Page%20content
Thats what we did a former company. You cache the main page on the edges of a CDN. When logged in, you'll get JSON blob that is also cached on the edges using oauth/jwt header as a dimension for the cache key. JSON blob has the users information like username, name etc and its just filled in. Makes the pages extremely performant since everything is cached on edges and protects your origin servers from load. You could also shove stuff into web storage but private mode for some browsers won't persist the data.
I've seen this backfire when someone breaks the configuration of the cache key. All of a sudden people start getting back usernames and personal information of random users.
This is what client side apps do (e.g. React). They come with their own set of challenges which when not solved correctly turn into downsides. Probably still easier for Wikipedia to do than fixing their backend.
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.
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.
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.
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.
Surely there must be a better way to do this, not just for Wikipedia but for all websites with optional logins. It seems like the only difference in the vast majority of cases is to change a single link in the corner of the page from "login" to "the name of my account", which is a silly reason to miss the cache.
this is literally the goal of 20 year old AJAX patterns. progressively enhanced html with javascript on top. absolutely a solvable problem. perhaps wikipedia could look into using Astro or SvelteKit.
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:
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!
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.
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.
I wish any company on the web that spends 6-7 figures a year on their website would hire either of you to make a website that actually loads before I click away.
I worked for many of those and... it is more complicated.
When you are a small team, it is easy to create a performant site because you work in a tight circle with shared conventions, rules, etc. and it is always the same people that work on the project.
When you are a large organization (think Facebook blog), there will be hundreds of engineers/designers/copywriters/... that are exposed to the codebase over the course of many years. Each will need to make a 'quick change' that over time compounds into the monstrosities that you are referring to.
The best you can do is add automated processes into CI/CD that prevent shipping anything that does not meet certain criteria. This might hold for a while... but as soon something borks the shipping velocity and some higher-up starts asking for names, those checks will be removed "temporarily" to unblock what that's burning.
As an engineer who takes pride in developing accessible and performant software, this killed the drive/joy for me of working for large orgs.
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 :)
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.
The initial request size is not a great way to compare frontend frameworks. Next goes into a lot of effort to optimize navigation around your site, and gives you full usage of React in your frontend so you can show amazing things like charts, forms etc.
If the JS files are set to load asynchronously, the initial load should be almost equally as fast, and React should load in the background. Afterwards, additional navigation should be near instant.
Depends how pages are generated. If they are using getStaticProps this is not true because the HTML needs to be "hydrated" with the React runtime which requires javascript. Astro will prebuild the static pages.
Look for a tag like this: <script id="__NEXT_DATA__" type="application/json">
The page will render perfectly fine before it is hydrated when using getStaticProps. To verify , simply run LightHouse in Chrome on a page with cache busting on and look at the screenshot timeline. It will render in a fraction of a second, long before React gets loaded.
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.
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?
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.
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.
There problem is when your auto-detection gets it wrong and you keep getting served the mobile version even if you are not (looking at you www.arista.com).
This is a good use of a session cookie. Or even a stored cookie.
It would be considered a non-tracking essential site function value too, so you wouldn't need to beg permission (contrary to what people who want us to be against privacy legislation will claim), and the site is probably already asking for permission anyway for other reasons so even that point is moot.
I was meaning non-tracking essential cookies, as defined by privacy legislation that requires permission for things that are not essential for site features.
Or are you suggesting mainstream browsers are blocking same-origin session-level cookies by default now? I'm not aware of any. And if you have a browser that is blocking such things, the worst that will happen is the current behaviour (repeated mis-guesses because the preference isn't stored) continues.
This is not entirely accurate. It's only script-writable storage. HTTP cookies are not removed.
I'm not defending Safari's policy, by the way, just describing. I think it sucks, and a conspiracy theorist might note how it favors native apps over web apps.
Needing to re-override the incorrectly detected mobile/not upon return after a full week away will be massively less annoying than needing to do it every new page request, so that shouldn't be problematical.
That Safari does this is useful information that I may need to warn users of one of my projects about, as it means intentionally offline data has a much shorter expiry date than on other platforms.
Everything you've not visited in the last seven days, yes.
Things you touch regularly should be fine.
And apparently it only affects mass local storage, not cookies which are most often used for season management (so you might stay logged in but the app need to reset data previously called in local storage).
how would a cookie help with better auto-detection? to store the platform, maybe, but how do you determine whether the user wants a mobile/desktop version to begin with?
It doesn't help the detection, it means that the override when the detection fails is remembered so the site knows to just pick a particular version instead of using the detection method at all.
It is a work-around improving the UX on the second and subsequent requests, not a fix for the root cause.
If you do it right you don't have auto-detection because you don't have separate versions of the page in the first place. CSS is powerful enough to adapt a page to whatever viewport it happens to be displayed on.
My main gripe about the Wikipedia mobile site is that text search doesn't work on the collapsed sections, and there's no way to expand all sections at once. The simplest thing left to do is the request/navigate to the desktop site and use your browser's find text feature then.
On mobile, they asked for the desktop version, and got redirected to mobile. Does intent not matter there? If you are going to redirect automatically, then redirect back automatically.
You’re getting downvoted, but this is a totally legitimate comment. A sizable minority of people prefer the mobile WP interface and find it cleaner even on a non-mobile device.
m.wikipedia isn’t the default, so it’s different from regular wikipedia.com redirecting a mobile user to the mobile version.
It’s easier for them to go to m.wikipedia.com than to change their user agent, especially if they aren’t that technical.
The point is that the user can go to `m.wikipedia.com` and not do anything else. They don't have to hunt around for a footer option, they don't have to do multiple page loads (which can cost some people money!), they don't have to keep some cookies around or use the same device for their preference to be maintained.
Note also that WP isn't alone in their choice. Facebook, another website with a large non-Western user base, also maintains the same behavior. Go to https://m.facebook.com, you won't be redirected to https://facebook.com .
There are tradeoffs either way, and no matter what WP does, they'll be making some users unhappy. Not all of these users fit the same profile, either. Wikipedia has a global user base, so what's best for most American sites isn't necessarily what's best for Wikipedia. Ultimately, it's not the case that one option is right, and the other is wrong.
I think the right option is to use whatever is best for most users. Most users (by far) will be fine with being served the mobile/desktop website automatically, depending on whether they use a mobile/desktop browser.
Modern browsers all have buttons to toggle user agent preferences in their dev tools. This is a highly technical request and the solution really only needs to be accessible to highly technical users... it's much _much_ more likely that less technical users with strong style preferences will use one of the dozens of pre-configured alternative CSS extensions or just write up their own stylesheet.
I love user customization but this is extremely niche.
No there is no asking for mobile version in the link, the links are the same for both.
You rely on saving the user display preference as a cookie that persists across sessions.
They declare their preference on a device a single time on the site and that's remembered. None of this has anything to do with which URL is being used.
(Not to mention that following a link on a page like "en.m.wikipedia.org" isn't even user intent, it's author intent at most. But usually not even that, because the author just copied the link without even thinking whether it had an "m." in it or not.)
Not a downvoter, but I can understand them. GP's comment assumes that there need to be different versions of the page, while HTML allows degradable experience. Just have the same page and make it work properly everywhere.
You send them what their browser is asking for - if the user wants a different screen format they're tech savvy enough that they can manually edit their user agent request headers. It's actually quite easy and most browsers (if you pop open dev tools) will have an option to switch the render area to a variety of mobile devices and doing so will cause the request headers to be adjusted appropriately.
Since the redesign the expandable categories of the mobile Wikipedia website expand no more than once on Android Firefox beta, so I constantly must reload the page to read new categories.
Fixing this might be a good way to reduce bandwidth.
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.
CSS has come a long way, I would expect that these things would be ease to achieve with just CSS and HTML, for instance: media viewer -> dialog (I remember this being a HTML thing), collapsing sections -> details/summary (?)
There is always going to be a user interaction that is sufficiently complex as to require JS. Arbitrarily limiting to just CSS severely limits what you can do.
It's not arbitrary though. It's a choice to save bandwidth shipping unnecessary javascript rather than making it easier to develop the website. At the scale of Wikipedia that isn't unreasonable.
It's not unnecessary if the feature is something you want?
There's this pattern on HN: people value a feature as having 0 utility and then become annoyed that someone has paid time/performance/money for them. Well duh, if you discount the value of something to 0, it will always be a bad idea. But you're never going to understand why people are paying for it if you write off their values.
At my last job there were countless pieces of UX to make things smoother, more responsive, better controlled by keyboard or voice reader, etc.. that required JS. It was not possible to make our site as good as possible with CSS, and it certainly wasn't worth the tradeoffs of loading a big faster (not that it couldn't have had it's loading time improved--just, cutting JS was a nonstarter).
Fairly certain that's literally the point of simplifying interfaces. Do what you need with what you have. Don't try to shove a racehorse into a VW Beetle.
Surely at the scale of Wikipedia that wouldn’t be a factor ?
considering the dominance of few browsers (chrome , safari on iOS) will most users notice any difference? The first one (with that UA) to the site with a new build will have they cache key warmed up ?
Mediawiki itself is built to support 10-year old phones (which is why the Moto G makes an appearance in the post - it's the official low-end Android benchmark) and older desktop operating systems. https://www.mediawiki.org/wiki/Compatibility#Browsers
Makes sense since the Moto G is also what Lighthouse and a lot of tools driven by it use. So PageSpeed Insights (pagespeed.web.dev), the Lighthouse developer in Chrome tab and even external services like https://totalwebtool.com all generally evaluate mobile performance using it to simulate a slower experience.
The sections could be collapsed by CSS by default without render-blocking JS, and adding a media viewer to random media bits and pieces can definitely wait until later. So time-to-interactivity is unnecessarily hampered here.
Who is using mobile without JS? They are going to have many problems beyond collapses... Likewise, crawlers these days generally run with JS enabled in a browser/VM because so much breaks completely if JS is disabled. This is not a real problem, sorry, NoScript fans.
(Anyway, if you are using CSS + the relevant semantic HTML elements, it can be more accessible, not less, because you are expressing priority and emphasis, so they can skip over collapsed stuff. Although I have my doubts whether screenreaders etc make any good use of it, given that they apparently still do not do basic things like stripping soft hyphens.)
I love details/summary and want them to succeed but current implementations have some issues. A big one is VoiceOver for iOS currently what they are or their state, something that's very straightforward and reliable when making a custom disclosure widget.
"Better interactivity" is subjective. You could argue that faster is better. Expanding and collapsing sections can be achieved faster and with zero JavaScript (which also makes it work on browsers with disabled JS) with a hidden input[type="checkbox"].
Aa for the media viewer, it could be a great exercise to try and make it in a similar manner with input[type="checkbox"] for opening/closing media viewer and input[type="radio"] for switching to prev/next image. This one probably requires browsers to support the `:has` CSS selector.
Also, if you want to further speed up your site, just like you said, the fastest way to speed up the site is to delete JavaScript, get rid of jQuery.
It's just opening and closing detail panes (personal recipie site), there's no reason to put the open/closed state in the url.
But if I can do it with all html, that's better than a function to add / remove a css class and document.onclick = a function to find which recipie you clicked on and adjust the css class.
Probably more useful for a nested menu. The default thing almost works out of the box. You need some css to set a proper cursor and style the clickable text properly.
I assume the author of the blog post just wanted to optimize the current situation, not completely change how these features work (which would most probably be a much more elaborate change).
Same for dropping jQuery - that will probably be a few weeks or months of work in a codebase the size of Wikipedia/Mediawiki.
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.
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.
> 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.
> The better question is: Why use Javascript at all for a static website?
I've been developing websites professionally since 1996. HTML/CSS/JS and SQL.
I am still amazed there is the crowd out there who is "anti-JavaScript". They run NoScript to only allow it in certain places, etc.
It's 2023, a small amount of JavaScript on a page isn't going to hurt anyone and will (hopefully) improve the UX.
For the record, the last site I deployed as a personal project had 0 JavaScript. It was all statically generated HTML on the server in C#/Sqlite that was pushed to Github Pages. So I get it, it's not necessary.
For my little personal site. I'm also the senior lead on an enterprise Angular project.
JavaScript is fine, it's not going anywhere.
And yes, there are way too many React (specifically) websites that don't even need a framework at all, but it's become the go-to. That annoys me too. But some JavaScript in 2023 is fine.
I won't argue that JS doesn't add something to the web experience. My main reason for having JS switched off by default is because JS adds something to the web experience. Namely, a whole load of annoying things like outrageously illegal cookie banners, adverts over the top of the content you're trying to read, auto-play videos on an unrelated topic when you just want to read the article, paywalls, "invitations" to have notifications or sign up to a newsletter, browser fingerprinting, active tracking, and outright malware.
It's a signal to noise ratio thing. There's a small reason to have JS switched on and a large reason to block it. I'd love it if the reason to have JS switched on was even smaller, and that is in fact the recommendation (that JS should enhance an otherwise functional site). I enable JS on sites where I regard the reward as worth it, but most of the time it just isn't, and I don't trust all the rubbish that gets included in the average site.
Wikipedia probably wants to support every user of the internet, which means even very old browsers. You can’t rely on relatively new CSS features when supporting browsers that are 10 years out of date.
The fact they’re still using JQuery, probably for similar compatibility reasons is good evidence of that.
Now there are ways to use polyfills that only load when necessary but just about everything is very difficult at wikipedias scale. We can’t solve their problems from an armchair.
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:
Interestingly I don't have an issue on Firefox (on a Thinkpad), it renders the content immediately, then a second or 2 later it tells me there's a script slowing down the page, i pressed stop and it rendered all of the comments fine. Whatever that script is doing, it's not useful for actually rendering content.
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
(Annoyingly, they don't show any general contract opportunity on their website. Luckily in the Google Play Store they have to supply a support email address. Got it from there.)
What's happening here is the browser did a first paint, and then the javascript started eating up all the CPU. You can scroll because of asynchronous pan/zoom, but when you get to the edge of the rendered region, it asks to render more and it never gets rendered because the page is stuck executing javascript. Recording: https://share.firefox.dev/3C2DE9C
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.
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.
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.
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.
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.
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.
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.
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.
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?!?
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.
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.
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?
Recently, 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.
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!
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.
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.
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?