Tags: for

862

sparkline

Thursday, July 19th, 2018

Fixing these webs - daverupert.com

I’m a fan of fast websites. Your website needs to be fast. Our collective excuses, hand-wringing, and inability to come to terms with the problem-set (There is too much script) and solutions (Use less script) of modern web development is getting tired.

I agree with every word of this.

Sadly, I think the one company with a browser that has marketshare dominance and could exert the kind of pressure required to stop ad tracking and surveillance capitalism is not incentivized to do so.

So the problem is approached from the other end. Blame is piled on authors for slow first-party code. We’re told to use certain mobile publishing frameworks that syndicate to proprietary CDNs to appease the gods of luck and fortune.

Tuesday, July 10th, 2018

When 7 KB Equals 7 MB - Cloud Four

I remember Jason telling me about this weird service worker caching behaviour a little while back. This piece is a great bit of sleuthing in tracking down the root causes of this strange issue, followed up with a sensible solution.

GitHub Is Microsoft’s $7.5 Billion Undo Button - Bloomberg

Paul Ford explains version control in a way that is clear and straightforward, while also being wistful and poetic.

I had idle fantasies about what the world of technology would look like if, instead of files, we were all sharing repositories and managing our lives in git: book projects, code projects, side projects, article drafts, everything. It’s just so damned … safe. I come home, work on something, push the changes back to the master repository, and download it when I get to work. If I needed to collaborate with other people, nothing would need to change. I’d just give them access to my repositories (repos, for short). I imagined myself handing git repos to my kids. “These are yours now. Iteratively add features to them, as I taught you.”

Sunday, July 8th, 2018

Brutalist Web Design

A website is not a magazine, though it might have magazine-like articles. A website is not an application, although you might use it to purchase products or interact with other people. A website is not a database, although it might be driven by one.

Sunday, July 1st, 2018

Tuesday, June 26th, 2018

The Layouts of Tomorrow | Max Böck - Frontend Web Developer

A walkthrough of the process of creating a futuristic interface with CSS (grid and animation).

While this is just one interpretation of what’s possible, I’m sure there are countless other innovative ideas that could be realized using the tools we have today.

Name That Script! by Trent Walton

Trent is about to pop his AEA cherry and give a talk at An Event Apart in Boston. I’m going to attempt to liveblog this:

How many third-party scripts are loading on our web pages these days? How can we objectively measure the value of these (advertising, a/b testing, analytics, etc.) scripts—considering their impact on web performance, user experience, and business goals? We’ve learned to scrutinize content hierarchy, browser support, and page speed as part of the design and development process. Similarly, Trent will share recent experiences and explore ways to evaluate and discuss the inclusion of 3rd-party scripts.

Trent is going to speak about third-party scripts, which is funny, because a year ago, he never would’ve thought he’d be talking about this. But he realised he needed to pay more attention to:

any request made to an external URL.

Or how about this:

A resource included with a web page that the site owner doesn’t explicitly control.

When you include a third-party script, the third party can change the contents of that script.

Here are some uses:

  • advertising,
  • A/B testing,
  • analytics,
  • social media,
  • content delivery networks,
  • customer interaction,
  • comments,
  • tag managers,
  • fonts.

You get data from things like analytics and A/B testing. You get income from ads. You get content from CDNs.

But Trent has concerns. First and foremost, the user experience effects of poor performance. Also, there are the privacy implications.

Why does Trent—a designer—care about third party scripts? Well, over the years, the areas that Trent pays attention to has expanded. He’s progressed from image comps to frontend to performance to accessibility to design systems to the command line and now to third parties. But Trent has no impact on those third-party scripts. That’s very different to all those other areas.

Trent mostly builds prototypes. Those then get handed over for integration. Sometimes that means hooking it up to a CMS. Sometimes it means adding in analytics and ads. It gets really complex when you throw in third-party comments, payment systems, and A/B testing tools. Oftentimes, those third-party scripts can outweigh all the gains made beforehand. It happens with no discussion. And yet we spent half a meeting discussing a border radius value.

Delivering a performant, accessible, responsive, scalable website isn’t enough: I also need to consider the impact of third-party scripts.

Trent has spent the last few months learning about third parties so he can be better equiped to discuss them.

UX, performance and privacy impact

We feel the UX impact every day we browse the web (if we turn off our content blockers). The Food Network site has an intersitial asking you to disable your ad blocker. They promise they won’t spawn any pop-up windows. Trent turned his ad blocker off—the page was now 15 megabytes in size. And to top it off …he got a pop up.

Privacy can harder to perceive. We brush aside cookie notifications. What if the wording was “accept trackers” instead of “accept cookies”?

Remarketing is that experience when you’re browsing for a spatula and then every website you visit serves you ads for spatula. That might seem harmless but allowing access to our browsing history has serious privacy implications.

Web builders are on the front lines. It’s up to us to advocate for data protection and privacy like we do for web standards. Don’t wait to be told.

Categories of third parties

Ghostery categories third-party providers: advertising, comments, customer interaction, essential, site analytics, social media. You can dive into each layer and see the specific third-party services on the page you’re viewing.

Analyse and itemise third-party scripts

