DEV Community: Filip Rakowski

Investing in Developer Experience Could Be The Best Growth Hack for Your Business

Filip Rakowski — Wed, 19 Apr 2023 11:17:52 +0000

It was November 2017 when we pushed the very first version of Vue Storefront to GitHub. At that time, there were only two of us working on it after hours. One year later, we had been invited to almost every Magento event and podcast. Vue Storefront had almost 100 agencies around the world implementing it, and more than 4000 people were on its Slack. New live stores were popping up every week, and SAP had even approached us, asking for help to build its own Enterprise product.

As crazy as it sounded, this was a real story. What was our secret ingredient to success? Developer Experience. Despite having no investment or marketing budget, we managed to leverage Developer Experience to our advantage. The mechanisms that led to our success can be used by other IT companies, both building and consuming developer tools to greatly increase their chances of success.

Developer Experience is User Experience

For a company building tools for developers, developers are their users, so Developer Experience is just User Experience. It’s not a secret that improving the experience of your users can be a great way to increase revenue. A survey by UserTesting found that 86% of buyers are willing to pay more for a better customer experience.

Some companies, like Amazon, have become completely obsessed with their customers and their experience. It works the same way with developers - we have companies like Vercel, Netlify that are known from their obsession with great DX! By the way - we're obsessed about it in Vue Storefront too!

Developer Experience drives web tools adoption

Developers are constantly looking for new and better tools that will allow them to perform tasks more efficiently or decrease the chances of failure.

The reason we became so successful with Vue Storefront was quite simple - we identified a pain point of a huge amount of developers and shipped something that improved their experience. They lifted it up because our success was in their interest.

Developers often look for tools that are easy to use, provide the required functionality, have good documentation, and have good community support. If a tool lacks these qualities, developers are more likely to switch to an alternative tool that provides a better experience.

In our case, we gave Magento 2 frontend developers a way to use a modern frontend framework like Vue, and decouple their work from the PHP world. It was in their interest to advocate for Vue Storefront and convince the companies they worked for to use it. This way, they could learn a new, exciting technology that is much more enjoyable and efficient to work with than what they were used to.

Let’s take another example from the web dev tooling courtyard. Webpack, a tool that was fueling almost all modern JavaScript projects with 6 000 000 daily downloads was almost completely replaced by Vite in most of the modern frameworks and starters last year. Of course, Webpack won’t die any time soon, with its massive adoption, but Vite is now a go-to for the new projects on Vue, React and Nuxt.

Speaking of which - Nuxt and Vue also became a market standards because of their amazing DX. They had no marketing budget, but happy developers advocating for their products were all they needed to get where they are now.

I know what you’re thinking right now - is it really worth investing time in a migration just to make my developers happier? As a leader, or a business owner, should I even listen to their whims?

Developer Experience improves the efficiency of your team

Using a developer tool with great developer experience is like driving on a well-maintained highway, where you can smoothly and efficiently cruise at high speeds towards your destination.

On the other hand, using a tool with a poor developer experience is like driving on a bumpy and pothole-filled road, where you constantly have to slow down and maneuver around obstacles, causing delays and frustration. Ultimately, the former allows you to get to your destination faster and with less stress, while the latter can slow you down and impede your progress.

Developers spend most of their time coding, designing, and testing software applications. The experience they have while doing these tasks can have a significant impact on their performance. Good developer experience can make them more productive and more efficient, leading to timely delivery of high-quality software.

While a bad developer experience can lead to inefficiencies, delays, and ultimately, higher costs. This can also impact the end-user experience, leading to unhappy customers, bad reviews, and lost business opportunities.

A report from McKinsey shows that companies prioritizing developer velocity have four to five times the revenue growth of their counterparts.

It’s not always worth migrating to the next big thing

Investing in tools that can provide better developer experience is an excellent decision, especially for large teams. However, it's essential to consider that not all migrations are worthwhile. If your current tool is already delivering good developer experience, then it's highly unlikely that migrating to a new tool will bring significant benefits that justify the costs.

For example, people migrated from webpack to Vite in large numbers because webpack was incredibly slow in larger projects, leading to a significant waste of time.

However, Vite has addressed this problem by being fast enough, so replacing Vite with an even faster build tool may not provide the same benefits as migrating from webpack to Vite.

Therefore, it's crucial to make a well-informed decision before making any changes to your current toolset.

Developer Experience attracts talent

