必死ですね。
無理な要望だと思います。 （何故1枚ずつしかアップできない仕様なのか考えたことありますか？）
貴方のリクエストは、 （貴方にその自覚がなくても）DoS攻撃させろと言っているのと同義です。
しばらく、元の仕様、一枚ずつアップロードのままやっています。「アップロード時にページをリロードしない」機能で少し便利になりましたが、やはり一度にたくさんの画像を添付したいです。どうにかできないでしょうか？
https://z.wikiwiki.jp/wikiwiki-request/topic/427/16
私のほうでも確認できました ご対応いただきありがとうございました！
恐らく今日？「アップロード後にページをリロードしない(チェックマーク)」の機能が添付ページ追加されたようです。 「1回開くための負荷」と「添付ページに更新を反映させるために再読み込みする負荷(添付自体は行われているため必須ではない)」以外は高負荷にならなくなったため、非常に助かりました。 暫定的な対応か分かりませんが、対応ありがとうございました。
https://wikiwiki.jp/p/information/view?id=10
・WikiWiki全体に季節性の荒らし行為が多発している。 ・管理人以外のユーザーには規制が必要。 ・生成AIが多い。 ・他のWikiから引用している。 ・永久にSMS認証を続けてほしい。 ・その他
リクエスト広場トップに書かれている文言を引用します。
・案件にあったタグを使用する ・提案（要望）を具体的に書く ・なぜそれが必要か理由を書く ・他のユーザーに賛同してもらえるように書く
本件は通称ニコニコ外部プレーヤーのことを指していると推測します。動画ページの共有ボタンから埋め込みコードを表示できます。※PC版限定です
WIKIWIKIの現機能は2007年に導入されているのでそうなっています。現在のニコニコ動画に直リンク禁止規定はありません。そもそも共有ボタンで配布しているURLが直リンクと変わりありません。
ニコニコ動画様は動画の直リンクを許可しておりませんので サムネイル形式の表示になります。
https://wikiwiki.jp/sample/ニコニコ動画
ご確認ありがとうございます。 ご不便をおかけしてしまい、申し訳ありませんでした。
>> 5 ありがとうございます。いくつか可能なパターンがあるのは確認できました。ただ、どのように&br;を入れると任意の行数でも意図した表が実現できるのかが分からないので、ちょっとすぐには使えなさそうですね……
なるほど、たしかに閲覧に使用するブラウザによって結果が変わるようです。最初に示した方法は、chromeやedgeでうまくいきませんでした。 以下の書き方なら、chromeでも意図した結果になりました。
|左1&br;左1|右1| |~|右2| |左2&br;左2|~| |~|右3|
空白だけの行を入れたりしてセルの縦幅を変えることで、見え方を調整できると思います。
>> 3 上記環境はGoogle Chrome (PCおよびiPad)とSafari (iPhone)で発生していたのですが、 試しにFirefoxで開いてみたら上手く表示されました。 このあたりは既知の現象なのでしょうか？
なお、Chrome環境下で https://wikiwiki.jp/sandbox/ を編集すると同様の事象が発生するので、デザインテンプレートに起因する現象ではないと思われます。
示した方法は事前に試していますし、今改めて試しても、やはりうまくいきます。そういったおかしな表示にはなりません。 もしかしたら、使用しているデザインテンプレートによっては、起きるのかもしれません。 実際にうまくいかなかったwikiの場所をハッキリさせたほうが、解決しやすいと思います。
それがですね、このような表示になってしまうのです
そう断言する根拠は何でしょう？
「再圧縮めんどくせー」「iPhone 6s・7を見殺しにできねー」という大きな障害がある割に、
https://www.microsoft.com/ja-jp/ https://studio.design/ja https://www.wix.com/
この3ページ（下2つはWeb上でホームページを作成できるサービスのトップページ）の画像のAVIF率が高いのはその需要の（潜在的な）高さを物語っています。
特に現在WebP止まりなサイトも多い一番の原因が「iPhone 6s・7を見殺しにできねー」であり、WikiWikiが対応したとして広く認知される頃にはこれの影響度合いもさらに減っていくでしょう。
リミッターを超過した画像をWebPで再圧縮して表示しています
元がJPEGの場合、これをWebPの代わりにAVIFに再圧縮すれば、より少ないストレージ容量でより粗が目立たない高品質な画像を提供できます。 特に、一部のJPEG画像（YUV444のもの）は、YUV420固定の非可逆WebPにしてしまうと特に色線の色が変わってしまいます。
AVIFはロスレス圧縮にも対応しています
全く実用的ではありません。WebPのロスレスは優秀ですので、JPEG XLが全ブラウザで解禁されるまでは、ロスレスWebP、非可逆はAVIFの流れに着実になっていくでしょう。
Windows 11のペイントも未対応な現状で「既にメジャー」は言い過ぎでしょう。
WebPも非対応ですが？
以下のように書けば、実現できます
|左1|右1| |~|右2| |左2|~| |~|右3|
ご確認・ご対応ありがとうございます。 手元でも確かに不具合修正が適用されている事を確認しました。
ご確認ありがとうございます。
こちらでの反映がうまく行われておらず、修正が適用されていない状態になっていました。 お時間を取らせてしまい、申し訳ありません。
現在は反映を完了しており、正常に動作することを確認しております。 お手数をおかけしますが、もう一度ご確認いただけますと幸いです。
下記Wikiで自分の編集履歴から動作確認しましたが、当該症状は改善していないように見られます。 お手数ですが、改めてご確認の程お願いします。 https://wikiwiki.jp/he8_hw2jo/
便乗するような形になるのと、結果として負荷が増す可能性のある提案となって申し訳ないのですが、添付ファイルのサムネイル表示も望みます。 現状、添付ファイルはファイル名でしか一覧確認できず、重複したアップロードが起こりやすい環境にあります。この点をサムネイル表示等で改善できれば、仮にページ分割して画像を管理するとしても、重複するアップロードを減らすことができるのではないかと思った次第です。
賛成します。 Wikiの種別や用途によって必要性は変わってくるとは思いますが、既に>> 5さんがいくつか例示されている通り、画像添付専用のページを用意するという方法は決してマイナーではないと思います。
当方のWikiでも同様の手法を取っており、質問主さんの「ある特定のページに画像を集中させることによる編集負荷軽減」にも大いに賛同できます。カテゴリーごとに分散してアップロードすれば良いという意見もごもっともですが、不特定多数が編集する以上、どこにどのような画像をアップロードするのか、あるいはされたのか管理することは現実的ではありません。(その結果重複してアップロードした場合、逆に負荷が増すと見なすこともできます。) そういった点では、>> 1さんが指摘されている「倉庫利用」や>> 3さんの「そのWikiでの特別な事情」には当てはまらないと思います。
また、一般的なページの利用方法であっても、極端に画像が多いページでは同様の事象が発生する可能性があり、改善を望みます。
ありがとうございます 分割の案で提案してみます
要望の背景として「負荷軽減」があると解釈しましたので、その対応の一つとしてページ分割を提案しただけなので話が逸れているとは思いません。
運営がノーと言えば現状は変わらない訳ですから、要望が通らなかった場合のことを考えて別の解決方法も検討しておいた方が良いのではと思った次第です。
ありがとうございます 私の要望とは逸れた話になってきていると思います
ページを分割しても要望である添付一覧の表示負荷軽減には長い目で見ると繋がらないと思います。
使い回しがしやすいというメリットは確かに存在しますが、 どの画像がどのページで使われているのか添付ページから確認できないというデメリットもあります。
そうした場合、どのページに影響するかわからないので迂闊に削除できず、 結果として添付ファイル数が肥大化してしまう、といった状況につながることも考えられます。
以上を踏まえると、やはり1ページに集約させるのではなくある程度ページ分割して運用するべきかと思います。
匿名で編集できるという前提でのWikiだと添付ページを分割するのは今後のことを考えると破綻してしまう運用になると思うので難しいです
画像の種類を属性などでジャンル分けして、 画像添付用ページを分割してみるのはどうでしょうか。
具体的なことが分からないので単純計算ですが、 例えば画像添付用ページを10分割すれば、 表示負荷も1/10になります。
ご不便をおかけしており、申し訳ございません。
ご指摘いただいた不具合につきまして、対応が完了いたしました。 お手数をおかけいたしますが、ご確認いただけますでしょうか。
なお、すでに登録されている規制ルールにつきましては、追加できませんのでご了承ください。
直ったこと確認しました！ 対応して頂きありがとうございました。
ご連絡ありがとうございます。
上記の不具合対応しました。 ご迷惑をおかけして申し訳ありません。
確認用リンク https://www.yahoo.co.jp/
ファイル添付ページの表示負荷を下げてほしいという意見に賛成します。 WIKIWIKIのトップにある「みんなが評価しているwiki」をさっと見たところ、トピック主さんが仰っている添付ページを統一してwiki内で使いやすくする、という方法はよくあるようです。 こうした使用方法はwikiに添付する画像ファイル数が少なくて済むため、むしろ全体としては容量の削減になるはずです。
該当サイトに問い合わせてください。WIKIWIKI運営には何の関係もないサイトです。
コメントありがとうございます。 利用しているWikiのゲームの特性上、同じ画像を複数ページで使いまわしているような状況で、そうではない使い方になるとページごとに同じ画像を添付していくような形になってしまい、管理上問題が発生してしまいます。 ※アイコンや画像、仕様などがアプデなどで頻繁に変わり、ページごとで最新の画像が使われたり使われなかったりが発生しました。
画像やファイルを保管するためだけの倉庫としては使っていません。
画像添付専用のページを作り、そこに大量の画像をアップして運用するというのは、 「そのWIKIでの特別な事情」に該当するのではと思います。
>> 2「ページ名指定が固定になって編集が楽」という意見ですが、 attachを使用すればページ名指定は不要ですし、 複数ページで同じ画像の使い回しを大量に行っているということであれば、 やはりそれも「そのWIKIでの特別な事情」に該当しそうです。
「複数のページにバラけさせるのは不便かつ煩雑」という意見も、 あまり一般的とは思えません。 私自身について言えば、同じ画像を複数ページで使い回すことは基本的にないため、 ページごとに使用画像を添付する方がシンプルで分かり易く、 むしろこちらが一般的でなないかと思います。
このように、どちらが使い易いと感じるかは個人の主観に左右される上、 「複数のページにバラけさせるのは不便」と言いつつ、 その運用で逆に不便が生じているからトピックを立てている訳で、 矛盾が生じています。
追加情報です。 本トピック投稿後、規制ユーザーを追加する機会が何回かありましたが、再現率は100％でした。
また、追加順ですが、下記の順に1つずつ追加される状況となっている模様です。 SMSトークン→ホスト→クッキー
起票よりそろそろ1ヶ月程度経過しますが、状況はどうなっているでしょうか？ 管理者がこの不具合に気付いていないと、荒らし対策が十分に機能しない可能性が考えられます。可及的速やかな対応を望みます。
賛成です。 自動読み込み無し、最新○件まで表示(+もっと見る)、非表示や格納、などで負荷を軽減してほしいです。 添付ファイルの確認をするために添付ページを開くのは稀ですし、毎回全てを表示させる必要はありません。
ページ名指定が固定になって編集が楽なので、用途毎などで特定のページに纏めたほうが運用する上で都合が良いです。 1ページに纏まってるから倉庫(保管用途)のように見えるだけで、倉庫(運用用途)とは異なります。 纏めてもバラけさせてもwiki全体のファイル総量は変わりませんし、禁止しているのはあくまで保管用途です。 添付ページの表示負荷を軽減するためだけに、意図的に複数のページにバラけさせるのは不便かつ煩雑です。 現状特定のページに纏めているwikiで実行すると、再添付とリンク調整で膨大な手間が掛かります。 特定のページに添付する方針になっている場合、個人の意見でそれを覆すのは非常に難しいと思われます。
自分も困っている側なので、代案や個人で対処可能な方法があれば教えていただきたいです。
それは運用方法に問題があると考えます。
以下、「本サービスに関する利用のルール」より引用
コンテンツ・広告の取り扱いに関する内容 記事に使用しない画像やファイルを大量にWIKIにアップロードして保管する行為は禁止です。 ファイルの保管にはGoogleドライブなどの便利な外部サービスをご利用ください。 ページ内に大量のYouTubeやXなどの外部サービスを埋め込む行為も禁止です。 これにより、サーバー負荷や閲覧体験の低下を招く可能性があります。 倉庫としての利用は、画像やファイルを保存するためだけの使用です。 一方、まとめ記事は情報を整理し、読者に有益な形で提供することを目的としています。WIKIはコンテンツ作成に使用されるべきものであり、 画像やファイルの保管庫としての使用は適していません。
正当な理由があるとはいえ、実質的に倉庫と同じような使われ方になってしまっていますので 大量の画像ファイルを1ページ内に添付するのは適切ではないと言えます。
従って、改善要望ではなく運用方法の見直しをするべきかと思います。
WebPよりもさらにファイルサイズを抑えられるため、wikiの軽量化に役立つと考えています。
単にファイルサイズを小さくするだけならJPEGでもWebPでもできますので、 画質を保ったまま圧縮率を大きくできるという意味だと思いますが、 現在のwikiwikiは、リミッターを超過した画像をWebPで再圧縮して表示していますので、 これに引っかかった場合、PNGだろうがWebPだろうがAVIFだろうが皆同じ画質になってしまうので、 AVIFが使えればより高画質になるという単純な話ではありません。
逆にAVIF→WebP変換で発生する負荷がマイナス要因となる可能性もあります。 （変換時の負荷の高さがAVIFのデメリットの一つとされています）
AVIFが既にメジャーな形式であり
少なくとも自分はそう思っていません。 画像関連のフリーソフトで対応済みなのは一部だけですし、 Windows 11のペイントも未対応な現状で「既にメジャー」は言い過ぎでしょう。 AVIFはロスレス圧縮にも対応していますので、本当にメジャーになれば、 JPEG、PNG程には普及していないWebPは事実上駆逐されると思います。
必死ですね。
無理な要望だと思います。
（何故1枚ずつしかアップできない仕様なのか考えたことありますか？）
貴方のリクエストは、
（貴方にその自覚がなくても）DoS攻撃させろと言っているのと同義です。
しばらく、元の仕様、一枚ずつアップロードのままやっています。「アップロード時にページをリロードしない」機能で少し便利になりましたが、やはり一度にたくさんの画像を添付したいです。どうにかできないでしょうか？
https://z.wikiwiki.jp/wikiwiki-request/topic/427/16
私のほうでも確認できました
ご対応いただきありがとうございました！
恐らく今日？「アップロード後にページをリロードしない(チェックマーク)」の機能が添付ページ追加されたようです。
「1回開くための負荷」と「添付ページに更新を反映させるために再読み込みする負荷(添付自体は行われているため必須ではない)」以外は高負荷にならなくなったため、非常に助かりました。
暫定的な対応か分かりませんが、対応ありがとうございました。
https://wikiwiki.jp/p/information/view?id=10
・WikiWiki全体に季節性の荒らし行為が多発している。
・管理人以外のユーザーには規制が必要。
・生成AIが多い。
・他のWikiから引用している。
・永久にSMS認証を続けてほしい。
・その他
リクエスト広場トップに書かれている文言を引用します。
本件は通称ニコニコ外部プレーヤーのことを指していると推測します。動画ページの共有ボタンから埋め込みコードを表示できます。※PC版限定です
WIKIWIKIの現機能は2007年に導入されているのでそうなっています。現在のニコニコ動画に直リンク禁止規定はありません。そもそも共有ボタンで配布しているURLが直リンクと変わりありません。
https://wikiwiki.jp/sample/ニコニコ動画
ご確認ありがとうございます。
ご不便をおかけしてしまい、申し訳ありませんでした。
>> 5
ありがとうございます。いくつか可能なパターンがあるのは確認できました。ただ、どのように&br;を入れると任意の行数でも意図した表が実現できるのかが分からないので、ちょっとすぐには使えなさそうですね……
なるほど、たしかに閲覧に使用するブラウザによって結果が変わるようです。最初に示した方法は、chromeやedgeでうまくいきませんでした。
以下の書き方なら、chromeでも意図した結果になりました。
空白だけの行を入れたりしてセルの縦幅を変えることで、見え方を調整できると思います。
>> 3
上記環境はGoogle Chrome (PCおよびiPad)とSafari (iPhone)で発生していたのですが、
試しにFirefoxで開いてみたら上手く表示されました。
このあたりは既知の現象なのでしょうか？
なお、Chrome環境下で https://wikiwiki.jp/sandbox/ を編集すると同様の事象が発生するので、デザインテンプレートに起因する現象ではないと思われます。
示した方法は事前に試していますし、今改めて試しても、やはりうまくいきます。そういったおかしな表示にはなりません。
もしかしたら、使用しているデザインテンプレートによっては、起きるのかもしれません。
実際にうまくいかなかったwikiの場所をハッキリさせたほうが、解決しやすいと思います。
それがですね、このような表示になってしまうのです
「再圧縮めんどくせー」「iPhone 6s・7を見殺しにできねー」という大きな障害がある割に、
https://www.microsoft.com/ja-jp/
https://studio.design/ja
https://www.wix.com/
この3ページ（下2つはWeb上でホームページを作成できるサービスのトップページ）の画像のAVIF率が高いのはその需要の（潜在的な）高さを物語っています。
特に現在WebP止まりなサイトも多い一番の原因が「iPhone 6s・7を見殺しにできねー」であり、WikiWikiが対応したとして広く認知される頃にはこれの影響度合いもさらに減っていくでしょう。
元がJPEGの場合、これをWebPの代わりにAVIFに再圧縮すれば、より少ないストレージ容量でより粗が目立たない高品質な画像を提供できます。
特に、一部のJPEG画像（YUV444のもの）は、YUV420固定の非可逆WebPにしてしまうと特に色線の色が変わってしまいます。
全く実用的ではありません。WebPのロスレスは優秀ですので、JPEG XLが全ブラウザで解禁されるまでは、ロスレスWebP、非可逆はAVIFの流れに着実になっていくでしょう。
WebPも非対応ですが？
以下のように書けば、実現できます
ご確認・ご対応ありがとうございます。
手元でも確かに不具合修正が適用されている事を確認しました。
ご確認ありがとうございます。
こちらでの反映がうまく行われておらず、修正が適用されていない状態になっていました。
お時間を取らせてしまい、申し訳ありません。
現在は反映を完了しており、正常に動作することを確認しております。
お手数をおかけしますが、もう一度ご確認いただけますと幸いです。
ご確認ありがとうございます。
下記Wikiで自分の編集履歴から動作確認しましたが、当該症状は改善していないように見られます。
お手数ですが、改めてご確認の程お願いします。
https://wikiwiki.jp/he8_hw2jo/
便乗するような形になるのと、結果として負荷が増す可能性のある提案となって申し訳ないのですが、添付ファイルのサムネイル表示も望みます。
現状、添付ファイルはファイル名でしか一覧確認できず、重複したアップロードが起こりやすい環境にあります。この点をサムネイル表示等で改善できれば、仮にページ分割して画像を管理するとしても、重複するアップロードを減らすことができるのではないかと思った次第です。
賛成します。
Wikiの種別や用途によって必要性は変わってくるとは思いますが、既に>> 5さんがいくつか例示されている通り、画像添付専用のページを用意するという方法は決してマイナーではないと思います。
当方のWikiでも同様の手法を取っており、質問主さんの「ある特定のページに画像を集中させることによる編集負荷軽減」にも大いに賛同できます。カテゴリーごとに分散してアップロードすれば良いという意見もごもっともですが、不特定多数が編集する以上、どこにどのような画像をアップロードするのか、あるいはされたのか管理することは現実的ではありません。(その結果重複してアップロードした場合、逆に負荷が増すと見なすこともできます。)
そういった点では、>> 1さんが指摘されている「倉庫利用」や>> 3さんの「そのWikiでの特別な事情」には当てはまらないと思います。
また、一般的なページの利用方法であっても、極端に画像が多いページでは同様の事象が発生する可能性があり、改善を望みます。
ありがとうございます
分割の案で提案してみます
要望の背景として「負荷軽減」があると解釈しましたので、その対応の一つとしてページ分割を提案しただけなので話が逸れているとは思いません。
運営がノーと言えば現状は変わらない訳ですから、要望が通らなかった場合のことを考えて別の解決方法も検討しておいた方が良いのではと思った次第です。
ありがとうございます
私の要望とは逸れた話になってきていると思います
ページを分割しても要望である添付一覧の表示負荷軽減には長い目で見ると繋がらないと思います。
使い回しがしやすいというメリットは確かに存在しますが、
どの画像がどのページで使われているのか添付ページから確認できないというデメリットもあります。
そうした場合、どのページに影響するかわからないので迂闊に削除できず、
結果として添付ファイル数が肥大化してしまう、といった状況につながることも考えられます。
以上を踏まえると、やはり1ページに集約させるのではなくある程度ページ分割して運用するべきかと思います。
匿名で編集できるという前提でのWikiだと添付ページを分割するのは今後のことを考えると破綻してしまう運用になると思うので難しいです
画像の種類を属性などでジャンル分けして、
画像添付用ページを分割してみるのはどうでしょうか。
具体的なことが分からないので単純計算ですが、
例えば画像添付用ページを10分割すれば、
表示負荷も1/10になります。
ご不便をおかけしており、申し訳ございません。
ご指摘いただいた不具合につきまして、対応が完了いたしました。
お手数をおかけいたしますが、ご確認いただけますでしょうか。
なお、すでに登録されている規制ルールにつきましては、追加できませんのでご了承ください。
直ったこと確認しました！
対応して頂きありがとうございました。
ご連絡ありがとうございます。
上記の不具合対応しました。
ご迷惑をおかけして申し訳ありません。
確認用リンク
https://www.yahoo.co.jp/
ファイル添付ページの表示負荷を下げてほしいという意見に賛成します。
WIKIWIKIのトップにある「みんなが評価しているwiki」をさっと見たところ、トピック主さんが仰っている添付ページを統一してwiki内で使いやすくする、という方法はよくあるようです。
こうした使用方法はwikiに添付する画像ファイル数が少なくて済むため、むしろ全体としては容量の削減になるはずです。
https://wikiwiki.jp/eft/img
https://wikiwiki.jp/nijisanji/ロゴ
https://wikiwiki.jp/genshinwiki/画像
https://wikiwiki.jp/poke_sleep/アイコン
https://wikiwiki.jp/splatoon3mix/icon
該当サイトに問い合わせてください。WIKIWIKI運営には何の関係もないサイトです。
コメントありがとうございます。
利用しているWikiのゲームの特性上、同じ画像を複数ページで使いまわしているような状況で、そうではない使い方になるとページごとに同じ画像を添付していくような形になってしまい、管理上問題が発生してしまいます。
※アイコンや画像、仕様などがアプデなどで頻繁に変わり、ページごとで最新の画像が使われたり使われなかったりが発生しました。
画像やファイルを保管するためだけの倉庫としては使っていません。
画像添付専用のページを作り、そこに大量の画像をアップして運用するというのは、
「そのWIKIでの特別な事情」に該当するのではと思います。
>> 2「ページ名指定が固定になって編集が楽」という意見ですが、
attachを使用すればページ名指定は不要ですし、
複数ページで同じ画像の使い回しを大量に行っているということであれば、
やはりそれも「そのWIKIでの特別な事情」に該当しそうです。
「複数のページにバラけさせるのは不便かつ煩雑」という意見も、
あまり一般的とは思えません。
私自身について言えば、同じ画像を複数ページで使い回すことは基本的にないため、
ページごとに使用画像を添付する方がシンプルで分かり易く、
むしろこちらが一般的でなないかと思います。
このように、どちらが使い易いと感じるかは個人の主観に左右される上、
「複数のページにバラけさせるのは不便」と言いつつ、
その運用で逆に不便が生じているからトピックを立てている訳で、
矛盾が生じています。
追加情報です。
本トピック投稿後、規制ユーザーを追加する機会が何回かありましたが、再現率は100％でした。
また、追加順ですが、下記の順に1つずつ追加される状況となっている模様です。
SMSトークン→ホスト→クッキー
起票よりそろそろ1ヶ月程度経過しますが、状況はどうなっているでしょうか？
管理者がこの不具合に気付いていないと、荒らし対策が十分に機能しない可能性が考えられます。可及的速やかな対応を望みます。
賛成です。
自動読み込み無し、最新○件まで表示(+もっと見る)、非表示や格納、などで負荷を軽減してほしいです。
添付ファイルの確認をするために添付ページを開くのは稀ですし、毎回全てを表示させる必要はありません。
ページ名指定が固定になって編集が楽なので、用途毎などで特定のページに纏めたほうが運用する上で都合が良いです。
1ページに纏まってるから倉庫(保管用途)のように見えるだけで、倉庫(運用用途)とは異なります。
纏めてもバラけさせてもwiki全体のファイル総量は変わりませんし、禁止しているのはあくまで保管用途です。
添付ページの表示負荷を軽減するためだけに、意図的に複数のページにバラけさせるのは不便かつ煩雑です。
現状特定のページに纏めているwikiで実行すると、再添付とリンク調整で膨大な手間が掛かります。
特定のページに添付する方針になっている場合、個人の意見でそれを覆すのは非常に難しいと思われます。
自分も困っている側なので、代案や個人で対処可能な方法があれば教えていただきたいです。
それは運用方法に問題があると考えます。
以下、「本サービスに関する利用のルール」より引用
正当な理由があるとはいえ、実質的に倉庫と同じような使われ方になってしまっていますので
大量の画像ファイルを1ページ内に添付するのは適切ではないと言えます。
従って、改善要望ではなく運用方法の見直しをするべきかと思います。
単にファイルサイズを小さくするだけならJPEGでもWebPでもできますので、
画質を保ったまま圧縮率を大きくできるという意味だと思いますが、
現在のwikiwikiは、リミッターを超過した画像をWebPで再圧縮して表示していますので、
これに引っかかった場合、PNGだろうがWebPだろうがAVIFだろうが皆同じ画質になってしまうので、
AVIFが使えればより高画質になるという単純な話ではありません。
逆にAVIF→WebP変換で発生する負荷がマイナス要因となる可能性もあります。
（変換時の負荷の高さがAVIFのデメリットの一つとされています）
そう断言する根拠は何でしょう？
少なくとも自分はそう思っていません。
画像関連のフリーソフトで対応済みなのは一部だけですし、
Windows 11のペイントも未対応な現状で「既にメジャー」は言い過ぎでしょう。
AVIFはロスレス圧縮にも対応していますので、本当にメジャーになれば、
JPEG、PNG程には普及していないWebPは事実上駆逐されると思います。