We have “view source” for learning web development. For third parties, you need some tool to export the data. HAR files (HTTP ARchive) are JSON files that you can create from most browsers’ network request panel in dev tools. But what do you do with a .har file? The site har.tech has plenty of resources for you. That’s where Trent found the Mac app, Charles. It can open .har files. Best of all, you can export to CSV so you can share spreadsheets of the data.

You can visualise third-party requests with Simon Hearne’s excellent Request Map. It’s quite impactful for delivering a visceral reaction in a meeting—so much more effective than just saying “hey, we have a lot of third parties.” Request Map can also export to CSV.

Know industry averages

Trent wanted to know what was “normal.” He decided to analyse HAR files for Alexa’s top 50 US websites. The result was a massive spreadsheet of third-party providers. There were 213 third-party domains (which is not even the same as the number of requests). There was an average of 22 unique third-party domains per site. The usual suspects were everywhere—Google, Amazon, Facebook, Adobe—but there were many others. You can find an alphabetical index on better.fyi/trackers. Often the lesser-known domains turn out to be owned by the bigger domains.

News sites and shopping sites have the most third-party scripts, unsurprisingly.

Understand benefits

Trent realised he needed to listen and understand why third-party scripts are being included. He found out what tag managers do. They’re funnels that allow you to cram even more third-party scripts onto your website. Trent worried that this was a Pandora’s box. The tag manager interface is easy to access and use. But he was told that it’s more like a way of organising your third-party scripts under one dashboard. But still, if you get too focused on the dashboard, you could lose focus of the impact on load times. So don’t blame the tool: it’s all about how it’s used.

Take action

Establish a centre of excellence. Put standards in place—in a cross-discipline way—to define how third-party scripts are evaluated. For example:

  1. Determine the value to the business.
  2. Avoid redundant scripts and services.
  3. Fit within the established performance budget.
  4. Comply with the organistional privacy policy.

Document those decisions, maybe even in your design system.

Also, include third-party scripts within your prototypes to get a more accurate feel for the performance implications.

On a live site, you can regularly audit third-party scripts on a regular basis. Check to see if any are redundant or if they’re exceeding the performance budget. You can monitor performance with tools like Calibre and Speed Curve to cover the time in between audits.

Make your case

Do competitive analysis. Look at other sites in your sector. It’s a compelling way to make a case for change. WPO Stats is very handy for anecdata.

You can gather comparative data with Web Page Test: you can run a full test, and you can run a test with certain third parties blocked. Use the results to kick off a discussion about the impact of those third parties.

Talk it out

Work to maintain an ongoing discussion with the entire team. As Tim Kadlec says:

Everything should have a value, because everything has a cost.

Saturday, June 23rd, 2018

The Critical Request - Speaker Deck

There are some handy performance tips from Ben in this slide deck.

In this talk we’ll study how browsers determine which requests should be made, in what order, and what prevents the browser from rendering content quickly.

I Don’t Believe in Full-Stack Engineering • Robin Rendle

A good ol’ rant from Robin.

HTML and CSS and JavaScript have always been looked down upon by many engineers for their quirks. When they see a confusing and haphazardly implemented API across browsers (HTML/CSS/JS), I see a swarming, writhing, and constantly improving interface that means we can read stuff that was written fifteen years ago and our browsers can still parse it.

Before jumping to conclusions, read the whole thing. Robin isn’t having a go at people who consider themselves full-stack developers; he’s having a go at the people who are only hiring back-end developers and expecting them to automatically be “full stack.”

Friday, June 22nd, 2018

Offline-Friendly Forms by Max Böck

A clever use of localStorage to stop data from being lost when your visitors are offline.

Wednesday, June 20th, 2018

Don’t Use The Placeholder Attribute — Smashing Magazine

A lot of the issues here are with abuses of the placeholder attribute—using it as a label, using it for additional information, etc.—whereas using it quite literally as a placeholder can be thought of as an enhancement (I almost always preface mine with “e.g.”).

Still, there’s no getting around that terrible colour contrast issue: if the contrast were greater, it would look too much like an actual pre-filled value, and that’s potentially worse.

Monday, June 18th, 2018

The crooked timber of humanity | 1843

Tom Standage—author of the brilliant book The Victorian Internet—relates a tale of how the Chappe optical telegraph was hacked in 19th century France, thereby making it one of the earliest recorded instances of a cyber attack.

Sunday, June 17th, 2018

Telepresence - daverupert.com

Dave is liking the word “telepresence”:

On social media we broadcast our presence and thoughts over radio and wire and I likewise consume your projections as they echo back to me. We commune over TCP/IP.

Just wait until he discovers the related neologism coined by Ted Nelson.

Thursday, June 7th, 2018

Fostering a Web Performance Culture - José M. Pérez

Six steps to kickstart a web performance culture:

  1. Your dev environment is not your user’s environment
  2. It’s better to learn the fundamentals than the library
  3. Get the time to experiment and validate
  4. Educate your colleagues
  5. Share and celebrate success (and failure) stories
  6. Make performance part of your workflow

Tuesday, June 5th, 2018

AMPstinction • Robin Rendle

And so whenever I look at AMP I wonder whether the technology and process itself might be bad (which is arguable) but the efforts might lead to something longer lasting, another movement inspired because of it, despite it, a movement that we can all benefit from.

Monday, June 4th, 2018

Progressive Web Games – Mozilla Hacks – the Web developer blog

I was just talking about how browser-based games are the perfect use-case for service workers. Andrzej Mazur breaks down how that would work:

  • Add to Home screen
  • Offline capabilities
  • Progressive loading

Sunday, June 3rd, 2018

AMPstinction

I’ve come to believe that the goal of any good framework should be to make itself unnecessary.

Brian said it explicitly of his PhoneGap project:

The ultimate purpose of PhoneGap is to cease to exist.

That makes total sense, especially if your code is a polyfill—those solutions are temporary by design. Autoprefixer is another good example of a piece of code that becomes less and less necessary over time.

But I think it’s equally true of any successful framework or library. If the framework becomes popular enough, it will inevitably end up influencing the standards process, thereby becoming dispensible.

jQuery is the classic example of this. There’s very little reason to use jQuery these days because you can accomplish so much with browser-native JavaScript. But the reason why you can accomplish so much without jQuery is because of jQuery. I don’t think we would have querySelector without jQuery. The library proved the need for the feature. The same is true for a whole load of DOM scripting features.

The same process is almost certain to occur with React—it’s a good bet there will be a standardised equivalent to the virtual DOM at some point.

When Google first unveiled AMP, its intentions weren’t clear to me. I hoped that it existed purely to make itself redundant:

As well as publishers creating AMP versions of their pages in order to appease Google, perhaps they will start to ask “Why can’t our regular pages be this fast?” By showing that there is life beyond big bloated invasive web pages, perhaps the AMP project will work as a demo of what the whole web could be.

Alas, as time has passed, that hope shows no signs of being fulfilled. If anything, I’ve noticed publishers using the existence of their AMP pages as a justification for just letting their “regular” pages put on weight.

Worse yet, the messaging from Google around AMP has shifted. Instead of pitching it as a format for creating parallel versions of your web pages, they’re now also extolling the virtues of having your AMP pages be the only version you publish:

In fact, AMP’s evolution has made it a viable solution to build entire websites.

On an episode of the Dev Mode podcast a while back, AMP was a hotly-debated topic. But even those defending AMP were doing so on the understanding that it was more a proof-of-concept than a long-term solution (and also that AMP is just for news stories—something else that Google are keen to change).

But now it’s clear that the Google AMP Project is being marketed more like a framework for the future: a collection of web components that prioritise performance …which is kind of odd, because that’s also what Google’s Polymer project is. The difference being that pages made with Polymer don’t get preferential treatment in Google’s search results. I can’t help but wonder how the Polymer team feels about AMP’s gradual pivot onto their territory.

If the AMP project existed in order to create a web where AMP was no longer needed, I think I could get behind it. But the more it’s positioned as the only viable solution to solving performance, the more uncomfortable I am with it.

Which, by the way, brings me to one of the most pernicious ideas around Google AMP—positioning anyone opposed to it as not caring about web performance. Nothing could be further from the truth. It’s precisely because performance on the web is so important that it deserves a long-term solution, co-created by all of us: not some commandents delivered to us from on-high by one organisation, enforced by preferential treatment by that organisation’s monopoly in search.

It’s the classic logical fallacy:

  1. Performance! Something must be done!
  2. AMP is something.
  3. Now something has been done.

By marketing itself as the only viable solution to the web performance problem, I think the AMP project is doing itself a great disservice. If it positioned itself as an example to be emulated, I would welcome it.

I wish that AMP were being marketed more like a temporary polyfill. And as with any polyfill, I look forward to the day when AMP is no longer necesssary.

I want AMP to become extinct. I genuinely think that the Google AMP team should share that wish.

Thursday, May 31st, 2018

Design Patterns on CodePen

This ever-growing curated collection of interface patterns on CodePen is a reliable source of inspiration.

Monday, May 21st, 2018

Identifying, Auditing, and Discussing Third Parties – CSS Wizardry

Harry describes the process he uses for auditing the effects of third-party scripts. He uses the excellent Request Map which was mentioned multiple times at the Delta V conference.

The focus here is on performance, but these tools are equally useful for shining a light on just how bad the situation is with online surveillance and tracking.

Thursday, May 17th, 2018

I Played Fortnite and Figured Out the Universe - The Atlantic

Robin Sloan smushes the video game Fortnite Battle Royale together with Liu Cixin’s Three Body Problem trilogy and produces a perfect example of game theory, cooperation, and the prisoner’s dilemma.

Based on my experiments in the laboratory of Fortnite, I think Liu Cixin is wrong. Or at least, he’s not entirely right. Fortnite is more Dark Forest theory than not, and maybe that’s true of the universe, too. But sometimes, we have a lever against the vise of game theory, and in this case, it is a single bit of communication. I mean “bit” in the programmer’s sense: a flag with a designated meaning. Nothing more. My heart emote didn’t make Fortnite cuddly and collaborative, but it did allow me to communicate: “Hold up. Let’s do this a different way.”