What is it about?

This interface enables synthetic voices to read plain text. The list of synthetic voices depends on which device you’re using and you can get a list of the available ones by running the getVoices method.

A simple example of this API goes like this:

const utter = new SpeechSynthesisUtterance(myTextField.value);
utter.voice = window.speechSynthesis.getVoices()[0]]; // Picked the 1st available voice, which is also default
window.speechSynthesis.speak(utter);

You can also set other properties of your SpeechSynthesisUtterance instance, like pitch, volume, rate, volume and more.

Conclusion

On this GitHub repo you can see the full implementation of the example above including a selector for all synthetic voices available on your device.

What is it about?

The Speech Recognition API takes a speech input (via microfone) and outputs a list of results, which including the transcript and the confidence level of that translation. It is customisable, letting you define what language you’re using and what words (Grammar) you are interested in.

The confidence level (0-1) changes over time, meaning that as you speak, new results are output replacing the initial guess. When the system is happy with the results, a boolean flag isFinal comes true and it moves on to following parts of the speech.

Using the API to type as you speak

A simple speech to text application could be done with the following code:

const speech = new SpeechRecognition();
speech.lang = ‘en-US’;
speech.onresult = (event) => {
    console.log(event.results[0][0].transcript
}
speech.start();

Grammar

On that example, more options could be applied to the speech variable, like grammar. Grammar must be written using the JSpeech Grammar Format, you can ream about it in the spec document.

Conclusion

With just a few lines we managed to translate speech into text, which then can be used by your application to do as you please. You could, for example, create a voice activated app by limiting the grammar and taking actions depending on which word was said.

A more complete example is available on this GitHub repo, where apart from a simple dictation, I’ve added a voice functionality to search for merchants on a website.

Spec in draft stage

This is a very experimental API, meaning, there is not a lot of documentation available. The WICG (Web Incubator Community Group) spec is very new. At the time of writing this post, the last update was January 3rd 2018. This is just a warning that it is possible that some of the methods and features described in this article might be out of date if you’re reading it later in the year.

What is it about?

The Shape Detection API does what it says on the tin: detect shapes. This is a feature that has been available on a hardware level for a while, but now it surfaced to software.

This means that not only the browser you’re using has to support the API, but the device you’re using must have this capability.

When we talk about shapes, we’re including:

• Faces
• Barcode
• Text

Face Detector

In this article I’m focusing on detecting faces. The FaceDetector constructor accepts an options param where you can set maximum number of faces to detect and whether you want it done using fast mode (prioritise speed over accuracy).

Using the API to detect faces in a picture

This can be achieved by doing the following:

var faceDetector = new FaceDetector();
  faceDetector
    .detect(myImageElement)
    .then(faces => {
       console.log(faces);
    });

In this example, faces is a list of recognized faces. Each face comes with dimensions, coordinates and landmarks. According to the spec, landmarks can be either eyes or mouth, and each landmark object comes with its own coordinates.

A working example can be found in this GitHub repo.

Using the API to detect faces on a live feed

We saw on the previous article that we can easily use MediaStream to capture a camera feed into a video element. Could we use detect shapes of this stream?

Luckily for us, yes! In fact, you can use FaceDetector in any ImageBitmapSource, such as:

• image
• video
• canvas

Here is how:

// #1 Start live feed
navigator
  .mediaDevices
  .getUserMedia({ video: true, audio: false })
  .then(mediaStream => {
    window.myVideoElement.srcObject = mediaStream;
  });

// #2 Captures faces and display them in the browser console
function faceDetectorLoop() {
  faceDetector
    .detect(window.myVideoElement)
    .then((faces) => {
      console.log(faces);
      window.requestAnimationFrame(faceDetectorLoop); // Loops detection
    });
}

// #3 Run
faceDetectorLoop();

We start (1) by opening up the camera feed with video only, then we define a function (2) that will detect faces in an infinite loop using requestAnimationFrame, and finally we start (3) the detection script.

I’ve create a more complete implementation of this idea in this GitHub repo, just click on the main box to start the application.

Conclusion

Shape detection is a very powerful feature that not many people is aware of. Faces, barcodes and text can be detected and used as your application needs.

This first one on the list is: MediaStream Image Capture.

What is it about?

The MediaStream Image Capture APi is an API for capturing images or videos from devices.
It allows multiple camera configuration, so you could control the front and back cameras of your mobile phone, for example.
The API also enables you to configure flash, red-eye reduction, image size (resolution) and more.
Support is currently minimal, to use it with all these feature you’re gonna need Chrome 59+.

Using the API to capture a camera feed

With very little code you can capture a device’s camera feed and use it as a source for a video element. For example:

navigator
  .mediaDevices.getUserMedia({ audio: true, video: true })
  .then(mediaStream => {
    myVideoElement.srcObject = mediaStream;
  });

As you can see, getUserMedia accepts a configuration object with audio and video. They can either have boolean values, telling the API whether you want audio and video, or, an object, if you need to specify more details of how you want the stream to be, for example: video: {width 600, height: 480}.

It’s worth to note that these options will be taken into account depending on the device capabilities. It also defaults to max resolution.

Using the API to take photos

Expanding the example above, you can use the mediaStream track to create an instance of ImageCapture, which will then let you:

• Grab a frame of the video feed, using grapFrame
• Take a photo using the camera’s full capabilities, using takePhoto

And the code would be something like this:

navigator
  .mediaDevices.getUserMedia({ audio: true, video: true })
  .then(mediaStream => {
    const track = mediaStream.getVideoTracks()[0];
    const imageCapture = new ImageCapture(track);
    imageCapture.grabFrame()
      .then(frame => {
        myImageElement.src = frame;
      });
  });

In this example, I’ve used frame as a source for an image tag, but you could also use it to populate a canvas element.

Conclusion

MediaStream combined with Image Capture gives you full control of the camera feeds of a device, with very little code.

I’ve create a more complete example on this GitHub repo https://github.com/jpedroribeiro/FunWithBrowserAPIs/tree/master/imagecapture where I combined these APIs with canvas to create a very basic image manipulation app.

A little background

A while ago I was under the task of review the accessibility standards of the website we were working on. We were used to do this, roughly, twice a year. One engineer would get this ticket, run through the code base for obvious a11y (accessibility) issues, and would submit a pull request with the fixes.

It was a manual job and the requirements would be very loose. An alt tag here, a label there. Nothing more than a few file changes.

It’s valid to point out that, keeping a commercial site up to accessibility standards is not just a nice thing to do to your users but also it is the law.

When you combine repetitive tasks with lack of time you get… automation. We engineers are “lazy” by nature and the idea of automating a tedious task is what makes our job exciting.

Accessibility tests automation = pa11y

When researching about tools I could use for this task I came across Pa11y, which includes not only the command line interface but also a dashboard, webservice and a CI.

In this article I’m focusing on the JavaScript interface that Pa11y provides, letting us write node modules to achieve our automation. I’m also using the version 5.0 beta, in which makes use of headless Chrome in place of PhantomJS.

Installation and first steps

Go to your terminal and make sure your node version is at least 8:
$ node -v
v8.9.4

All good. Now we install pa11y@beta (version 5 will soon leave beta and become the master branch, but in the meantime we need to tag its beta branch):
$ npm install -g pa11y@beta

The -g is optional, it means it’s a global install and makes it available throughout the system. If you need this just for one specific project, feel free to skip it.

With the installation done, you can start using it’s command line interface straightaway:
$ pa11y http://www.google.com

The output will be a list of accessibility issues found on that specific URL.
Now let’s see how we can test multiple pages at the same time and generate reports.

Node.js to the rescue

Pa11y provides a JavaScript interface that lets us write node scripts to create automation. In its most basic form, you can replicate the example above this way:

– In a file named a11y.js, type the following code:

const pa11y = require('pa11y');
pa11y('http://www.google.com/')
  .then((results) => { 
    console.log(results);
  });

– Now run it on your terminal
$ node a11y.js

You will notice that, now, the output is in JSON format. You can change it to CSV, HTML, and other types by passing a configuration object which will see more details later on.

Now let’s try testing multiple pages.

Testing multiple pages

const pa11y = require('pa11y');
const urls = [
    pa11y('http://www.google.com'),
    pa11y('http://www.bbc.co.uk'),
    // Add more pages here as needed
];

Promise.all(urls)
  .then(results => {
    console.log(results[0]); // Results for Google
    console.log(results[1]); // Results for BBC
  });

You can cater for each page individually, or you could just loop through the results array.

The console output can become overwhelming on some sites, so let’s output this results into a readable HTML with the help of reporters.

Reporters

As default, Pa11y comes with JSON, CSV and CLI reporters, but you can add HTML and TSV via additional packages. To enable HTML reporting you need to install another node module:

$ npm install -g pa11y-reporter-html

As before, the -g is optional.
With that done, we need to change our code to the following:

const pa11y = require('pa11y');
const html = require('pa11y-reporter-html');
const urls = [
  pa11y('http://www.google.com'),
  pa11y('http://www.bbc.co.uk')
];

Promise.all(urls)
  .then(results => {
    const googleResults = html.results(results[0]);
    const bbcResults = html.results(results[1]);

    googleResults
      .then(output => {
        console.log(output)
      });

    bbcResults
      .then(output => {
        console.log(output)
      });
  });

If you run that, $ node a11y.js you will get the output of each test in HTML format. With that content in hands, you can always use it to save into a file using fs.createWriteStream.

Conclusion

With a very small script and the help of a great library like Pa11y, accessibility tests can easily be automated.

You can always take a step further and try out their dashboard repository if you like to have a more graphical interface, or use pa11y-ci, for continuous integration.

The Book

Which brings me to this book, Web Performance In Action, by Jeremy L. Wagner. It’s a very thorough collection of information on how to develop fast websites, from the best way to load fonts to techniques that cater for HTTP/2.

With my years of experience in this area I can honestly say that this book is more suitable for intermediate developers. If you are a beginner, you will still find plenty of tutorials to follow and implement without much effort – there are enough links to ready made solutions that will suit most scenarios and use cases. For an advanced user, it might be more of the same.

Some Highlights

Right in the first chapters of the book, the author explain how to use Chrome Dev Tools to properly investigate performance issues. To me this was one of the highlights of the book. It’s very well explained and give the readers a good set of tools to use throughout the book.

Another highlight was the chapter on Service Workers. With the news that Safari is intending to implement this technology, it’s good to see the effort in educating more developers about it.

But most of all, the best chapter in my opinion was the one regarding HTTP/2. It manages to summarize a lot of information in a very easy to read manner. If you never heard of header compression, head-of-line-blocking, or SSL, then this is when you will become familiarized with these terms and understand the improvements this new version of the protocol is bringing the to web.

What is a Progressive Web App?

I kind of like Ada Rose Edwards definition: “A website so good you want to save it on your home screen”.

According to Google, a Progressive Web App is “a website or web application that is reliable, fast and engaging“. Lets break down those 3 pillars:

Reliable: this is mostly about using Service Workers and enabling offline with the use of cache control and managing requests when connection is unstable.

Fast: we all know thats users leave websites if they take too long to load. Google is putting a lot of emphasis on performance these days and I wouldn’t be surprised if it becomes part of its indexing algorithm.

Engaging: basically, the features that make a website look more like a native app – being installable, work on full screen, make use of push notifications.

Being Progressive

There is a focus on the new technologies like Service Workers and the Push API, but being progressive means catering for legacy browsers too. This is the basic idea of progressive enhancement which we know and have been using for ages.

Where to start?

The Google Developer Team has been putting a lot of effort in this field, especially since their Summit last September.

They also have a very deep and beginner friendly portal with loads of articles and tutorials on the subject: https://developers.google.com/web/progressive-web-apps/

Smashing Magazine, as always, has done the same and came up with a great article written by Kevin Farrugia on building PWAs: https://www.smashingmagazine.com/2016/08/a-beginners-guide-to-progressive-web-apps/

My PWA on github

I’ve also being playing around with these concepts and build a very simple page to practise. You can have a look at the source code on github: https://github.com/jpedroribeiro/VoucherWallet

Back to basics

The book says clearly on the cover: “…for novices and power users” so you’ve been warned. I’ve been using WebPageTest, on and off, for years. If you are in the same situation, you might find that 70% of the book is too obvious or just common sense, after all, WebPageTest is a pretty self explanatory tool.

Hidden complexity

With that in mind, the advanced parts of the books are quite good. I was not fully aware of the script capabilities of WPT. The fact that you can give instructions to it and simulate a navigation flow is very powerful. You can simulate a login scenario by doing the following:

navigate http://www.example.com/login
setValue id=u username
setValue ud=p password
submitForm id=login-form
navigate http://www.example.com/profile/username


Other highlights include a full chapter on Continuous Integration, with plenty of examples on how to setup WPT and Jenkins or Travis, or how to setup a private instance of WPT – which I struggled to achieve a couple weeks ago!

Took me a day and a half but I finally managed to get WebPageTest working on AWS

— João Pedro Ribeiro (@jpedroribeiro) August 19, 2016

Conclusion

I definitely recommend reading this book. WPT is such a complex tool that I can guarantee you will find something new about it that you didn’t know before.

Having said that, bear in mind that WebPageTest, like any other open source project, is constantly being updated and you mind find some topics presented on the book are slightly outdated.

no changes added to commit (use "git add" and/or "git commit -a")


Why is this happening?

The short answer is: Git relies on names to know if whether a file is tracked or not.
When you rename a file, Git believes the original file got deleted and suddenly there’s a new file in which it knows nothing about. Hence the untracked status.

Alternative: rename with Git

If you want to avoid this behaviour, you could simply use the native Git command: git mv

$ git mv README.md README-NEW.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

renamed: README.md -> README-NEW.md


Nice and easy.

To understand how performance can affect your website, it’s important to understand common terms and which part they play in a network connection. I’m going to try to explain the differences between bandwidth and latency by using an analogy*. Bear with me.

Road to performance

Picture bandwidth as being the amount of luggage you can fit inside the boot of a car.

Now imagine latency as being the distance between you and your destination, let’s say Brighton.

You can fit (bandwidth) as much as you want as long as it fits the boot of your car. And for this exercise, let’s ignore the differences between cars.

Time for upgrade

You feel it’s time to upgrade your vehicle as you have too many things to carry. You upgrade it to a 5mb/s connection, I mean, a big truck with lots of space to fill (bandwidth).

Everything is great and you can carry all the items you want. But you still need to go to Brighton, and it’s quite far away (latency).

The distance (latency) is still the same, no matter how much you can carry (bandwidth) in one go.

Summing up

This is why streaming movies requires good bandwidth, as you need to carry a lot of data in one go. Websites, on the other hand, perform better when latency is reduced, lots of small files requires lots of roundtrips.

* This is not an original idea. I’ve read similar analogies several times. This is my take on it.