[wp-trac] [WordPress Trac] #64369: Disable sourceURL Comments

[WordPress Trac]

#64369: Disable sourceURL Comments
-------------------------------+-------------------------------------------
 Reporter:  anton7249          |       Owner:  (none)
     Type:  enhancement        |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Script Loader      |     Version:  6.9
 Severity:  normal             |  Resolution:
 Keywords:  2nd-opinion close  |     Focuses:  javascript, css, performance
-------------------------------+-------------------------------------------
Changes (by jonsurrell):

 * keywords:  2nd-opinion => 2nd-opinion close
 * focuses:  javascript, css => javascript, css, performance


Comment:

 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:
 [https://make.wordpress.org/core/2025/12/05/coding-standard-proposal-
 allow-the-use-of-the-php-short-echo-tag/ 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.
 [https://source.chromium.org/chromium/v8/v8.git/+/main:src/parsing
 /scanner-inl.h;l=468-479;drc=8cd6e524522115f99f8666df71d98609325b0269
 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)]. [https://v8.dev/blog/scanner 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64369#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform