Change Details

NOTE: removing the preference should only be done after the wikimedia community has been consulted. **Summary:** The "thumb size" option severely degrades performance for users who have it enabled and consumes cache capacity for little benefit. The value of the feature, when working as intended, also seems dubious. It is probably best to simply remove the option. **Context:** The "thumb size" option allows users to choose how big they see images in articles. It was presumably intended to allow users to customize page display to accommodate their screen size and available bandwidth. We currently support eight different values between 120 and 400 pixel. The thumbnail size is applied Linker class used by the wikitext parser, appropriately scaled thumbnails are generated on the fly based on the size encoded in the image URL. **Problems:** Usually, the HTML generated by the wikitext parser is cached for later re-use. This is done because parsing is relatively slow - depending on the size and complexity of the page, it can take several seconds. However, when the "thumb size" option is used, this caching becomes ineffective: since there are a relatively large number of possible options, and relatively few people use them, the chances for a "cache miss" are high (cache fragmentation). In effect, users that have "thumb size" set to a non-standard value are much more likely to hit an uncached page, forcing them to wait until the page has been rendered for them. Generating image thumbnails in many different sized also clutters the on-disk cache on the media servers with scaled copies of images that are rarely used. This is particularly true because copies scaled to all possible thumbnail sizes is generated for all images, even if they are never used in an article. Finally, the benefit of the option seems dubious. It would probably be better to adapt the thumbnail size to the screen size automatically. This would also benefit casual readers. **Usage:** An ad-hoc analysis among users of en.wikipedia.org who have edited in the last 30 days shows that about 4% of active editors have the "thumb size" option set. **Solution: ** If there is no great demand for this feature, we should simply remove it. If the feature is to be kept or replaced with a mechanism for adjusting the thumbnail size dynamically, it should be re-implemented in a way that prevents it from fragmenting the parser cache. This could be done by injecting the appropriate size parameter into the rendered output, using a mechanism similar to the one that we use for section edit links (this is currently done by the ParserOutput class).

NOTE: removing the preference should only be done after the wikimedia community has been consulted. **Summary:** The "thumb size" option severely degrades performance for users who have it enabled and consumes cache capacity for little benefit. The feature itself is probably redundant to capabilities built into modern browsers. It is probably best to simply remove the option. **Context:** The "thumb size" option allows users to choose how big they see images in articles. It was presumably intended to allow users to customize page display to accommodate their screen size and available bandwidth. We currently support eight different values between 120 and 400 pixel. The thumbnail size is applied Linker class used by the wikitext parser, appropriately scaled thumbnails are generated on upload (or on the fly if missing). **Problems:** Usually, the HTML generated by the wikitext parser is cached for later re-use. This is done because parsing is relatively slow - depending on the size and complexity of the page, it can take several seconds. However, when the "thumb size" option is used, this caching becomes ineffective: since there are a relatively large number of possible options, and relatively few people use them, the chances for a "cache miss" are high (cache fragmentation). In effect, users that have "thumb size" set to a non-standard value are much more likely to hit an uncached page, forcing them to wait until the page has been rendered for them. Generating image thumbnails in many different sized also clutters the on-disk cache on the media servers with scaled copies of images that are rarely used. This is particularly true because copies scaled to all possible thumbnail sizes is generated for all images, even if they are never used in an article (compare T106640). Finally, the benefit of the option seems redundant. It is probably be better to rely on responsive image loading mechanisms available in modern browsers via the srcset attribute. MediaWiki already supports this, see <https://www.mediawiki.org/wiki/Manual:$wgResponsiveImages>. **Usage:** An ad-hoc analysis among users of en.wikipedia.org who have edited in the last 30 days shows that about 4% of active editors have the "thumb size" option set. **Solution: ** If there is no great demand for this feature, we should simply remove it. If the feature is to be kept or replaced with a mechanism for adjusting the thumbnail size dynamically, it should be re-implemented in a way that prevents it from fragmenting the parser cache. This could be done by injecting the appropriate size parameter into the rendered output, using a mechanism similar to the one that we use for section edit links (this is currently done by the ParserOutput class).

NOTE: removing the preference should only be done after the wikimedia community has been consulted. **Summary:** The "thumb size" option severely degrades performance for users who have it enabled and consumes cache capacity for little benefit. The value of the feature, when working as intended, also seems dubiousfeature itself is probably redundant to capabilities built into modern browsers. It is probably best to simply remove the option. **Context:** The "thumb size" option allows users to choose how big they see images in articles. It was presumably intended to allow users to customize page display to accommodate their screen size and available bandwidth. We currently support eight different values between 120 and 400 pixel. The thumbnail size is applied Linker class used by the wikitext parser, appropriately scaled thumbnails are generated on the fly basedupload (or on the size encoded in the image URLe fly if missing). **Problems:** Usually, the HTML generated by the wikitext parser is cached for later re-use. This is done because parsing is relatively slow - depending on the size and complexity of the page, it can take several seconds. However, when the "thumb size" option is used, this caching becomes ineffective: since there are a relatively large number of possible options, and relatively few people use them, the chances for a "cache miss" are high (cache fragmentation). In effect, users that have "thumb size" set to a non-standard value are much more likely to hit an uncached page, forcing them to wait until the page has been rendered for them. Generating image thumbnails in many different sized also clutters the on-disk cache on the media servers with scaled copies of images that are rarely used. This is particularly true because copies scaled to all possible thumbnail sizes is generated for all images, even if they are never used in an article (compare T106640). Finally, the benefit of the option seems redundant. It is probably be better to rely on responsive image loading mechanisms available in modern browsers via the srcset attribute. MediaWiki already supports this, see <https://www.mediawiki.org/wiki/Manual:$wgResponsiveImages>. Finally, the benefit of the option seems dubious. It would probably be better to adapt the thumbnail size to the screen size automatically. This would also benefit casual readers. **Usage:** An ad-hoc analysis among users of en.wikipedia.org who have edited in the last 30 days shows that about 4% of active editors have the "thumb size" option set. **Solution: ** If there is no great demand for this feature, we should simply remove it. If the feature is to be kept or replaced with a mechanism for adjusting the thumbnail size dynamically, it should be re-implemented in a way that prevents it from fragmenting the parser cache. This could be done by injecting the appropriate size parameter into the rendered output, using a mechanism similar to the one that we use for section edit links (this is currently done by the ParserOutput class).