Re:300ms Faster: Reducing Wikipedia's Total Blocking Time
by manquer on Monday May 29, 2023 @04:06PM
(#36117535)
You should be able to detect user agent and determine capability and send the poly-fills for backward compatibility ?
Re:300ms Faster: Reducing Wikipedia's Total Blocking Time
by pier25 on Monday May 29, 2023 @05:01PM
(#36118077)
Sure, there are many different ways to tackle this.
Re:300ms Faster: Reducing Wikipedia's Total Blocking Time
by ryan_lane on Monday May 29, 2023 @09:23PM
(#36120155)
Then you'd need to shard your cache on user agent, which would lead to considerably worse performance for everyone.
Re:300ms Faster: Reducing Wikipedia's Total Blocking Time
by manquer on Tuesday May 30, 2023 @05:03PM
(#36130768)
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 ?
Re:300ms Faster: Reducing Wikipedia's Total Blocking Time
by ryan_lane on Tuesday May 30, 2023 @08:23PM
(#36133010)
User-agent is way more granular than chrome, safari, firefox, etc. It's not a great shard key.
Re:300ms Faster: Reducing Wikipedia's Total Blocking Time
by paulddraper on Tuesday May 30, 2023 @12:03AM
(#36121006)
And hurt your caching....
All to get rid of a tiny bit of JS.
<dialog> has only been available in Safari for about a year.
https://caniuse.com/dialog
Wikpedia is one of the most popular sites on the internet. It needs to be as compatible as possible so that means using JS.