PostHole
Compose Login
You are browsing eu.zone1 in read-only mode. Log in to participate.
rss-bridge 2019-05-30T11:04:52+00:00

An Exercise Program for the Fat Web

When I wrote about App-pocalypse Now in 2014, I implied the future still belonged to the web. And it does. But it’s also true that the web has changed a lot in the last 10 years, much less the last 20 or 30.Websites have gotten


An Exercise Program for the Fat Web

Jeff Atwood

30 May 2019
— 6 min read
— Comments

When I wrote about App-pocalypse Now in 2014, I implied the future still belonged to the web. And it does. But it’s also true that the web has changed a lot in the last 10 years, much less the last 20 or 30.

Websites have gotten a lot… fatter.

While I think it’s irrational to pine for the bad old days of HTML 1.0 websites, there are some legitimate concerns here. The best summary is Maciej Cegłowski’s, The Website Obesity Crisis:

To channel a famous motivational speaker, I could go out there tonight, with the materials you’ve got, and rewrite the sites I showed you at the start of this talk to make them load in under a second. In two hours.

Can you? Can you?

Of course you can! It’s not hard! We knew how to make small websites in 2002. It’s not like the secret has been lost to history, like Greek fire or Damascus steel.

But we face pressure to make these sites bloated.

I bet if you went to a client and presented a 200 kilobyte site template, you’d be fired. Even if it looked great and somehow included all the tracking and ads and social media crap they insisted on putting in. It’s just so far out of the realm of the imaginable at this point.

The whole article is essential; you should stop what you’re doing and read it now if you haven’t already. But if you don’t have time, here’s the key point:

This is a screenshot from an NPR article discussing the rising use of ad blockers. The page is 12 megabytes in size in a stock web browser. The same article with basic ad blocking turned on is 1 megabyte.

That’s right, through the simple act of running an ad blocker, you’ve reduced that website’s payload by twelve times. Twelve! That’s like the most effective exercise program ever!

Even the traditional advice to keep websites lean and mean for mobile no longer applies because new mobile devices, at least on the Apple side, are faster than most existing desktops and laptops.

*[The iPhone XS is faster than an iMac Pro on the Speedometer 2.0 JavaScript benchmark. It's the fastest device I've ever tested. Insane 45% jump over the iPhone8/X chip. How does Apple do it?!]*

Despite claims to the contrary, the bad guy isn’t web bloat, per se. The bad guy is advertising. Unlimited, unfettered ad “tech” has creeped into everything and subsumed the web.

Personally I don’t even want to run ad blockers, and I didn’t for a long time – but it’s increasingly difficult to avoid running an ad blocker unless you want a clunky, substandard web experience. There’s a reason the most popular browser plugins are inevitably ad blockers, isn’t there? Just ask Google:

So it’s all the more surprising to learn that Google is suddenly clamping down hard on adblockers in Chrome. Here’s what the author of uBlock Origin, an ad blocking plugin for Chrome, has to say about today’s announcement:

In order for Google Chrome to reach its current user base, it had to support content blockers – these are the top most popular extensions for any browser. Google strategy has been to find the optimal point between the two goals of growing the user base of Google Chrome and preventing content blockers from harming its business.

The blocking ability of the webRequest API caused Google to yield control of content blocking to content blockers. Now that Google Chrome is the dominant browser, it is in a better position to shift the optimal point between the two goals which benefits Google’s primary business.

The deprecation of the blocking ability of the webRequest API is to gain back this control, and to further instrument and report how web pages are filtered, since the exact filters which are applied to web pages are useful information which will be collectable by Google Chrome.

The ad blockers themselves are arguably just as complicit. Eye/o GmbH owns AdBlock and uBlock, employs 150 people, and in 2016 they had 50 million euros in revenue, of which about 50% was profit. Google’s paid “Acceptable Ads” program is a way to funnel money into adblockers to, uh, encourage them to display certain ads. With money. Lots… and lots… of money. 🤑

We simultaneously have a very real web obesity crisis, and a looming crackdown on ad blockers, seemingly the only viable weight loss program for websites. What’s a poor web citizen to do? Well, there is one thing you can do to escape the need for browser-based adblockers, at least on your home network. Install and configure Pi-Hole.

I’ve talked about the amazing Raspberry Pi before in the context of classic game emulation, but this is another brilliant use for a Pi.

Here’s why it’s so cool. If you disable the DHCP server on your router, and let the Pi-Hole become your primary DHCP server, you get automatic DNS based blocking of ads for every single device on your network. It’s kind of scary how powerful DNS can be, isn’t it?

My Pi-Hole took me about 1 hour to set up, start to finish. All you need is

I do recommend the 3b+ because it has native gigabit ethernet and a bit more muscle. But literally any Raspberry Pi you can find laying around will work, though I’d strongly advise you to pick one with a wired ethernet port since it’ll be your DNS server.

I’m not going to write a whole Pi-Hole installation guide, because there are lots of great ones out there already. It’s not difficult, and there’s a slick web GUI waiting for you once you complete initial setup. For your initial testing, pick any IP address you like on your network that won’t conflict with anything active. Once you’re happy with the basic setup and web interface:

  • Turn OFF your router’s DHCP server – existing leases will continue to work, so nothing will be immediately broken.
  • Turn ON the pi-hole DHCP server, in the web GUI.

Once you do this, all your network devices will start to grab their DHCP leases from your Pi-Hole, which will also tell them to route all their DNS requests through the Pi-Hole, and that’s when the ✨ magic ✨ happens!

All those DNS requests from all the devices on your network will be checked against the ad blacklists; anything matching is quickly and silently discarded before it ever reaches your browser.

(The Pi-Hole also acts as a caching DNS server, so repeated DNS requests will be serviced rapidly from your local network, too.)

If you’re worried about stability or reliability, you can easily add a cheap battery backed USB plug, or even a second backup Pi-Hole as your secondary DNS provider if you prefer belt and suspenders protection. Switching back to plain boring old vanilla DNS is as easy as unplugging the Pi and flicking the DHCP server setting in your router back on.

[...]


Original source

Reply