 Good morning, everyone. Today, I'm going to talk about the Lighthouse CI and the benchmarking the web applications with the Lighthouse CI. So this is the topic which I'm going to talk about today. My name is Rijan Uman. I'm working as a senior software engineer with Red Hat. And I belong to the digital experience platform D also. So let's see what is Lighthouse. Lighthouse is an open-source tool which we can use to analyze the quality of the web pages. Like if you have a web page, so if you want to see how your web page meets the certain standards which you set, so you can do an audit against the website against the light with the Lighthouse. So this is actually developed and maintained by the Google. And this is completely open-source. So by default, Lighthouse is shipped with every browser which we use, specifically Chrome. So in the Chrome and Chromium, we can see the support of the Google Lighthouse part as a part of the Google Developer Tools. If you open the Developer Console, you can see that there is a certain option called Lighthouse in the Developer Tools. There you can find the certain aspect for categories and the device you need to audit against. So you can see that once you generate a report against on a website, you can see a certain report over there. And it will say something that, hey, how my web application is looking like. How does the Google Lighthouse CI rate your web page against the certain standard? You'll get that insight about your web page, actually. So this is actually the Lighthouse part. Basically, it will help you to audit or it will help you to analyze the web page against certain standards which we set, actually, which I told in the first slide. So yeah, this is all about the Lighthouse part. But the key insights which we get from the Lighthouse is the performance score, accessibility score, and the best practices score, and SEO score, and PWS score. So based on this course, we can rate our web applications and we can rate our web applications and we can improve with the suggestions which is provided within the Lighthouse. So let's think about like, so this is actually built with the developer. So let's see that, can we adopt this? My question is, can we adopt this Lighthouse as a part of my CI-CD deployment process? So in, for example, once you deploy an app, you can identify that like, hey, how my performance should look like. So what will be my accessibility score for this release? So even if you get some certain questions like this, you can directly integrate this Lighthouse CI with your web application. So there comes the next section called Lighthouse CI. So in the Lighthouse CI, Lighthouse is incorporated within the CI ecosystem. So in the CI ecosystem, you will be able to see the, you'll be able to perform the audits of a web page against the certain standards as it is before, but it is all in the CI way. So Lighthouse CI can be defined as, it is a set of tools which we can use to audit a website, saving the result and the, to verify the results against the certain standards, actually. This is the Lighthouse CI part, which is exactly the section. So in the, so it has various steps in the process behind. We can go through that one by one later. So let's see how a typical developer workflow happens, actually. So if you have something to get changed, so you maybe will be developing that, you'll be testing that, you will be marked as verified and you will deploy it. So after the deployment, so how this testing happens, actually, how the audit process, let's call it as audit process, how the audit process happens within all the scenes. So in the automatic test sections, in the automatic tests and the, so we can include a certain phase called Lighthouse CI configuration, where we can audit the deployment, against, we can audit the deployment against the certain standards which we set, actually. So for example, like if you merge a pull request, you will perform all the CSED processes for the test or your deployment and everything. After that, you'll be using the Lighthouse CI to audit the deployment and you'll get some certain score and you'll get some certain insights about the webpage also. So this you will be getting within the Lighthouse CI. So even if you, even if something needs to be improved, you will get some more data about that, actually, in the automatic test phase only. You don't need to wait for the complete Lighthouse report to be generated also. You will get the more insights about the things. For example, if you are not using the pre-connect, if you are not using the, if you are not using the five-accounts properly, you'll get the certain insights about that. So this can enrich the user experience in a way that we can continuously provide a stable user experience to our customers. So let's see what is happening in scenes behind the Lighthouse CLI. So there is a CLI which is available in the NPF. We can install that globally. So with the support of the CLI, with the support of CLI, we can start, we can incorporate it into the CI also and we can test it actually. So there are generally, there are four phases which we perform in the testing phase. Health check, collect and asserting and upload. So health check means that it will verify that every configurations which we set for the audit is right or wrong. It will verify that. And collect means we will perform the scans against the URL. For example, if you deployed, if you deployed a certain spa, single-page application, if you want to audit the single-page application, then it will run the test against it in the collect phase and it will fetch you the Lighthouse report. In the assert phase, so in the Lighthouse CLI configuration we mentioned, it might be mentioned some assertion standards. Assertion standards is nothing but certain set of predefined rules which we can use for the benchmarking. So in the assertion phase, we will perform that. So is that Lighthouse report is meeting my expectation. We are doing the comparison in the assert phase. And upload is, in the Lighthouse CLI, there is something called the server. So we upload the whatever the Lighthouse report we received to the server. So these are all the process which is running behind the Lighthouse CLI. So these all processes are incorporated into a single module called Autoron. Autoron is actually, when you execute the Autoron, it will perform this all the operations. It will perform all the operations like health, collect, assert, upload in a single command and with the default value. So if you want to overwrite it, we can override that also. You will get a complete provision over there also. Yeah, so you have to install this Lighthouse CLI to get this feature in your pipeline. Yeah, so before I told about this Lighthouse CI server. CI server is nothing but a storage server for performing your, for storing your Lighthouse reports actually. So it will give you the trend of like how the performance was before, how the performance was now. You will get a certain insight of your single page application so that you can continuously improve your application. So this can be a single source of truth for the value of your app. So you will get the UI also then. So this is also an NPM package. So you can configure that also and deploy it. There are various Docker images also available to use this Lighthouse CI server. So you can deploy that and you can upload the CI as a result to the servers. Then you will be getting this kind of insights in the CI server. I will take you through that in the demo spot. Yeah, so if you want to, I told about this Lighthouse CLI. If you want to onboard a certain Lighthouse, so you have to register your Lighthouse app. You have to register your app. With the Lighthouse project. So that we are using something called Vizart. In the Vizart, we actually perform the process of generating the, we are going to the process of registering our single page application with the Lighthouse CI server. In the CI server, we generally go for what should be the name which we want to see in the Lighthouse CI server and what is our Lighthouse CI server URL? What's your project name? Where is our source code? So once we get every, once we give every data, we'll get two things called admin token and the build token. So build token is something which we use to upload the Lighthouse report which we get as per part of the assertion process which I shown in the demo. So, and the admin token is a token which is used to manage the project which is in the Lighthouse CI server. For example, deleting the project, updating the project which we just created in the CLI. So this kind of administrative task which we use for the admin token. So there are various way we can configure the Lighthouse CI. So it can be a JS file, it can be JSON, it can be YAML. So the file name should be like this. Based on this, we can, we can configure our custom configurations for our Lighthouse audit process. So in the Lighthouse audit process, we can mention that like what will be our suboptions like I mentioned the certain phases in the, before slide, like health check, collect, assert, upload. So if you have any custom requirements also, we can mention it over here. So based on the inputs which you give over here, it will audit, Lighthouse CI will audit your webpage against this. So as I will repeat it one more, collect is the upload, collect is the URL scan configuration, assert is the standards which we are going to check, upload is the server upload configuration and the server is the part where, which we actively use for deploying the server. But we generally consider just two factor, this already something which we use for the, which we use for the project creation process. There are various type of customizations which is possible. This is a generic template which we use with the Lighthouse RC.js file. So this is the basic configuration model which we come in picture. Let's to see that how this is configured within a project and all. Is everything okay? Yeah, I'm just resharing my screen completely. Okay. Oh, sorry. Yeah. I hope everyone can see my screens. Yep, we can. Okay, thank you. So I do have a single page application. So this single page application consists of the Lighthouse configuration. This is built with an Angular. So I have deployed this single page application in the upstream version. Like this is the application which we use. So basically, yeah, this is the application which we use in the upstream. So, and this is deployed completely on the Heroku. So, yeah, so one, my deployment is happening within. So my project is configured with the Heroku and it will deploy whenever I push automatically. So also I have mentioned about CPU configurations in here also, like collecting. So LHCA collect is a command which we use to collect actually. So LHCA collect is an operation which we use to collect. So in the collect configuration, yeah, in the collect configuration, it will audit the webpage against the standards which we test actually. So, yeah, so by default, by default every test will run three times. So if you have any specific configuration related to the testing within the Chrome, you have to mention that. And the URLs, if you want to test multiple URLs, you can mention that. So assertion is the standard. There are three assertion standards which we follow as recommended all and the no PWA. So, also you can define your own custom standards also over there. So you can refer to this URL, I'll share in the link. So you can refer to this URL and you can see the multiple assertion standards like in the state. So another thing is like after configuring your Lighthouse CI, you have to mention it in your workforce pipelines actually. So I'm using the GitHub actions for this audit process. So in the GitHub actions, what I am doing is in the GitHub actions, what I am doing is I'm installing the CLI only and I'm auditing the, and I'm auditing it against the URLs which are configured in the Lighthouse RCS.js. So in the Lighthouse RCS, I have, I'm defining this upload configuration separately which you will ensure that like where should the, where should my Lighthouse report to be uploaded to? What will be my build token which are generated as a part of the CLI? So, and it will also recognize the URL and pushes it actually. So that's the process which we performs in the autorun operations. So let's see. So I have made a few changes in my spa like which can help in the performance improvement. So, so I have, I'm committing it and pushing it actually. So once the change is pushed, automatically the deployment happened in the background by the, in by the Heroku. So, yeah, so, yeah. So this is my project repository. So here I am setting up the certain GitHub actions to ensure that like what is happening in the behind actually. Like, so I'm, so in the Lighthouse CLI, in the, in the GitHub actions, it is installing the Lighthouse CI and it will perform the autorun process which I mentioned before. Yeah. So in the autorun process, what it shows is it will be performing a health check on this first piece and it will run the audit against the URL which I, which I set in the configurations. So here the, the URL which I set it by other upload. So this is where I am overriding the default configuration also with the autorun, so, yeah. So, so by default it will run three times. You can customize it to as, as you need actually. So let's wait for that. So, so in the background, like for the Lighthouse CI, what's the dependency for that is a kind of, like if you are doing in your own pipelines, you might be in, you might have to use a support for the image, you might have to include the image with the Chromium support or Chrome support, Google Chrome support. Yeah. So right now this is, this is deploying this spam, which is on the upstream. So it is testing this and performing the, collecting the results. So the audit has been completed. Let's go through that actually. So once the audit is completed, you'll see the certain things actually, what is failing like, so as a developer, as a, as a engineer, you can see that, like what things you can improve over this. For example, like how, how this score can be improved. So you'll get the certain tips in the web UI also in the CLI also. And you'll get, so once you, once you go through the results, you can say that your standard has been met and you can push the data. So once, once the, once the session is completed, it will automatically upload the data to the Lighthouse CI server. CI server, I told you, it is a place where we store all the Lighthouse CI reports in one place. That's the, that's the place where we used to store. Yeah. So once it is uploaded, you will be able to see the certain Lighthouse results in the, in the Lighthouse server. So, so you can see that actually, like what has changed with the last build, which I pushed. So you can see the comparison analysis also, like right now with the change performance improvements, like I say that I have get a 25 point extra score with a comparatively to the last thing. So this is a detailed Lighthouse report which we can get within the Lighthouse server. So how my performance has been improved with the last change which I pushed. So you'll be getting more insights also with the specific Lighthouse report. Like in the Lighthouse build difference, it will compare with the how, what was the last build and what is the new build. So based on this comparison, it is going, it is moving forward right now. So another thing is like, when you go through the Lighthouse server, so when if you go through the Lighthouse server, you can see that projects are there. So this is the project which we registered over the CLI and when you click on the CLI part. So you can see that, like what are the things which you will get the trends which are shown in the slide actually, like how the performance has been changed with every commit which I made. So we'll be getting more insights about that. And about another thing is like, you'll see, you can see the trend actually, what's a large contentful paint. So what's a large speed index for the sparse. So you'll get some more insights also on the certain score which we are moving forward also. So this can be happen, this can be done within the every commits, every deployments also. So this is the one part of this. And it also give the trends of the SEO score also. So for your deployments, similarly for the Prophecy web apps also, it will show you the trends with the, like how the, how your stack, how your app is rated, how your app is rated with the, how your app is rated with this actually. Yeah, another thing is like, you can, if you go for a build report, so you can see some more things like how your, how your web stack is actually arranged over there also. Like, so what are the steps you need to be taken care of and everything you can see that actually. So even if you open the Lighthouse report, so this is the same thing which we see over in the developer console, like developer tools actually. So in the developer tools, we can see that, like this is a similar, this is a similar data which we get over here also. Also you can see that how, it's a similar report, but also you can see the how your build is actually optimized, build is actually deployed within the server. So you can get into a detailed insight also, like how the, how your original source code is behaving in the browser. You can get some more insights also on this case also. Yeah, so yeah, so yeah, that's all about the Lighthouse CI. Any questions? Are you done? Okay, there is one question in chat. Can, are we able to do quality, code quality check in Lighthouse CI rather than performance quality? With the code quality check, it is not, so it can suggest you something, it can suggest you something regarding the performance actually. So for the code quality, it is not as an exact tool like Sonar. Okay, Shovil, does that answer your question? Yes, okay, great. Guys, if you have any other questions for region, you can put it in the Q&A section or type it down in chat, I'm monitoring both. Also, yeah, go ahead. Also, we are continuing with this as an open source project also, so these are the few references which we can use to start with this Lighthouse CI performance audit and score audit processes. So we also have a project called one platform. So in the one platform, we have adopted this Lighthouse CI and we have created a consolidated place for the dashboard and the microservice to perform all these kind of operations. Like this is actually pretty much good, actually, people can watch on this rapport. Yeah, so this is actually completely integrated with the Lighthouse CI server. Okay, that's great. There is one more question. So is it just to improve SEO for the SBAs? No, so it is, every practice can be improved. Like you can improve the performance, you can improve the accessibility based on the standards which were based on the W3C standards also. So it's a typically a guide, it's a CI guide to improve your web app. Okay, does that answer your question? Okay, great. That was a very comprehensive presentation. Thank you for that. I'm just looking, is there any more questions? No. I don't think so. Is there anything in addition you want to say according to your presentation, you have a couple of more minutes? So I strongly recommend you to try this Lighthouse CLI and the process to adopt as your workflow. So you can deliver a best experience to your customer based on the results actually. So always have a goal to reach the 100. So if you have that, so we can consistently give a good experience to our customers in the web platforms. This can be, this is a really a life saver. Okay, great. Thank you so much, Rajan. Okay, we will take a five minute break for the, if there are no other questions right now, you will take a five minute break before we start the next session, next talk. Thanks. Okay. I'll be open for Q&A also that time, anyone? Yeah, if anyone, Rajan, actually there is a breakout room link and you can join that in case anyone wants to, continue the conversation with you and ask any more questions, then I'll just paste that in the chat right now. Okay. If anyone has any more questions that want to interact with Rajan, the breakout room link is right there. Okay. All right. Thank you, everyone. Yeah, thanks.