Link tags: scripts

Writing Javascript without a build system

For me, a complicated Javascript build system just doesn’t seem worth it for small 500-line projects – it means giving up being able to easily update the project in the future in exchange for some pretty marginal benefits.

This! Also, this:

I’m writing this because most of the writing I see about JS assumes that you’re using a build system, and it can be hard to navigate for folks like me who write very simple small Javascript projects that don’t require a build system.

Introducing Opportunities & Experiments: Taking the Guesswork out of Performance - WebPageTest Blog

WebPageTest just got even better! Now you can mimic the results of what would’ve previously required actually shipping, like adding third-party scripts, switching from a client-rendered to a server-rendered architecture and other changes that could potentially have a big effect on performance. Now you can run an experiment to get the results before actual implementation.

Ban embed codes

Prompted by my article on third-party code, here’s a recommendation to ditch any embeds on your website.

Remove Trackers - CSS-Tricks

Laura and I are on the same page here.

Test Your Product on a Crappy Laptop - CSS-Tricks

Eric’s response to Chris’s question—“What is one thing people can do to make their website better?”—dovetails nicely with my own answer:

The two real problems here are:

1. Third-party assets, such as the very analytics and CRM packages you use to determine who is using your product and how they go about it. There’s no real control over the quality or amount of code they add to your site, and setting up the logic to block them loading their own third-party resources is difficult to do.
2. The people who tell you to add these third-party assets. These people typically aren’t aware of the performance issues caused by the ask, or don’t care because it’s not part of the results they’re judged by.

Ain’t No Party Like a Third Party - CSS-Tricks

Chris is doing another end-of-year roundup. This time the prompt is “What is one thing people can do to make their website bettter?”

This is my response.

I’d like to tell you something not to do to make your website better. Don’t add any third-party scripts to your site.

Is Safari the new Internet Explorer?

The transcript from the latest episode of the HTTP 203 podcast is well worth perusing.

• Internet Explorer halted development, no innovation. Would you say Safari is the new IE?
• There was loads of stuff missing. Is Safari the new IE?
• My early career was built on knowing the bugs in IE6 and how to solve them. Is Safari the new IE?
• Internet Explorer 6, it had a really slow JavaScript engine, performance was bad in that browser. Is Safari the new IE?
• Internet Explorer had a fairly cavalier attitude towards web standards. Is Safari the new IE?
• Back in the day that we had almost no communication whatsoever. Is Safari the new IE?
• Slow-release cycle. Is Safari the new IE?

Phantom Analyzer

A simple, real-time website scanner to see what invisible creepers are lurking in the shadows and collecting information about you.

Looks good for adactio.com, thesession.org, and huffduffer.com …but clearleft.com is letting the side down.

Van11y: Accessibility and Vanilla JavaScript - ES2015

Van11y (for Vanilla-Accessibility) is a collection of accessible scripts for rich interfaces elements, built using progressive enhancement and customisable.

Blacklight – The Markup

This is an excellent new tool for showing exactly what kind of tracking a site is doing:

Who is peeking over your shoulder while you work, watch videos, learn, explore, and shop on the internet? Enter the address of any website, and Blacklight will scan it and reveal the specific user-tracking technologies on the site—and who’s getting your data. You may be surprised at what you learn.

Best of all, you can inspect the raw data and analyse the methodology.

There are some accompanying explainers:

• I Scanned the Websites I Visit with Blacklight, and It’s Horrifying. Now What?
• How We Built a Real-time Privacy Inspector
• The High Privacy Cost of a “Free” Website

Scripts: async, defer

I’m constantly forgetting the difference between the async attribute and the defer attribute on script elements—this is a handy explanation.

Move Fast & Don’t Break Things | Filament Group, Inc.

This is the transcript of a brilliant presentation by Scott—read the whole thing! It starts with a much-needed history lesson that gets to where we are now with the dismal state of performance on the web, and then gives a whole truckload of handy tips and tricks for improving performance when it comes to styles, scripts, images, fonts, and just about everything on the front end.

Essential!

What would happen if we allowed blocking 3rd-Party JavaScript as an option?

This would be a fascinating experiment to run in Firefox nightly! This is in response to that post I wrote about third-party scripts.

(It’s fascinating to see how different this response is to the responses from people working at Google.)

5G Will Definitely Make the Web Slower, Maybe | Filament Group, Inc.

The Jevons Paradox in action:

Faster networks should fix our performance problems, but so far, they have had an interesting if unintentional impact on the web. This is because historically, faster network speed has enabled developers to deliver more code to users—in particular, more JavaScript code.

And because it’s JavaScript we’re talking about:

Even if folks are on a new fast network, they’re very likely choking on the code we’re sending, rendering the potential speed improvements of 5G moot.

The longer I spend in this field, the more convinced I am that web performance is not a technical problem; it’s a people problem.

Is client side A/B testing always a bad idea in your experience? · Issue #53 · csswizardry/ama

Harry enumerates the reasons why client-side A/B testing is terrible:

• It typically blocks rendering.
• Providers are almost always off-site.
• It happens on every page load.
• No user-benefitting reuse.
• They likely skip any governance process.

While your engineers are subject to linting, code-reviews, tests, auditors, and more, your marketing team have free rein of the front-end.

Note that the problem here is not A/B testing per se, it’s client-side A/B testing. For some reason, we seem to have collectively decided that A/B testing—like analytics—is something we should offload to the JavaScript parser in the user’s browser.

Test the impact of ads and third party scripts

This is a very useful new feature in Calibre, the performance monitoring tool. Now you can get data about just how much third-party scripts are affecting your site’s performance:

The best way of circumventing fear and anxiety around third party script performance is to capture metrics that clearly articulate their performance impact.

Hello, Goodbye - Browser Extension

A handy browser extension for Chrome and Firefox:

“Hello, Goodbye” blocks every chat or helpdesk pop up in your browser.

194028 – Add limits to the amount of JavaScript that can be loaded by a website

Now this is a feature request I can get behind!

A user must provide permission to enable geolocation, or notifications, or camera access, so why not also require permission for megabytes of JavaScript that will block the main thread?

Without limits, there is no incentive for a JavaScript developer to keep their codebase small and dependencies minimal. It’s easy to add another framework, and that framework adds another framework, and the next thing you know you’re loading tens of megabytes of data just to display a couple hundred kilobytes of content.

I’m serious about this. It’s is an excellent proposal for WebKit, similar to the never-slow mode proposed by Alex for Chromium.

The costs and benefits of tracking scripts – business vs. user // Sebastian Greger

I am having a hard time seeing the business benefits weighing in more than the user cost (at least for those many organisations out there who rarely ever put that data to proper use). After all, keeping the costs low for the user should be in the core interest of the business as well.

On using tracking scripts | justmarkup

Weighing up the pros and cons of adding tracking scripts to a website, from a business perspective and from a user perspective.

When looking at the costs versus the benefits it is hard to believe that almost every website is using tracking scripts.

The next time, you implement a tracking script it would be great if you could rethink it and ask yourself if it is really worth it.