@csxgg
I find this very interesting. Right now I'm starting to research how to create a performance budget which would result in passing Core Web Vital metrics. Basically, I want analyze pages that already "pass" these benchmarks and then I want to see the breakdown (count and size) of files loaded by the browser before FCP and LCP (as well as other metrics), and I'd like to see how many scripts have "long tasks" that are loaded before FCP and LCP, etc. The result would be a budget that could be "predictive". Meaning if you build the page to load files in this way, we can predict that it will be fast. For example, do fast pages load 3 images before LCP or 20? Or do fast pages load 1 script with a long task before LCP or 5? Or how many render blocking resources are loaded before FCP? Third parties would be good to know as well. The idea is that if you use the app shell modal, critical rendering page and this type of "budget" then you have a boiler plate for building a fast page. Then if you know this, you can evaluate existing pages. That all said, I find this research really interesting and I return to it often as I work on waterfaller.dev.
There's so much intricacies on web development that could affect performance! I had no understanding at all of these things under the hood, and merely tried to represent characteristics of a web page with numbers. I'm glad this work can potentially be useful, but clearly there are a lot of things that are not captured by the training data.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Tim, sorry for the super delayed response!
This was simply a modeling choice that we made, as there was some extra interest regarding font, so I added an additional request count for font.
For third party requests though, we did use count of requests, and did not come up with much strong correlation there.
@csxgg I find this very interesting. Right now I'm starting to research how to create a performance budget which would result in passing Core Web Vital metrics. Basically, I want analyze pages that already "pass" these benchmarks and then I want to see the breakdown (count and size) of files loaded by the browser before FCP and LCP (as well as other metrics), and I'd like to see how many scripts have "long tasks" that are loaded before FCP and LCP, etc. The result would be a budget that could be "predictive". Meaning if you build the page to load files in this way, we can predict that it will be fast. For example, do fast pages load 3 images before LCP or 20? Or do fast pages load 1 script with a long task before LCP or 5? Or how many render blocking resources are loaded before FCP? Third parties would be good to know as well. The idea is that if you use the app shell modal, critical rendering page and this type of "budget" then you have a boiler plate for building a fast page. Then if you know this, you can evaluate existing pages. That all said, I find this research really interesting and I return to it often as I work on waterfaller.dev.
There's so much intricacies on web development that could affect performance! I had no understanding at all of these things under the hood, and merely tried to represent characteristics of a web page with numbers. I'm glad this work can potentially be useful, but clearly there are a lot of things that are not captured by the training data.