Almost every time I try to connect to #Catchpoint 's #WebPageTest with our paid account, I get a 400 error. 😭
I have to try 5 to 10 times before being able to access the tool and use it…
@grigs do you have similar issues?
“WebPageTest.org is moving to the new UI within the Catchpoint Portal to provide users with enhanced features” in https://docs.catchpoint.com/wptpro/docs/webpagetest-faq
🤣🤦♂️🤡
Ok, the roadmap in #WebPageTest #Catchpoint docs says “Add scripting capabilities to scheduled tests for full control” in the “Later (Future Enhancements)” section…
https://docs.catchpoint.com/wptpro/docs/webpagetest-roadmap
As some features like authentication are now only available in scheduled tests, we can't have both authentification and scripts in the same tests… 😭
Basic authentication is in the “Next (Planned for Upcoming Releases)” section of the roadmap, while it was available before…
I would use @speedcurve if I could.
My client allowed #WebPageTest IPs, much easier for them is seems, than checking HTTP headers from SpeedCurve.
With #WebPageTest before #Catchpoint, we could set the URL for the test, and a script that had access to variables like %ORIGIN% or %URL%
Now, when we activate the script feature in an “Instant Test”, the URL field is disabled, so we can't have reusable scripts… 😭
Oh, and it looks like using scripts is not possible in scheduled tests, I couldn't find it. 😡
Almost every time I try to connect to #Catchpoint 's #WebPageTest with our paid account, I get a 400 error. 😭
I have to try 5 to 10 times before being able to access the tool and use it…
@grigs do you have similar issues?
I’ve been afraid to enable the new UI for #WebPageTest because I wasn't certain I would be able to get back to the old UI.
But I took the leap today hoping I would find an easier way to run experiments blocking domains.
Has anyone else switched to the new UI yet? What are your impressions?
“Discovering Third Party Performance Risks” by @paulcalvano
🔗 https://paulcalvano.com/2024-09-03-discovering-third-party-performance-risks/
> […] a tool called Third Party Explorer, which leverages WebpageTest data to help analyze a third party’s impact on a page load. The idea behind this tool is that some of the insights already collected during a WebPageTest measurement may enable you to prioritize a list of domains to evaluate proactively.
⚓️ https://nicolas-hoizey.com/links/2024/09/05/discovering-third-party-performance-risks/
It likely comes as no surprise that third party content can be a significant contributor to slow loading websites and poor user experience. As performance engineers, we often need to find ways to balance requirements for their features with the strain that they can put on user experience. Unfortunately, for many sites this becomes a reaction to slowdowns and failures detected in production.
#Development #Techniques
Discovering third party performance risks · How to assess if a third-party script needs further review https://ilo.im/15zzqp
_____
#ThirdParty #ThirdPartyExplorer #WebPageTest #Browser #WebPerf #WebDev #Frontend #JavaScript
It likely comes as no surprise that third party content can be a significant contributor to slow loading websites and poor user experience. As performance engineers, we often need to find ways to balance requirements for their features with the strain that they can put on user experience. Unfortunately, for many sites this becomes a reaction to slowdowns and failures detected in production.
In case anyone working on private #webpagetest installs is wondering, it was this func that fails silently (until you add some "curl_error" logging to see that it's timing out...):
https://github.com/catchpoint/WebPageTest/blob/apache/www/common_lib.inc#L2617