Good developer experience can also impact employee retention and recruitment. Developers want to work for companies that provide the best tools, technologies, and working environments. Often they switch jobs just to be able to work with the new technology they’re excited about.

According to a survey by Hired, a job search platform for tech talent, outdated technology is one of the top reasons why developers look for new jobs. In their 2021 State of Software Engineers report, they found that 39% of software engineers surveyed cited outdated technology as a reason for leaving their job, making it the second most common reason behind compensation.

By providing good developer experience, businesses can retain and attract top talent, leading to better results and growth opportunities.

Summary

Investing in Developer Experience (DX) can be a game-changer for IT companies building and consuming developer tools. *DX is simply User Experience (UX) for developers, and improving it can increase revenue, drive adoption, and increase team efficiency. *

However, not all migrations are worthwhile, and it's crucial to make a well-informed decision before making any changes to your current toolset. Good DX can also impact employee retention and recruitment, leading to better results and growth opportunities. Overall, businesses should consider DX as a growth hack that can drive success and take them to the next level.

I share how we build best Developer Experience on the market in Vue Storefront every month in my newsletter! Follow me on Twitter or Linkedin to stay in the loop and learn something new!

How to deal with caching and dynamic content in Nuxt?

Filip Rakowski — Wed, 05 Oct 2022 13:10:19 +0000

The cache is one of the most powerful weapons when you want to make your web application fast. Delivering static, pre-rendered pages from the closest location can result in a great performance, but setting it up on the server without making your frontend application ready to be cached can lead to unpleasant outcomes. In the best-case scenario, you will annoy your users by breaking the app. Worst-case scenario, you will violate GDPR rules. This is certainly a situation that none of us want to experience! Don't worry - from this article, you will learn everything you need to know to make your Server-Side or Statically generated Single Page Applications ready to be cached (and hopefully distributed through a CDN)!

⚠️ Side Note: I use Nuxt.js in code examples, but the concepts and solutions are not tied to any framework.

We cache HTML templates to improve performance.

Let's learn some theory first and familiarize ourselves with the concept of full-page caching. I found a very good one on Branch CMS documentation:

"Full page cache" means that the entire HTML output for the page will be cached. Subsequent requests for the page will return the cached HTML instead of trying to process and re-build the page, thus returning a response to the browser much faster

When you open a Server-Side Rendered application, the JavaScript code first runs on the server to generate the HTML file containing all your components and data rendered. This static file is then sent to the browser. Single-Page Application framework like Vue takes control over it and makes it dynamic. This process is called hydration. At this stage your application is fully interactive.

Generating the static HTML file on the server can take a few seconds. A few seconds when your user sees a blank screen and potentially leaves your website. According to Google's study, 1-3 seconds of load time increases the bounce rate probability by 32%!

To deal with this significant performance downside of Server-Side Rendering, developers started caching the first generated response and sending it to others. Thanks to that, we perform the time-consuming rendering step only once and send its outcome immediately to all users requesting it.

The cached template has to be generic.

When we cache an HTML page generated by a SPA SSR framework like Nuxt.js it contains both the generated HTML and application state as inlined JavaScript object after the server-side code execution.

Because of that you need to ensure that there is no session-specific content in both template and application state after server-side code execution. Otherwise, it will be cached and served to all users.

A session-specific content contains data and markup that can be different depending on a user or device - for example: displayed user or device name, conditional rendering statement for specific devices etc.

If you don’t remove session-specific content from the cached template, everyone will see a page with the data of the first user.

Execute session-specific content in the browser

Our applications are rarely entirely generic in the real world, though. There is nothing wrong with it - almost every website has some content that is dynamic and depends on a current user session.

it’s important to make the dynamic content rendering happen in an environment that is isolated for each user like their browser.

This way the generic content, generated on the server is distributed immediately to all of your users and then, in their browsers, parts that make the experience tailored specifically for them are injected.

How to deal with session-specific templates

The first thing that comes to mind when thinking about session-specific content is the one of the currently authenticated user. We obviously don't want other users to receive a page that is filled with someone else's data.

Let’s see an example of excluding session-specific parts of AppHeader component from rendering on the server.

In Nuxt.js you can skip the server-side rendering of components wrapped with a built-in ClientOnly component.



<!-- components/AppHeader.vue -->
<header>
  <AppLogo />
  <!-- Keep the elements that are session-specific as client-only -->
  <ClientOnly>
    <button v-if="!isLoggedIn" @click="LogIn()">Log in</button>
    <button v-else @click="logOut()" >Log out</butt>
    <AppCart />
    <AppWishlist />
  </ClientOnly>
