@shivaalipour Can you have our devs take a look at this.
DAP is required on all government websites per M-23-22 and DAP is installed and the analytics are flowing into the DAP console for marketplace.fedramp.gov. However, TTS' Site Scanning tool that is being used by OMB to validate site compliance with M-23-22 is still having issues detecting it.
So - the short version is that there's some aspects of marketplace.fedramp.gov that cause performance issues. The most immediate effect, that led this thread, is that the Site Scanning scans which OMB is using to better understand all federal websites, fail because the page times out for them. That, in and of itself, isn't a huge deal, but there's reason to think that it may also be impacting the user experience of some visitors as well.
The clearest way to start to see the impact of this (and also, I'd say, the clearest roadmap for addressing it) is to load the site into Google's Pagespeed Insights tool. The results 1) suggest a number of performance issues (see the Core Web Vitals Assessment) and 2) reflect the same timeout issue (see how the lower down Diagnose Performance Issues section can't load - you can compare against the results for www.fedramp.gov to see what I mean).
It would be good for the marketplace website to be able to return results in the Site Scanning data and in OMB and GSA's website analyses, but the bigger issue is any degree to which the underlying performance issues that cause 1 and 2 above impact visitors.
The best direction to share with the team that actually operates the site would be that you want to improve the site's results on pagespeed insights such that the Core Web Vitals Assessment passes and such that the Diagnose Performance Issues section can run. I suspect that much of this may have to do with the nature of the site's design (it looks like the entire page loads from a script in the page's source code instead of being the page's source code itself - see the attached screenshots for a sense of how that is different). It's possible that redressing these things might be simple, or might not be, I'm not sure. Your team should be able to think it through and propose a plan. Holler if you want any help unpacking this with them though.
@shivaalipour Can you have our devs take a look at this.
DAP is required on all government websites per M-23-22 and DAP is installed and the analytics are flowing into the DAP console for marketplace.fedramp.gov. However, TTS' Site Scanning tool that is being used by OMB to validate site compliance with M-23-22 is still having issues detecting it.
So - the short version is that there's some aspects of marketplace.fedramp.gov that cause performance issues. The most immediate effect, that led this thread, is that the Site Scanning scans which OMB is using to better understand all federal websites, fail because the page times out for them. That, in and of itself, isn't a huge deal, but there's reason to think that it may also be impacting the user experience of some visitors as well.
The clearest way to start to see the impact of this (and also, I'd say, the clearest roadmap for addressing it) is to load the site into Google's Pagespeed Insights tool. The results 1) suggest a number of performance issues (see the Core Web Vitals Assessment) and 2) reflect the same timeout issue (see how the lower down Diagnose Performance Issues section can't load - you can compare against the results for www.fedramp.gov to see what I mean).
It would be good for the marketplace website to be able to return results in the Site Scanning data and in OMB and GSA's website analyses, but the bigger issue is any degree to which the underlying performance issues that cause 1 and 2 above impact visitors.
The best direction to share with the team that actually operates the site would be that you want to improve the site's results on pagespeed insights such that the Core Web Vitals Assessment passes and such that the Diagnose Performance Issues section can run. I suspect that much of this may have to do with the nature of the site's design (it looks like the entire page loads from a script in the page's source code instead of being the page's source code itself - see the attached screenshots for a sense of how that is different). It's possible that redressing these things might be simple, or might not be, I'm not sure. Your team should be able to think it through and propose a plan. Holler if you want any help unpacking this with them though.