Slides of Tweakers frontend performance talk

As I nowadays use Mentimeter for my slides, I am able to get to know more about the attendees to my talks. I started my slides with one of the first software engineers, Margaret Hamilton, who worked at NASA at the time. Of all the attendees who voted, 15% recognized her sitting in the Apollo Command Module.

A few statistics on the attendees:

• 78% of the attendees were developer;
• 14% was active within UX / UI;
• 4% was SEO specialist.

I also asked in which languages they worked, or felt the most comfortable. Of all attendees who participated in the interactive slides:

• 26% was working with Angular, React or Vue.js;
• 29% was doing backend development (PHP, Ruby, ASP.net);
• 24% was most comfortable in HTML, CSS and/or jQuery;
• Just one person had no clue what I was asking here at all.

Download the slides

As I used Mentimeter, the slides are only available in PDF format only. Download the 40 slides in this 3MB PDF document.

Harder to build a website than to land on the moon

77% saw it coming, that we need more frontend code to build a website nowadays, than NASA needed for a touchdown on the moon. This is even the case when you would preserve all of NASA's code-commentary (already being 668 kilobytes by itself).

Mobile first

This also gave me the opportunity to explain that mobile first is the wrong description of how we are building websites lately. When mobile usage became more popular, we started implementing a responsive grid within our websites. However, we continued shipping the same amount of resources to the devices of our visitors.

Moreover, by dropping our separa­te mobile version (for example, m.amazon.com), we are giving mobile devices a harder time as the amount of resources we were shipping to desktop devices, now also have to be parsed by mobile devices. We are giving them more work.

As mobile devices have different CPU boundaries than laptops or desktops, we are merely building responsive, instead of mobile first.

Knowing how to improve speed using Lighthouse

Of all respondants, 64% where familiar with PageSpeed Insights and/or Lighthouse analysis tooling. As a big portion of the attendees were backend developers, and others weren't developers at all, I didn't consider this as a strange outcome. But I hoped to trigger the ones who didn't know this tooling as well, by using an ironic example.

I could have used Wix as an example. The average Wix websites uses a lot of JavaScript, thus suffering from bad First Meaningful Paints and thus bad UX / satisfaction / bounce-rate. But I chose to use Hubspot, as their products are more popular amongst (marketing) experts.

Hubspot knows how you should optimize. Well, they try to tell you how to improve your speed, but nowadays, everybody is writing about this, as from UX and SEO perspective this is a hot topic. Even Brian Dean or Neil Patel are talking about improving your score or even getting 100%, but don't succeed in doing so at all, respectivly scoring 19% and 64% on mobile pagespeed/performance.

For the right portion of irony, I added a PageSpeed Insights report of a Hubspot article page to my slidedeck, showing a mobile pagespeed score of 17% and resulting in laughter from the audience.

Speeding things up

I asked the audience what they would expect to speed things up, no questions asked. The question-type was multiple choice, and possible answers (including their votes) were as following:

• 21% for smaller images, for example using webp;
• 12% for lazyload images;
• 7% for defer JS;
• 10% for using gzip/brotli;
• 12% for reduce requests;
• 11% for use CDN;
• 9% for http/2
• 14% for minimize resources;
• 5% for using DNS over HTTPS (to encrypt DNS query).

This resulted in the following chart:

Lazyloading, reducing requests, using a CDN aren't likely to speed things up at all times. And DNS over HTTPS might be good for privacy, but not for security nor performance. Obviously, I will write about these subjects in individual articles later on.

Arcade mode

Implementing a so-called arcade mode, users were able to know or guess the right answers on some questions. The outcomes were as following:

• Before elaborating on render blocking resources, 39% knew that JS and CSS resources are render blocking by default;
• 35% thought HTML itself and images were render blocking as well;
• 14% didn't expect CSS resources to be render blocking (they are render blocking, but only blocking parsing in specific circumstances);
• After elaborating, 58% understood that from First Meaningful Paint perspective, server side rendering is the best approach, compared to client side rendering;
• Only 13% expected me to gain an average rendering improvement of 75% on the HEMA case across different internet speeds, being 4G, fast 3G and slow 3G;
• This was on desktop-only, so imagine the wins on mobile with CPU constraints in mind!