</header>

The server-side-rendered code of the above component will look more or less like this:



<header>
  <img src="./assets/logo.png">
</header>

Then in the browser, the rest of the elements are added dynamically.

Improving the user experience with loading indicators and placeholders

Usually, the hydration happens in milliseconds, but on some devices, it could take even more than 10 seconds. Seeing empty elements on the template can be misleading and deliver a bad user experience. Users can feel that the website is broken, or they could miss some important elements that are loaded later. We should let them know that some elements are not there yet.

The most common and effective technique of indicating yet-to-be-loaded content are skeletons.

Skeleton screens **are blank pages that are progressively populated with content, such as text and images, as they become available.* (from ***uxdesign.cc)

Skeletons are much better option than spinners because they give user a hint of what content they can expect.

Let's take a look at a practical example of Linkedin. When you enter the page, not everything is loaded yet. You immediately receive a cached skeleton home screen, and the data is loaded progressively in the browser:

The Nuxt.js ClientOnly component has a placeholder slot we can use to display a skeleton for the content that will gradually load on the client side. I used SfSkeleton component example from Storefront UI - eCommerce UI library we’ve built in Vue Storefront for our users.



<!-- components/AppHeader.vue -->
<header>
  <AppLogo />
  <!-- Keep the elements that are session-specific as client-only -->
  <ClientOnly>
  <!-- Display a placeholder until the page is hydrated -->
    <template #placeholder>
      <SfSkeleton type="paragraph" />
    </template>
    <button v-if="!isLoggedIn" @click="LogIn()">Log in</button>
    <button v-else @click="logOut()" >Log out</butt>
    <AppCart />
    <AppWishlist />
  </ClientOnly>
</header>

💡 Sometimes it is better to just use the generic state of the component as placeholder

What about the data?

Until now we talked only about the session-specific templates but what about data fetched inside components?

Most of the SSR frameworks like Nuxt or Next send the server-side state at the bottom of index.html file that comes with the rendered HTML, so you don’t have to fetch the data twice - on the server and then on the client.

If you inspect your Nuxt or Next SSR response, you will see a similar piece of code injected at the end of the body tag:



<script>window.__NUXT__={layout:"default",data:[{},{posts:[{userId:1,id:1,title:"sunt aut facere repellat provident occaecati excepturi optio reprehenderit",body:"quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto"},{userId:1,id:2,title:"qui est esse",body:"est rerum tempore vitae\nsequi sint nihil reprehenderit dolor beatae ea dolores neque\nfugiat blanditiis voluptate porro vel nihil molestiae ut reiciendis\nqui aperiam non debitis possimus qui neque nisi nulla"},{userId:1,id:3,title:"ea molestias quasi exercitationem repellat qui ipsa sit aut",body:"et iusto sed quo iure\nvoluptatem occaecati omnis eligendi aut [...]"}]}],error:null,serverRendered:!0}</script>

Because of that, we have to ensure that no session-specific data is in the cached HTML just like we did with the templates.

The data can be fetched from two places:

Inside the component

When the data is fetched inside the component, the case is simple. If the whole component is wrapped with ClientOnly like in the example above the execution of the component code is completely skipped on the server, so the data is fetched for the first time when its executed in the browser.



<!-- components/AppHeader.vue -->
<header>
  <AppLogo />
    <!-- None of the code from components inside ClientOny will execute on the server -->
  <ClientOnly>
    <!-- ... -->
    <AppCart :items="user.cart.items" />
  </ClientOnly>
</header>




<!-- components/AppCart.vue -->
<template>
  <!-- cart template -->
</template>

<script setup>
import { ref } from 'vue'

const cart = ref({})

async function fetchCart () {
  const res = await fetch('...')
  return res.json()
}

cart.value = await fetchCart()
</script>

If you’re REST APIs and have multiple requests on your page, executing the fetching logic inside the components is best. It’s much harder to miss the session-specific data if it’s not all around your app.

In the parent component

If you follow a smart/dumb components pattern aka. presentational/container (explained well by Dan Abramov here, and no longer a go-to approach since the introduction of React Hooks/Composition API) and fetch all the logic in the parent component, you have to take care of the session-specific data separately in the parent component.



<!-- components/AppHeader.vue -->

<AppHeader>

  <AppLogo />

    <!-- None of the code from components inside ClientOny will execute on the server -->

  <ClientOnly>

    <!-- ... -->

    <AppCart :items="user.cart.items" />

  </ClientOnly>

</AppHeader>

<script>

import { ref } from 'vue'

const cart = ref({})

async function fetchCart () {

  const res = await fetch('...')

  return res.json()

}

// onMounted runs only in the browser (client context)

onMounted(() => {

 cart.value = await fetchCart()

})

// ...other logic

</script>

Summary

To make your app cacheable and CDN-ready you have to avoid session-specific content in the cached content rendered on the server.

You have to render your application in a few steps - a generic one that renders most of the page and a session-specific one that injects dynamic parts.

Liked the article? Follow me on Twitter to get daily tips about web development.

Everything you need to know about Web Performance (in 5 Minutes)

Filip Rakowski — Thu, 23 Jun 2022 15:00:53 +0000

I hear a lot of people saying that web performance is hard. Honestly, I don't think that's true. It could feel complex and intimidating at first glance because there is a lot of domain-specific naming, metrics, etc but to build a fast website you don't need to know them. You only need a basic understanding of what influences the speed of your website the most and make sure you have it under control. Believe me or not, you can learn this in about 5 minutes. Let's see if I'm right!

What influences your app performance?

Let's start with identifying all the aspects that influence your app performance. I find this mental model most useful when thinking about web performance:

There are essentially three "steps" that sum up the overall loading performance of your app

Server-side execution - First the HTML document has to be generated on the server. In some cases, this step costs us nothing because it's already generated (static sites).
Network - The generated HTML document has to travel through wires and routers to arrive in the user's browser.
Client-side execution - The document needs to be parsed, and dependencies (CSS, JavaScript) have to be downloaded and executed. Once it's all done our page is fully loaded.

Optimizing server-side execution

If you're building a SPA (Single Page Application) there is a high chance you're also adopting SSR (Server-Side Rendering). In that case, the same code will run both on the server and the client sides.

The best code is the one that never has to run so you should first consider SSG (Static Site Generation). If it's not an option and you're sticking to SSR, make heavy use of full-page caching and distribute cached content through CDN.

Some pages will have to be generated on the server during runtime and just cannot be cached. Of those, make sure to fetch only fast, essential data on the server and make less important, and slower API calls on the client-side. This way you will significantly improve your Time to First Byte.

Optimizing Network

Optimizing the networking part boils down to 4 main rules:

Ship the smallest possible assets. The bigger they are, the longer it takes to download them.
Avoid chaining network requests (making one request depending on another) and try to download them in parallel.Avoid using multiple external domains in the critical path. Establishing a connection with all of them will take more time than downloading everything from one source.
Cache static assets (HTML, CSS JS) through a Service Worker.

Source: https://developer.chrome.com/blog/app-shell/

If you take care of that there is a much smaller chance you will run into performance bottlenecks on the network part.

Optimizing client execution

This is where we, frontend developers, have the most power and where we also make a lot of mistakes! From my experience, 90% of frontend performance bottlenecks are around rendering time (that one can be easily solved with cached SSR and SSG output) and interactivity (that one can be solved by reducing amount of JavaScript in so-called critical rendering path through code splitting, lazy loading and being cautious with adding new libs to the clients).

The thing that usually leads to the biggest number of performance bottlenecks is JavaScript. In SPAs it's very easy to lose control over your JS bundle size. Here's what you can do to prevent it from growing into a Brontosaurus:

If you're using SSR/SSG it means that many of your components are already rendered on the server and they don't need interactivity on the frontend. You can drastically increase the speed of your hydration by hydrating only the components that need to be interactive and only when they need to become ones. You can use Astro.build or vue-lazy-hydration plugin if you're using Nuxt to control the hydration process and exclude the components that don't need it.
Split your app into multiple lazy-loaded chunks (start with routes!). Every sidebar, modal or expensive widget can be loaded lazily on interaction.
Your website could seem fast when you're building it but once the marketing team puts all the analytics there I guarantee it will slow down. You can use web workers to run the non-critical code asynchronously. I strongly recommend Partytown - it's integrated with all major frameworks from the Vue ecosystem. Source: https://partytown.builder.io/

Optimizing images

Surprising amount of developers does a rookie mistake of not optimizing their images. To make sure images aren't the bottleneck simply adjust their size to the screen and use next-gen formats like webp. You can automatically resize and optimize your images using and/or Cloudinary. Also, load your below-the-fold images last. You can use native <img loading="lazy" /> property for that.

