Closed felixarntz closed 1 year ago
cc @tunetheweb @westonruter
@felixarntz I added a list of tested websites to the PR description to check our test action. (see here)
@tunetheweb @max-ostapenko I'm not sure what's going on with the tests in https://github.com/HTTPArchive/custom-metrics/actions/runs/6629171971/job/18007857722?pr=96 Looking at the CI failures, the test code seems to assume it needs to run some of the returned values from this check as commands (which is not the case)? 🤔
Can you advise on that, or is there any documentation on how I should amend those tests?
Just merged a fix to main
for this so just updated this branch. Fingers crossed it works now!
Tests now pass. And it automatically comments with the custom metrics for any URLs mentioned in the issue. Saving you the need to run these manually. You can check them to make sure your custom metric change is working as intended.
@tunetheweb @max-ostapenko I'm not sure I understand how the automated tests are supposed to work. Looking at the results in https://github.com/HTTPArchive/custom-metrics/pull/96#issuecomment-1777769835, for example https://webpagetest.httparchive.org/details.php?test=231024_AD_V&run=1&cached=0#:~:text=cms-,%7B%22wordpress%22%3A%7B%22block_theme%22%3Afalse%2C%22has_embed_block,-%22%3Afalse%2C%22embed_block_count%22%3A%7B%22total, I don't see the metrics from this PR being added at all.
If they were incorrect, I would assume there may be a problem with the PR, but given that the field that this PR is adding is missing entirely, I wonder whether the tests are working as intended. The cms.wordpress
object should have a content_type
property, but that is not the case, which makes me think this is not using the latest JS from this branch.
@felixarntz The tested custom metric is called _cms
, so you should look for _cms.wordpress.content_type
.
The other cms
custom metrics I believe are the ones used in production currently.
They should show in "Changed custom metrics values:" section though, which I believe @max-ostapenko is looking at in #100. Will see if we can get that merged first to test on this PR.
They should show in "Changed custom metrics values:" section though, which I believe @max-ostapenko is looking at in #100. Will see if we can get that merged first to test on this PR.
This is fixed now and seems to be working. Thanks @max-ostapenko !
In WordPress specific HTTP Archive research, we've so far typically relied on only home pages of each origin. However, home pages tend to have different layout than many other pages have, and our assumptions on e.g. performance are not segmented in any way regarding content type. It would be helpful to e.g. differentiate between specific performance patterns commonly applied on home pages vs on singular posts.
Therefore this PR introduces a WordPress specific content type detection, based on the body classes that the CMS outputs by default. The PR adds 3 fields with information:
template
: This is the most important field and can have one of the following values:home-blog
: The home page showing the blog (of latest posts).home-page
: The home page showing a "static front page" (as configured in WordPress).blog
: The blog (of latest posts) if configured to not also be the home page (only relevant when the home page is showing a "static front page").singular
: Any kind of singular content, e.g. a single post, page, etc.archive
: Any kind of archive content, e.g. a post type or taxonomy archive.unknown
: None of the above could be detected.post_type
: The post type of the current content, or empty if not applicable based on thetemplate
. This field should have a value for any content type, except for a taxonomy archive.taxonomy
: The taxonomy of the current content, or empty if not applicable based on thetemplate
. This field should have a value only for a taxonomy archive.Some WebPageTest tests with this logic (using @westonruter's site as test candidate):
Test websites: