Lighthouse has been part of my daily work for the last few months and I shared some snippets in my last few posts. For this particular post, it is time to share how I am using Lighthouse in a product used by millions of people and what I have discovered during this process. Disclaimers: 1. This content may be reviewed in the future as I learn more about web performance and Lighthouse; 2.
Earlier this year, Google announced that “page experience” would impact its search ranking. A few weeks ago, they announced that the new page experience signals will roll out in May 2021. But what are these page experience signals? The page experience signal measures aspects of how users perceive the experience of interacting with a web page. Offering mobile-friendly pages and serving content over HTTPS is something we have been doing for a while but soon slow sites may lose their spot in the Google page ranking algorithm.
Lighthouse captures the rendering timeline of a page in 10 images. Do you need to store them? If yes, keep reading in order to learn how to store these images. The filmstrip above reveals how a page is rendered in a browser and gives us an opportunity to understand what is slow. For example, blank screenshots in the beginning is a sign that the First Contentful Paint is too slow.
Have you ever about thought tracking what is added to a page or web app? Did not know how your website became 15MB? Sounds like it is time to track this data! Calibre, one of my favourite web performance tools, creates charts, such as the one above, to illustrate what is being transferred to users when they visit your page or use your web app. Hi! This post is part of a Lighthouse post series.
Lighthouse is the go-to tool for improving the quality of web pages. Lately, I have been using Lighthouse a lot at work to identify opportunities for performance optimizations. This post is part of a 6 part series that I have written about how to get the most out of Lighthouse. Lighthouse Post Series Quick Lighthouse intro The Lighthouse Node package Getting asset transferred information with Lighthouse Generating screenshots with Lighthouse Getting Web Vitals information with Lighthouse Generating HAR files with Lighthouse My experience using Lighthouse in the real world Quick Lighthouse intro Lighthouse is an open-source automated tool for auditing the quality of web pages.
In my previous post, I covered how to add screenshot testing in Cypress to ensure components unintentionally change over time. Now, I will share how to automate accessibility tests with Cypress. Why should we care about accessibility? Short answer: because it is the right thing to do. Long answer: an accessible web can help people with disabilities improve their lives. There are different kinds of disabilities, including auditory, cognitive, neurological, physical, speech and visual and our goal as product creators, engineers, designers is creating experiences that can include all people.
Developers are usually concerned about the quality of their code. There are different kinds of tests to avoid breaking code when a new feature is added in a project, however, what can be done to ensure that components don’t look different over time? In this post, you will learn how to use Cypress to capture parts of pages of a website and after that, you will integrate the testing tool in CI to ensure that in the future no one will bring unwanted changes in the project.
Working in multiple Node projects sometimes means using different versions of Node. nvm is one popular solution for Linux, macOS and Windows WSL that handles multiple Node installations. One of its most unknown tricks is the deeper shell integration. Check the video: If you are using macOS Catalina, you are probably using ZSH as default shell. To make the magic happen, paste the following in ~/.zshrc file. # place this after nvm initialization!