Disable sourceURL Comments

[anton7249]

Hi,

There is sourceURL= now in styles tags, that can not be disabled.

<style id='wp-img-auto-sizes-contain-inline-css'>
img:is([sizes=auto i],[sizes^="auto," i]){contain-intrinsic-size:3000px 1500px}
/*# sourceURL=wp-img-auto-sizes-contain-inline-css */
</style>

And there are all the block styles have these comments.

/*# sourceURL=wp-img-auto-sizes-contain-inline-css */

Since this is for developers purposes, can this be disabled with a help of condition SCRIPT_DEBUG ​https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/#script_debug please to improve performance?

These comments add additional kbs to a page.

Kind regards

[westonruter]

This was introduced in #63887 and related tickets.

I don't feel too strongly that the sourceURL comments always be visible, but I'm also not sure that SCRIPT_DEBUG is the right way to exclusively enable them. For example, when SCRIPT_DEBUG is off, styles are minified and it is useful to be able to see the source for where minified scripts and styles are coming from as well. It's also useful for running a code coverage report with minified sources. It's also useful to easily identify the source of a JS error in production without enabling SCRIPT_DEBUG.

Maybe there should be a function like wp_should_show_source_url_comments() with a corresponding filter that defaults to the value of SCRIPT_DEBUG. This would allow an opt-in to sourceURL without also serving unminifed scripts and styles.

This applies scripts as well as to styles.

cc @jonsurrell

[anton7249]

A function

wp_should_show_source_url_comments()

would be great!

[jonsurrell]

Thanks for creating this ticket. The sourceURL comments are mostly helpful for developers and for debugging issues on sites, so we don't want those improvements to come at the cost of performance regressions.

If there's a performance tradeoff to be made, we should consider conditionally printing the comments or providing ways to configure the comments. However, if there is no performance tradeoff then adding complexity to WordPress and more options to configure this behavior is harmful and should be avoided.

It's my believe that there's no real performance tradeoff here. Any efforts to improve performance are better placed elsewhere.

---

How could this be theoretically harmful to performance? Let's look at the most recent post at the time of writing on the Make/Core blog: ​Coding Standard Proposal: Allow the use of the PHP short echo tag. I've captured the page with curl then stripped the sourceURL lines with sed in order to compare the two versions.

---

It's more bytes to send.

This is true, the HTML page contains more bytes. They are repetitive bytes of ASCII text and should compress very well. The tested page had 25 scripts and styles, so there were 25 lines with sourceURL. For compression, nginx's compression module uses gzip level 1 by default so I'll use that in the comparison:

	With sourceURL	Without	Difference
Size (bytes)	469,701	467,964	-1,737
Gzip (level 1)	80,013	79,781	-232

200 bytes of page size does not seem like a significant impact for the page size.

I agree in general that smaller responses are better, however not all bytes have the same impact on a page. In my opinion, the benefit of the sourceURL outweighs the cost of a few hundred bytes of HTML.

---

JavaScript bytes are expensive!

This is also true, JavaScript tend to be some of the most expensive bytes in a page. The JavaScript engine needs to parse and evaluate all of these bytes. However, not all JavaScript bytes have the same impact. The sourceURL are entirely limited to JavaScript comments, so JavaScript engines can optimize parsing to basically skip the comments, and of course with comments there's nothing for the engine to evaluate. ​Here's an example from the v8 engine where handling of comments has a special case (there's even a special case for the "magic" sourceURL comments). ​There's some related information in this v8 blog post.

Bytes of CSS stylesheets are usually considered less expensive than JavaScript, but the same reasoning applies (comments are relatively cheap bytes of CSS).

Again, the cost of these sourceURL comments seems unlikely to have a significant impact on the page performance.

I would like to highlight a related performance related ticket at #58873. There's a proposal to add a method to pass data to scripts without using JavaScript script tags (no JavaScript engine parsing or evaluation on page load). That's a great place to focus performance-related efforts.

---

If I've overlooked some aspect of performance or if someone can provide data or analysis that suggests this has a significant impact on site performance, please share it. If that's the case, we should absolutely revisit the sourceURL comments. At this time, I don't think it's worth focusing efforts or introducing any complexity to make the comments configurable.

[anton7249]

@jonsurrell Hi

Ok, got it.

In Chrome Network tab ​https://developer.chrome.com/docs/devtools/network#open I had 15kb of html page, after updating to 6.9 I has 17kb.

Not too much, but nevertheless.

I do not know which Gzip level I have, 5 probably as a default.

[jonoaldersonwp]

I'd also like to be able to disable this; I'm seeing these URLs getting requested/crawled unnecessarily and at scale by Google/LLMs etc.

[westonruter]

Googlebot erroneously crawling non-link URL-like paths has come up recently ​for Speculative Loading and ​for Optimization Detective. It doesn't seem like a big problem though?

[jonoaldersonwp]

Yeah, those issues are also problematic (though harder to solve, as the nature of them requires the outputting of things-which-look-like-URLs - whereas simply not outputting the sourcemap refs in our CSS issue is much simpler).

At scale, this is definitely an issue worth fixing; the printing, discovering, crawling, and processing of those URLs and their content at WordPress-scale has a real carbon impact.

Further, it's also costing time and money in businesses everywhere, discovering and investigating the data in GSC, etc.

[westonruter]

If that's the case, maybe they should default to not being displayed unless SCRIPT_DEBUG is enabled.

I'll milestone this for visibility and change to a defect type.

[jonoaldersonwp]

Heroic, thanks!

[westonruter]

@jonsurrell If you concur, I'll work on a patch.

Modifies the sourceURL output so it's only done if the SCRIPT_DEBUG constant is set to true.

Trac ticket: https://core.trac.wordpress.org/ticket/64369

## Use of AI Tools

Copilot helped with auto-complete/type ahead.

[peterwilsoncc]

@westonruter @jonsurrell I've linked a ​pull request to this ticket to make this change.

As the unit test suite runs on the -src directory, the SCRIPT_DEBUG constant is defined as true by default, see this ​block of code in default-constants.php

This has allowed me to only modify files in the source code for the pull request but does mean the tests will fail if a developer sets the constant to false in their test config file.

However, this is already the case as a lot of the script enqueuing tests already assume it is set to false and look for min.js extensions. If you set the constant to false and run phpunit --filter test_various_strategy_dependency_chains you'll see an example where the jQuery enqueues fail to return the expected result.

this sounds less than optimal as it seems to lead to the next workflow

• There is a JS error. It is hard to trace where it comes from
• change your wp config, set debug_scripts to true
• recreate the error to be able to pinpoint where it comes from
• solve the bug
• change your wp config, remove debug_scripts setting

I would go for something less conditional like show it only to admins (I am assuming all developers have or can safely be given admin role, not sure how much this assumption is true in real life)

on a second thought maybe it does not worth the effort at all as it adds relatively so little to the generated HTML, but if this kind of filtering must be done, maybe its better to use the enviroment setting as a signal.

[jonsurrell]

@jonoaldersonwp I'd like to confirm that I understand the issue you're describing.

• Crawlers discover the sourceURL comments and try to crawl the referenced URLs.
• This means "URLs" like wp-img-auto-sizes-contain-inline-css are discovered. This is treated as a relative URL and a fetch is attempted.
• This likely results in a 404.
• The 404 appears in GSC (Google Search Console) and creates confusiong.

Is this a good description of the problem? Are there additional issues I haven't summarized? Will you share some specific URL examples? (of the form https://example.com/a-post-slug/wp-img-auto-sizes-contain-inline-css to understand the bad paths that are being crawled).

---

I have a personal website with WordPress 6.9. It includes the sourceURL comments. I have not noticed any issues and do not see problems in GSC related to the sourceURL for the property.

---

I'm not opposed to adjusting how the sourceURL comments are printed, but they still seem to provide more benefit than harm. WordPress 6.9 has been out for several months with the sourceURL comments. This is the only report I'm aware of that suggests any problems.

It would be helpful if someone with a property on GSC can confirm the issue since I'm unable to.

[westonruter]

In looking at my GSC, for the “Page indexing > Not found (404)” report, I see the following relevant URLs:

URL	Date
https://weston.ruter.net/wp-content/*	Nov 26, 2025
https://weston.ruter.net/*	Nov 25, 2025
https://weston.ruter.net/wp-content/themes/twentytwentyfive/*	Nov 13, 2025
https://weston.ruter.net/wp-admin/*	Nov 11, 2025
https://weston.ruter.net/wp-content/plugins/*	Nov 11, 2025
https://weston.ruter.net/wp-content/uploads/*	Nov 11, 2025
https://weston.ruter.net/wp-*.php	Nov 11, 2025

These all appear to be related to Speculative Loading. I don't see any for sourceURL comments, even though I have 34 on my homepage alone.

[jonoaldersonwp]

Yep, seeing the same thing; though I did see a few requests from Googlebot in my logs.

[jonsurrell]

Thank you both. I understand the issues do not seem related to sourceURL comments.

It still appears there's no compelling motivation to print them conditionally or provide mechanisms to disable them.

I think this can be closed based on further discussion in the ticket. There are no clear problems with the sourceURL comments.

[peterwilsoncc]

Given the follow up discussion, I'll close this off as maybe later. If it is found to be a major problem, it can be reopened.