The journey ahead
This blog is part two of a three-part introductory series that will focus on web page performance. In this blog you will be introduced to multi-page web applications, single-page web applications and standard web page performance metrics. Finally, you will be introduced to Salesforce Lightning web page performance. Check out part one here.
What is web page performance?
From the first part of this series focused on what performance testing is, the different types of performance testing and using time as the primary metric to discuss web page performance.
In this blog we are focusing on the performance of web pages. The question we ask is “how long does it take from when you click a link or press a button for the web page to show (render) the content?”. An example is going to http://www.bing.com, typing in your search term “Lightning Performance” and clicking the search button. Once you have hit the search button how long does it take for the list of search results to show in the browser. Performance testing measures how long this search result page takes to show the results.
Of course, this simple definition hides a huge amount of complexity. There are a range of metrics that have been used over the history of web development to help engineers improve performance. As the web developed, various new metrics were identified and in 2020 Google introduce Core Web Vitals as a way of standardizing some key metrics.
What are some of these metrics?
This is in a rough order of my journey of learning metrics that helped me understand the performance of my web pages.
- DOMContentLoaded or load – Shows how long it took for everything in the DOM (Document Object Model), that represents all the content on the page, to be loaded.
- Time to first byte (TTFB) – this metric is to understand from when the HTTP request was sent to the server, how long did it take for the response to return the first byte.
- Total download size – The sum of all of the data that was downloaded to show the page. This includes html, JavaScript, css, fonts, images, json etc. In general less data downloaded the faster the page load.
- Total count of downloaded files – How many files did we download. There is overhead in TCP/IP protocol that means that lots of tiny files take longer to download that one bigger file.
- Concurrent connections – The protocol for HTTP 1 lead to browsers having a limitation on the maximum number of network connections to a domain. It was possible have requests blocked if all network connections to the domain were being used.
- First Contentful Paint (FCP) – at what time did the first piece of content get painted (shown) on the screen?
- Largest Contentful Paint (LCP) – at what time did the largest piece of content get painted on the screen? This is one of the Core Web Vital metrics.
Are there different types of web applications?
There are two primary types of web applications.
Multi-page web applications (MPAs)
This is just a fancy name for the original web sites. The simplest way to think about this is that every page is independent so all resources (html, js, css, images etc) are fetched for each different page.
The example above shows a simple navigation example. First, we go to www.grandstandperformance.com.
- The first a request will go to the web server to get the first page (page1.html). The html file has references to a JavaScript file and a css file.
- The javascript and css files are fetched from the web server next.
As you look at the rendered page you see an amazing blog article and click on a link to the latest blog item.
- The next page (page2.html) is fetched, which has a reference to a JavaScript and css fileThe javascript and css files are fetched from the web server next.
You can see why we now call this a multi-page web application, as there are multiple pages (html files) as you navigate through the website (application).
Single-page application (SPAs)
As web applications (websites) got richer (usually with javscript interactions) and reactive (usually with AJAX requests), some one had the thought that instead of fetching a new html page each time, just get one html file with only references to JavaScript and use AJAX to get all of information needed to build and render the page in the browser.
Hopefully you see the difference immediately. There is only one page (page1.html) and there are lot more files being fetch. Please note that this picture is to highlight key principles and not necessarily how it is implemented.
You visit www.grandstandperformance.com which fetches page1.html from the web server. It has references to a number of files.
- app.js and app.css that contain all the js and css for every possible page in the application.
- meta1.json has the definition of what needs to be shown on the page. This is called metadata. For example a header image, followed by a title text then a paragraph, followed by a footer.
- data1.json has the data that is needed to fill in the meta1 definition. In this example it would have a url to the header image and the title test, the paragraph text and the footer data.
With the metadata and data, the JavaScript in app.js build the DOM tree to render this page.
Next, you see an excellent looking blog article and click on the link. This now really highlights the difference between a MPA and SPA. The click does not cause a new page to be requested. Instead that click kicks off some JavaScript that does the following:
- Clears the screen by removing the top-level DOM node, or perhaps just hiding the top level DOM node.
- Requests a new meta file meta2.json which describes the layout of the new page.
- Request a new data file data2.json which has the data needed for this page.
As above, with the metadata and data the JavaScript in app.js build the DOM tree to render this page.
As the web became more critical to businesses the idea was to provide the smooth responsive interaction that native application provided, and SPAs were an enticing way to do this. From a business perspective, we should be able to offload most of the work (building the DOM tree) to the client browser (which is free from the businesses perspective) and all we have to do is send up some metadata and data json blobs. This provides native application-like interactivity with lower server costs.
MPAs vs SPAs
Apart from the obvious differences described above, I want to draw your attention to two significant differences between these application models.
- Performance metrics. A lot of the standard metrics like DOMPageLoad, FCP and the Core Web Vitals that are built into the browser only work for MPAs. This makes SPAs challenging, as each implementation needs to build their own model in JavaScript to create a metrics that attempts to duplicate the functionality built into the browser for MPAs.
- Equity. SPAs are more intensive, in general, for both client-side compute time and network time. For those that have access and can afford top end computers, mobile phones and network connections the impact of SPAs is limited. However, this is not most of the world. I was recently introduced to Alex Russell’s Infrequently Noted blog site and the Performance Inequality Gap series. It is really worth reading this series.
Are there any other models?
There are other models that are a mixture of MPAs and SPAs, however I won’t go into detail here. The blog up until now is just a lead up to get to Salesforce Lightning web application performance. So lets get into it.
Salesforce Lightning web page performance
We have finally got to the reason for this blog series, the basis for the upcoming deep dive blog series and the primary purpose of Grandstand Performance. Salesforce Lightning web page performance is a complex and interesting challenge. SPAs are a challenge in their own right, to measure and understand performance. The lack of standards around this exacerbates the problem, leading to bespoke measurements. Salesforce Lightning has the added challenge that it is a platform built to support, essentially, infinite customization.
What is Salesforce’s page load measurement?
Experience Page Time, more commonly known as EPT, is the custom measurement created by Salesforce to standardize page load performance for Lightning. Quoting from the Salesforce documentation
“Experienced Page Time (EPT) is a performance metric Salesforce uses in Lightning to measure page load time. EPT measures how long it takes for a page to load into a state that a user can meaningfully interact with.”
How can I see my page load EPT?
There are at least five ways that you can see EPT for your sites page load times.
- EptVisible
- Debug mode
- Instrumentation Beacon
- Lightning Usage App
- Event Monitoring
I am going to skip discussion of Lightning Usage App and Event Monitoring. The first three options can be collected from the browser as you are navigating through your Lightning application, so we will focus on these options.
EptVisible
This is the quickest and easiest way to see what the EPT is for a given page. Once you have logged into you Salesforce instance you add a query string parameter to the end of the URL. Just add ?eptVisible=1 to the end of the URL and hit enter. You will see a new UI component come up showing EPT in both numeric form with a time in seconds and with color coding based on the time to load the page. It is green if it is less than three seconds, orange between three and five seconds and red for EPT greater than five seconds.
Debug mode
Debug mode does a lot of things. The most significant thing is that it does apply any optimizations or obfuscations to the JavaScript that runs Lightning Platform UI. This has a significant impact on the performance of Lighting web page load times. A part of this is enabling eptVisible implicitly and shows EPT after each page load. If you are just looking for EPT use the eptVisible query string parameter instead of this option.
Instrumentation Beacon
Instrumentation beacon is how Lightning sends the performance metrics it has collected back to Salesforce. In the last 15 years I have spent most of my time using Fiddler, a HTTP proxy, running almost all of the time showing me the network requests and responses. Whether you Fiddler, Postman or Chrome developer tools you can capture the https traffic. If you look at the network requests, there will be a POST request that looks something like:
This sends all of the instrumentation measures collected during the page load process. In the next blog I will go into more detail of what data is in this data set. For now just know you can look at the post body and search “ept” you will find something like, \”ept\”:1297, indicating an EPT for 1297ms.
There will be a deep dive into the information in this post request coming soon.
Conclusion
Traditional websites or Multi-page applications (MPA) have a range of best practice and built-in metrics. This helps with understanding the application performance, learning resources and best practice approaches to making performance improvements.
Salesforce Lightning Platform is built as a Single-page application (SPA). To help with the challenge of understanding performance of Lightning Platform a custom metric Experience Page Time (EPT) was created to help Salesforce and their customers understand their web page load time.
Finally, you were given some basic approaches for you to start monitoring and collecting information overtime on the performance of your Salesforce Lightning web page load times.