Measuring performance

If you can't measure – you can't say if there was any improvement. Measuring your performance constantly is as important as optimizing it regularly.

The performance metrics that have the biggest impact on user experience are called Core Web Vitals (CVV):

Largest Contentful Paint (LCP): measures loading performance.
First Input Delay (FID): measures interactivity.
Cumulative Layout Shift (CLS): measures visual stability.

Source: https://web.dev/vitals/?gclid=Cj0KCQjw2MWVBhCQARIsAIjbwoN567MYvlge9gXipQmZGvQG-9WZddKuQXRto_NiuIaHaTXStrjNFx0aApY9EALw_wcB

If you want to quickly check how your website is performing, try Page Speed Insights. It will run a Lighthouse audit on your website using the closest Google Data Center.

You should also incorporate performance checks into your CI/CD pipeline. Use Lighthouse CI to run a synthetic Lighthouse test on each PR (PS: Learn why you shouldn't believe the Lighthouse score alone) and bundlesize package to raise alerts if your bundle size exceeds a certain threshold. For more nuanced data you should use WebPageTest.

Believe me or not but that's all you need to know to have your performance under control!

If you liked the article and want to learn more about web performance through articles and tips you can follow Vue Storefront profile here or follow me on Twitter

You’re probably using Lighthouse wrong: How we got tricked by a single magic number

Filip Rakowski — Wed, 13 Apr 2022 11:59:51 +0000

These days web performance is one of the most important things everyone wants to optimize on their apps, and it's clear to everyone how dramatic the impact of a poorly optimized website is on business. Yet we as an industry completely fail in recognizing its complexity and widely misuse the most common tool to measure it — Google Lighthouse. If you’re one of those people thinking that good performance equals a good Lighthouse score, you’ve also fallen into this trap and this article is for you.

You may not believe me, but five years ago, when we were writing the first lines of code for Vue Storefront, the topic of frontend performance was almost non-existent in the web-dev space.

At that time, JavaScript SPA frameworks were gaining huge traction. AngularJS and React were already well-established tools gaining in popularity every day. Evan You just released the second major version of Vue.js that only a few years later became one of the three most popular SPA frameworks in the world.

At that time almost no one cared how fast the websites built with those tools were. The world was simple and if you wanted to dig into frontend performance topics, you ended up on websites with retro designs made by old computer geeks. The mainstream didn’t care, but this was about to change very soon because of the little friends in our pockets.

As long as we were using PCs and laptops as primary machines to consume the web no one seemed to be concerned with the growing size of websites. Both CPU and internet bandwidth were progressing faster than websites were growing their size.

This all changed when mobile started to become the preferred way of consuming the web.

According to Google Research in 2017, it took on average 15.3 seconds to fully load a web page on a mobile phone. The impact of poor mobile performance on the business started to become clear to everyone, but we were still lacking an easy way to link those two components.

Everything changed when Google Lighthouse started gaining popularity. I remember when it was introduced and became rapidly adopted in the eCommerce space following Progressive Web Apps hype around 2018. Everyone was obsessed with PWAs, everyone was obsessed with Web Performance, and almost no one knew anything about both. Unfortunately, not much has changed since then.

What makes Lighthouse so widely adopted is its simplicity. You run a test, and get a number between 1 and 100 that tells you how good or bad the web performance of your website is. Everyone, even those without a technical background, can understand that.

The reality is not that simple, though, and web performance or user experience cannot be represented by a single number. In addition, there are a lot of nuances around how a Lighthouse audit works, and to use it as a reliable source of knowledge, you have to be aware of them. You won’t read about these things in the audit summary but don’t worry. In this article, I’ll dig into the most important ones.

Getting obsessed with one metric

Let’s start with a simple question. What does Google Lighthouse measure, and how can we use this information? I have a feeling that many people don’t try to answer it and just blindly assume that the score has to be high to be right.

As we can read on its website, the goal of Google Lighthouse is to measure “page quality”. The audit divides the quality into performance, accessibility, best practices, and SEO. All of those combined should give a good perspective on the quality of the website and, by that, try to accurately predict real end-user experience. “Try to predict” is accurate here because the audit will not give you any definitive answers about your users' experience. Some tools will, though, and I will talk about them in the end.

Google has always promoted the performance score as the most important one. In the heads of the general audience, “Lighthouse score” equals “performance score”, so “quality page” means “page with a high-performance score”.

Don’t get me wrong here. Performance is definitely a major factor influencing page quality and end-user experience, but the fact that we got so obsessed with just one of the four metrics gives the false impression that the only thing that matters to the end-user is performance, and if we get it right, our users will have a delightful experience. In reality, there are so many factors influencing good user experience that even all four metrics of Lighthouse can’t give you a definitive answer if it's good or bad.

Do you even know where this number comes from?

Making business decisions based on a raw number without broader context usually leads to bad decisions, but you can make even worse ones if you don’t even know where this number comes from.

Let me quickly explain how the Lighthouse score is calculated to make sure we are all on the same page.

The Lighthouse score is calculated from a bunch of other metrics’ scores. Each of them has its own weight - some of them are more important, some of them less. You can check how individual metrics contribute to the score on this website.

The algorithm changes with each version. This is nothing unusual - the more Google explores the impact of individual metrics on the end-user experience, the more accurate the weights are. This is why it makes no sense to compare your current Lighthouse score to the one from a year or two ago. Most likely, the scoring system has changed during that time. It could’ve improved or decreased because the algorithm changed, not because you changed something.

I’ve seen many people who made that mistake and were convinced that their website was slower than before (even though it wasn’t). When I asked them why they think it is, they showed me a one-year-old Lighthouse score and compared it to the most recent one.

The problem with local testing

Let’s dig deeper into understanding where the magical performance score comes from. We already know half of the truth behind the number, but we still don’t know about the second most important thing — the environment the test is performed in.

Most people use Chrome Devtools to run their Lighthouse audits, and this is probably the least reliable way of doing it. There are multiple external factors that influence the score. The download and rendering speed depends on your CPU and network. The developers will usually run the test on their shiny Macbooks with 5G internet and in most cases have better results than real users. In addition, your browser extensions are also treated as part of the website you’re auditing.

We can decrease the impact of these factors by running the test in Incognito mode, which will exclude Chrome extensions, and by applying CPU and network throttling, but we will still see different results on different devices.

Running Lighthouse locally is not reliable if you want to compare the results with anyone else and is definitely not reliable if you want to tell if the supposed end-user experience will be good or bad. Everyone in the company can run the benchmark, and everyone will have a different result. It’s hard to tell if there was an improvement or if the opposite happened after releasing the new version if the tests were performed in different environments.

You should always test your website in the same environment and limit the external factors that may influence the score as much as possible.

Using Page Speed Insights

You can have more consistent results if you set up Lighthouse CI in an external environment to test your page or use tools like SpeedCurve, but if you need to quickly inspect a website, I suggest taking a look at Page Speed Insights.

It’s a website made by Google itself, and you can use it to perform quick Lighthouse tests on any website using the closest unoccupied Google Data Center instead of your local machine.

Page Speed Insights usually uses the data center that is the closest one to your location, but sometimes it could use another one if the closest is under heavy load. This is why you could sometimes get slightly different results on the same page in tests made one after another but it’s still much better than using your own laptop.

Even though the PSI score will be more consistent, it’s still far from being an accurate measurement of real user experience. Page Speed Insights will run a mobile Lighthouse test on emulated Moto G4, which is a typical mid-range smartphone. Unless all of your users have it, they’re gonna experience the website differently.

Lighthouses can be easily tricked

Another problem with Lighthouse is the fact that it is just an algorithm. It gets input, processes the data, and gives output. If we know how it works, we can easily cheat it, and that happens more often than you think!

You can easily find a lot of articles like this one showing how to build a website that is getting a perfect Lighthouse score in a particular category while delivering a horrible experience.

It’s equally easy to trick the performance score. You can detect the Lighthouse user agent and serve a different version of your website for auditing tools.

In fact, there are companies out there doing exactly that! If the score is suspiciously high compared to the website's complexity and real loading experience, there is a high chance someone is trying to trick you. We’ve seen that not that long ago in the eCommerce space where one of the PWA frontend solutions - ScandiPWA tried to cheat their clients with a fake Lighthouse score.

// Detect dark theme var iframe = document.getElementById('tweet-1416056228095082499-295'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1416056228095082499&theme=dark" }

As a side note, things like that wouldn’t happen if all of us didn’t so blindly believe that this score is so important.

So when does it make sense to use Lighthouse?

By reading all of that you can get the impression that in my opinion, Lighthouse is useless. This is definitely not my point here! I think it’s a wonderful tool and the fact that Google is trying to find an easy way to help developers identify potential performance bottlenecks impacting user experience is worth supporting. The problem is not in the tool itself but in the way how we use it or, to be more precise, misuse it.

I have no doubts that Google Lighthouse has contributed to a faster web more than any other tool before, but the name “Lighthouse” has its purpose. Its goal is to guide on improving the page quality, not give definitive answers if it's good or bad. I’ve seen websites with a great user experience and low Lighthouse scores and vice versa. Good performance is a tradeoff. You always have to sacrifice something to make it better. Sometimes it’s an analytics script, sometimes it's a feature. It’s not always a good business decision to get rid of some of them to have better performance.

To me, Lighthouse shines the most when we want to quickly compare different versions of our website to see if there was an improvement or decrease in its performance. It’s definitely worth implementing Lighthouse checks in your CI/CD pipelines with Lighthouse CI.

You should also audit websites with similar complexity from your industry to get a sense of the realistic score in your case that you should be aiming for. An eCommerce website rarely scores above 60 while a blog often hits 100. It’s important to know what is a “good” score in your case.

Measuring real user performance

Lighthouse is not a good tool to measure actual user experiences. Synthetic data will never tell you anything about that. To understand how users are experiencing your website, you have to get the data from… your users.

You don’t have to set up any additional monitoring tools to check that! If you audit your page on Page Speed Insights at the very top you will see how it is scoring against the four most important performance metrics (and that will also affect your SEO results).

This data is collected from the past 30 days on devices using Chrome among real users of your website so keep that in mind when comparing the score before and after the update. The only requirement for collecting this data is to make your website crawlable.

This real-world data comes from a Chrome User Experience Report (CrUX) which collects performance metrics from real user devices using Google Chrome (by default it’s turned on on every Chrome browser). You can easily get access to the history of your metric in CrUX Dashboard in Google Data Studio. (edit: Piotr Grzywa posted a link in the comment to generate the CrUX Dashboard for your website automatically)

If you do a PSI benchmark on a few websites, you will quickly notice that in many cases, there is no relation between a Lighthouse score and performance data from real users. For example, below, you can find a screenshot from an audit of adidas.pl (performed some time ago). Even though the Lighthouse score is rather high, the real-world performance is terrible.

This is why you shouldn’t blindly optimize the Lighthouse score and always look for real user data.

Summary

Lighthouse is a great tool if it is used in the right way. You can (and should) use it to get a general sense of the performance of your website. No other tool will give you so much ready-to-process information with just a few clicks.

You just need to be aware of where this data comes from and what exactly it represents so you can make conscious decisions based on it. Not everything that Lighthouse will identify as a bottleneck is an actual bottleneck and it’s not always worth optimizing your performance at all costs.

Lighthouse is best at identifying if there was an improvement or decrease in the performance of a specific website, but the actual score could have nothing to do with actual performance experienced by real-world users. To learn about this, you need to collect real user data.

If you liked this post you can follow me here or on Twitter to stay up to date with new articles!

Vue during coffee break - Transform any Vue application into offline-ready PWA in 5 minutes.

Filip Rakowski — Thu, 18 Apr 2019 09:49:33 +0000

The purpose of this series is to post small tips about advanced Vue concepts that can be quickly applied into every application and give you a new weapon to approach problems.

In this short article I will explain how to transform existing Vue application into PWA or how to set up new one.

What are Progressive Web Apps?

In short words Progressive Web App (PWA) is a web application that works and behaves like a native one.

Some of PWA capabilities are:

ability to work offline
homescreen installation
support for push notifications

If you want to know more i strongly suggest reading this document. Now let's write some code.

PWA Module for Nuxt

If you're using Nuxt adding PWA features works the same for new and existing apps.

(optional) If it's a new project set it up with create-nuxt-app

npx create-nuxt-app <project-name>

Install @nuxtjs/pwa module

npm i @nuxtjs/pwa

{
    modules: [
        '@nuxtjs/pwa',
    ],
}

(optional) Create static/icon.png (recommended 512x512px) which will be used as a homescreen icon for your app.
(optional) Add sw.* rule to .gitignore file to avoid commiting files generated by Nuxt module.

Nuxt PWA module is in fact a set of smaller PWA submodules. Let's give them a look after we're done with the installation:

Workbox - under the hood Nuxt PWA module is using Workbox in generateSW mode (You can find configuration options here) which means it will automatically generate us a service Worker file that will take care of caching our static assets. Every file from your dist directory will be cached for offline usage. This module works out of the box
Manifest - Automatically generates manifest.json file. This module works out of the box but can be configured via manifest property of your nuxt.config.js (read more)
Meta - Automatically adds SEO friendly meta data with manifest integration. (read more)
Icon - Automatically generates app icons with different sizes. (read more). This module works out of the box but can be configured via icon property of your nuxt.config.js
OneSignal - Free background push notifications using OneSignal. OneSignal is a platform that allows to easily send push notifications to the user. You can read how to configure this module here

Vue-cli PWA plugin

If you're using vue-cli 3.x installation is even easier.

For new projects after running

vue create <project_name>

select Manually select features on the first step and then check Progressive Web Apps with spacebar.

After finishing the installation process along with standard files generated by vue-cli you will find registerServiceWorker.js and manifest.json. You can customize behavior of the plugin under pwa property of your vue.config.js and under pwa.workboxOptions you can customize underlying Workbox plugin in generateSW mode (same that we have seen in Nuxt).

For already existing projects on vue-cli 3 installation of @vue/pwa plugin will have exactly the same effect. You can add PWA capabilities to your app by simply typing

vue add @vue/pwa

Other Projects

If you're not using Nuxt or vue-cli 3.x you can still transform your application into offline-ready PWA with just a few commands by using Workbox CLI.

First you need to install the cli:

npm install workbox-cli --global

Next in the root of your project we should make use of a wizard that will generate Service Worker for us:

workbox wizard

After answering prompted questions wizard will generate a workbox-config.js file that will be used to generate a Service Worker!

You can generate your service worker with

workbox generateSW workbox-config.js

Those simple steps can significantely boost your application performance so they're certainly worth a try ;)

Stay tuned for the next parts of the series!

Vue during coffee break - using v-model with custom components.

Filip Rakowski — Mon, 08 Apr 2019 13:13:00 +0000

The purpose of this series is to post tips & tricks about advanced Vue concepts that can be quickly applied to every application and give you a new weapon to approach problems.

In this short article, I will explain how v-model works and how it can be applied to every Vue component.

Understanding v-model

v-model is a common directive used in almost every Vue application. It's typically used to enable two-way data binding on form elements and works perfectly with input, checkbox, select, textarea and radio.

In below example, v-model applied on the input element binds someVal variable with native value property of the input.

<input v-model="someVal">

Then the directive listens for native input event and updates someVal every time it's emitted.

So it turns out that we can rewrite the above code to well-known events and props with the same effect:

<input
  v-bind:value="someVal"
  v-on:input="someVal = $event.target.value"
>

This is how v-model applied to regular input works under the hood.

Knowing this we can use v-model on every component that will emit input event and accept a value prop.

Take a look at this MagicCounter :

<template>
  <div>
    <button @click="changeValue(value-1)">-</button>
    <span>{{ value }}</span>
    <button @click="changeValue(value+1)">+</button>
  </div>
</template>

<script>
export default {
  props: ["value"],
  methods: {
    changeValue(newVal) {
      this.$emit("input", newVal);
    }
  }
};
</script>

Since we are emitting input event with a new value each time it's changed and accepting the value prop we can safely use v-model directive on this component:

<MagicCounter v-model="count" />

Using v-model with custom components

Event thought input and value pair is the default setup for v-model depending on the input type, those bindings can be different (I strongly suggest checking it's source code for details). For example in checkbox element checked property and change event are used instead of default ones.

It turns out that we customize the event/prop pair accepted by v-model directive through a model property. For example, this is how it could look like for checkbox element:

model: {
  prop: 'checked',
  event: 'change'
}

You might want to change the name of the event emitted by our MagicCounter to be more descriptive (for example modified).

Let’s see how we can make this custom event work with v-model

<template>
  <div>
    <button @click="changeValue(value-1)">-</button>
    <span>{{ value }}</span>
    <button @click="changeValue(value+1)">+</button>
  </div>
</template>

<script>
export default {
  props: ["value"],
  model: {
    event: `modified`
  },
  methods: {
    changeValue(newVal) {
      this.$emit("modified", newVal);
    }
  }
};
</script>

..and voilà! Now you know how to use v-model with every Vue component. I hope you'll find a way to use this knowledge very soon .

Here you can find a working example with a code from the post to play with.

Stay tuned for the next parts of the series!