> 1. design a flawed API (it's fine! APIs are hard)
> 2. ship it in the most-used browser, despite objections
> 3. get cross-browser working group to fix the API
> 4. oops, too late, that would break the web
251–260 of 306 posts
> 1. design a flawed API (it's fine! APIs are hard)
> 2. ship it in the most-used browser, despite objections
> 3. get cross-browser working group to fix the API
> 4. oops, too late, that would break the web
I find this tweet about how Google approaches web standards illuminating. To quote: > 1. design a flawed API (it's fine! APIs are hard) > 2. ship it in the most-used browser, despite objections > 3. get cross-browser working group to fix the API > 4. oops, too late, that would break the web https://twitter.com/Rich_Harris/status/1220412711768666114
Earlier quoted context omitted.
I don't know if it's a combination of overreliance on algorithmic rankings + seo or what, but if I search for something like "Panasonic GH5" (something I searched recently), I want to see the top two ranked items as the Panasonic product page, followed by the Wikipedia page. When I run that search on Google in Canada, there is a Panasonic link on the first page (third link), but it's for the US store listing, which h…
I agree that Google search is horrendous but Youtube is actually manageable. If you want decent recommendations you need to curate your viewing history. If you watch some random video and find a lot of annoying related videos showing up in your recommendations then go into your history and delete that one video from the history. Now Youtube will "forget" you watched that video and stop recommending things related to…
There are many good seo companies(true, you have todo your home-work, but that is true for other service providers as well).
The dream is of course to not have to use them and just reply on Google and it's good nature and or algorithms... But is that not saying.. Oh we will just relay on never getting sued and therefor never need a lawyer cause, crimes are bad ?
(Disclaimer: previously worked at Google search) I think some commenters are attributing to Google an ulterior motive, whether ill- or good-intentioned, separate from its core business. But in this case no such motivation is necessary. Basically, Google wants its users to be satisfied - otherwise it will lose to, say, Bing. So it measures user satisfaction - e.g., if a user clicks on a Google result, and immediately…
How is this helping Google not lose to Bing, when the change would equally improve Bing experience (rising tide rises all boats?).
> 22.82 Mbps will reliably download very complex web pages nearly instantaneously. The author may be unaware of how ridiculously huge web pages have gotten. I just loaded Wired.com, scrolled down and let it sit for a few seconds. It downloaded 96.2 MB, requiring over 33 seconds on one of those average connections. On a pay-as-you-go data plan, it would have cost about a dollar just to load that one page. The front pa…
> 22.82 Mbps will reliably download very complex web pages nearly instantaneously. The author may be unaware of how ridiculously huge web pages have gotten. I just loaded Wired.com, scrolled down and let it sit for a few seconds. It downloaded 96.2 MB, requiring over 33 seconds on one of those average connections. On a pay-as-you-go data plan, it would have cost about a dollar just to load that one page. The front pa…
As if I wouldn't notice that casual reading material was causing my cooling fans to spin up.
As if I were multi-tasking so hard, that it couldn't be discernible which dog in the room could take the blame for who just farted.
The wired.com website first showed hints of becoming unusable when their audience participation widget provided by Disqus, for reader/user comments, became this opaque blob of compressed/minified JavaScript. Then they started piling on video. This was back around 2009 or 2010. By 2013, I had mostly washed my hands Conde Nast publications.
Whoops.
Earlier quoted context omitted.
I will not stay on a site with auto-playing video or GIFs. I can't focus on anything with it there.
Or you can scroll down. It's presumably a hero imagespace that serves to explain their product in the fastest way. 300kb for a gif isn't that big for such an inefficient type.
I find this tweet about how Google approaches web standards illuminating. To quote: > 1. design a flawed API (it's fine! APIs are hard) > 2. ship it in the most-used browser, despite objections > 3. get cross-browser working group to fix the API > 4. oops, too late, that would break the web https://twitter.com/Rich_Harris/status/1220412711768666114
>5. Rally a group of developers and PR to bash Webkit as the only one not implementing those flawed API and name it as the new IE.
Earlier quoted context omitted.
>Web developers have utterly squandered all efficiency gains of the last 30 years, and Loading Wired.com with uBlock and no javascript the page comes in below 1.5MB for me, with most functionality seemingly intact (in that the front page looks mostly normal and I can load articles that appear to have their text completely intact). The bulk of that seems to be fonts and images, which are probably unavoidable for a med…
With uBlockO it was 1.5MB for me, without it was 3.8MB, on Firefox, coming from Germany. Which is still pretty ridiculous on both numbers for what's actually visible on the page. Once you scroll, however, things get messy no matter what, because of their "Scott Adkins Answers Martial Arts Training Questions From Twitter" auto-play video they have right now. That ate way another 30MB quickly and the video wasn't even…
1.37 MB / 722.93 KB transferred, Finish: 6.57 s
versus uBlock default
8.62 MB / 4.49 MB transferred, Finish: 28.38 s
Clean setup mostly increase load time:
11.58 MB / 5.79 MB transferred Finish: 1.13 min
^ checked with "Disable Cache".
Not much content delivered for such big HTML file
660.46 / 167.60 KB transferred
because it's mostly inline script:
$$('script').map((s) => s.textContent).join('').length
568681
And fonts.css is inline font:127.70 / 100.15 KB transferred
[0]
uBlock Origin:
* * 1p-script block
* * 3p block
* * 3p-frame block
* * 3p-script block
* * inline-script block
or uMatrix: * * * block
* * frame block
* 1st-party css allow
* 1st-party frame allow
* 1st-party image allow