行頭にスペースなり適当なエスケープ文字列を入れて一旦保存。 プラグインとして認識させなけれはページ名に置換される。 改めて編集してエスケープ文字を取り除く。
「メニューにしか使ったことがない」と言うように、むしろ特殊な用途なので、tablesortのようにそれを適用したい箇所にだけ{{}}で上下囲むという書き方でも間に合います。
自分の関心では、サイドメニュー以外に上の要求を覚えないので、コンパネから一括ですとメニュー編集を凍結してしまうこととだいたい同じです。その必要は感じません。
他からの移植について触れてしまったので挙げると、 #region(close,remember,テキスト) rememberと書き足すことでコントロールしている例があります。
また、 #treemenu(flag=ex) flag=exとかいう、いかがわしい呪文で指示している例もありますが、できるなら読んでそれと意味のわかる文字にしてほしいです。時間が空くと忘れていちいちマニュアルに戻っていた。
同様の上限にかかる件に最近当たりましたので報告します。それなりに重要なテーマを含んでいると思います。まず、自分の編集者/管理者としての関心は、テキスト情報の収集、整理編纂、その快適な閲覧に集中しており、情報をまとめる記事を作成し関連項目への誘導整理を行う際に「何事かをランダムに表示すること」に興味が寄りません。
randommesについては存在は知っていましたが、所詮おまけのお遊びの機能だと思っていました。Wiki上でゲームや何かのシミュレーターを作る必要もないです。ですが、このたび扱った内容が「多数のキャラクター(人物)のプロフィール」であったことと、そのプロフィール作成の作業中にキャラクターのポートレートに当たる画像を挿むように進んだとき、多数の中から無作為に選んだワンショットをちら見せ、そういうものを常時表示させておくことで、閲覧者の関心を惹く目的ではそこそこ意味がある。固有の利用形態だと思いました。
それでヘッダエリアに入れてみたところ、なかなか面白い。「まず目を引き、最初に読み始める興味関心をそこから始める」意味で、これは使えます。
作成中なりに8000件のようなシャッフルをのほほんと想像してしまいましたが、やってみると早速500上限に当たりました。案の定かと臍を噛んだものの、管理者としては上の方針であり、このコンテンツ自体サイトの主目的では絶対になく、「本当に必要か」といえば不要なことはあらためて言います。また、上限があることについてはWIKIWIKI運営の方の通りにすぐに腑に落ちました。
「500」という具体的な数については判断できないものの、判断できないものは運営の方針にお任せすればよく、制限があればその制限にしたがうべきとの考えに至り、その後は500以内でシャッフルの条件を適宜可変にする形に収めています。8000を空想し、実用的に要るのは300くらいでした。その際に意識に昇ったのは、情報の編集・編纂は常にその操作より、操作を行う意図が重要という基本です。扱う対象が多ければ何ブロックかに分けてそこそこの数ごとに仕分けるようにすれば、その仕分けの意図を考え直す機会にもなるかと思います。実際に馬鹿げた操作をしかけてから上限に気づくので、上限数についてはマニュアルに載せておいてください。
AVIF image format につきまして、検討いたします。
WikiWikiはアップロードサイズの容量制限が厳しいため、数秒間のショート動画を掲載する際にこのような高圧縮形式に対応していただけていると非常に助かります。
本来の目的がショート動画の埋め込みなら別の要望になると思います。
ページ内の全ての開閉記録を保持してページ遷移後、記録をページに反映させる機能でよろしいでしょうか？ 以下の項目を踏まえて引き続き議論いただけたら幸いです。
動的に動かす機能はコストがかかります。 WIKIの機能として本当に必要なのかも踏まえて、引き続き議論をお願いします。
同様のトピックが作成されましたので、 こちらで議論をお願いします。 https://zawazawa.jp/wikiwiki-request/topic/188
同様のトピックがありましたのでまとめます。
プラグインの引数にプラグインを指定することは非推奨です。
都度ページ名をコピペする手間を省けるので、置換されるようになると嬉しいです。
本来のやりたいことを別のトピックで要望として、議論していただけたら幸いです。
例えば1500x1500でアップロードした画像もサイズを100x100に指定したら100x100の画像になって転送量を削減できるということですか？
はい、極端な例ですとそうなります。 実際は妥当な画像サイズに最適化されます。
また、一度読み込んだ画像はキャッシュに保存されブラウザ更新してもキャッシュから読み込まれますか？
はい、ブラウザのキャッシュがあればそちらから読み込みます。
画像の最適については、以下のトピックもご確認ください。
表示画像の最適化について https://zawazawa.jp/wikiwiki-request/topic/184
どのような場面で表組の枠線を消したいのでしょうか？ レイアウトでの使用なら、別の要望になると思います。
例えば1500x1500でアップロードした画像もサイズを100x100に指定したら100x100の画像になって転送量を削減できるということですか？ また、一度読み込んだ画像はキャッシュに保存されブラウザ更新してもキャッシュから読み込まれますか？
「最近更新されたWiki」は必要ないからやめてくれということなのか、「一日単位での追記件数」ランキングを作ってくれというのか 結局、何を要望しているのか分かりにくいです。
以下は昔のWIKIWIKIのよくある質問を抜粋したものです。
WIKIWIKI.jp*トップの「最近更新されたWIKI」に載らないようにするにはどうすればいいの？ 現在「最近更新されたWIKI」に載らないようにする設定はございません。 情報公開された開放的な形での運用となりますので、閉鎖的なコミュニティの使用には向いておりません。 （全体的に大手検索エンジンに比較的早く上位表示されているようです。）
WIKIWIKI.jp*トップの「最近更新されたWIKI」に載らないようにするにはどうすればいいの？
現在「最近更新されたWIKI」に載らないようにする設定はございません。 情報公開された開放的な形での運用となりますので、閉鎖的なコミュニティの使用には向いておりません。 （全体的に大手検索エンジンに比較的早く上位表示されているようです。）
これを見て「最近更新されたWIKI」って検索サイトのクローラーに見つけてもらうためにあるんじゃないかと勝手に思ってます。 更新しても数時間で埋もれてしまうのでタイミングが合わなければだめですけどね。 自分の作ったWikiも一切宣伝してませんが訪問者が来るようになりましたし。 関係ないですが、WIKIWIKIにはいくつのWikiがあるんでしょうね。どこかで公表してましたっけ？
話がそれましたが「ネットに存在するあらゆるWikiに関心を持ちながらその通知を見ている人」とはまさに「検索サイトのクローラー」なんじゃないでしょうか。(人じゃないけど) ということで「最近更新されたWIKI」は必要だと思いますよ。
こちらの希望としてはrecent・zrecentと全く同じ表示ですので、>> 2はその場しのぎとしてはありかなぁ、という印象です。 類似の話題で言及されている通りlsxは重めのものですので、長年愛用して数万ページに達しているとまた話は別なのかなと。 zawazawaのより手軽な利用方法要望については別トピックで議論したほうがいいと思います。
Wiki編集ってボランティア活動の一種だと思いますが、その行為を評価するのって必要なんですか？というか確認できる仕組みを求めてることに強い疑問を感じます。 そちらが積極的に編集に参加していて、他の編集者のアクティビティを見たいという意見なら分からなくもないですが、編集に参加しない人側からの視点での意見ということであれば取り下げたほうがいいです。
調べたらでてくるボランティアの4原則などを一度見てみてください。
ご対応ありがとうござます。Headerが意図したとおり表示されることを確認しました。
この不具合の対応で上記の現象が発生しました。🙇♂️
大変遅くなり申し訳ございません。 :Header でも flexbox が動作するように対応いたしました。
実は :Header や MenuBar はスタイルに「特別ルール」が実装されています。 例えば、:Header は表組の枠線が表示されません。
昔からレイアウトを組む方法として表がよく使われてきました。 :Header では 表組にデータを入れる用途で使われないため、レイアウト専用として枠線を消していました。
このガラケー時代の名残が原因で flexbox が動作しておりませんでした。 今は flexbox があるので、不具合の原因になりやすい :Header の「特別ルール」を無くすことを検討しております。 もし、:Header で表組でレイアウトを組んでおられる方は flexbox でレイアウトを組むようにしてください。
対応いたしました。 大変ご迷惑をおかけいたしました。🙇♂️
【不具合解消のお知らせ】不具合の原因となっている箇所を修正し、2023年4月19日(水)20時43分に不具合が解消されました。大変ご迷惑をおかけしました。— WIKIWIKI【公式】 (@WIKIWIKI_Japan) April 19, 2023
【不具合解消のお知らせ】不具合の原因となっている箇所を修正し、2023年4月19日(水)20時43分に不具合が解消されました。大変ご迷惑をおかけしました。
時間を置いて元の内容を記述したところ、直りました。 一時的に発生した不具合の模様です。
ご不便をおかけして申し訳ございません。 対応しておりますので、今しばらくお待ちください。
【不具合のお知らせ】2023年4月19日(水)20時20分頃から、レイアウトが一部崩れる現象が発生しております。現在、調査しております。ご不便をおかけして申し訳ございません。今しばらくお待ちください。— WIKIWIKI【公式】 (@WIKIWIKI_Japan) April 19, 2023
【不具合のお知らせ】2023年4月19日(水)20時20分頃から、レイアウトが一部崩れる現象が発生しております。現在、調査しております。ご不便をおかけして申し訳ございません。今しばらくお待ちください。
ChromeとFirefoxで瞬時に表示されることを確認しました。 ご対応ありがとうございました。
申し訳ございません。 アイコンが常時表示される不具合が発生しておりました。 修正し、正常に動作するようにいたしました。
特定の文字列の「表記ゆれ文字の対応処理」でブラウザに負荷がかかっていたようです。 この機能を無効化して対処いたしました。
共有ありがとうございます。 結論から申し上げますと、負荷は問題ないと思われます。
外部画像も最適化を行っています。 実際にインラインで表示されている画像は最適化済みです。(413KB) もとの画像サイズと比較して十分最適化されています。
相手側(cdn.discordap)へのアクセスはインライン表示では、ほぼゼロです。 クリック時に拡大表示させた時だけ相手側のCDNから直接読み込みます。(6.6MB) ここだけ相手側とユーザー側に負荷(転送量含む)が発生します。
相手側の画像は、閉じられた空間でのアクセスを想定されていると思いますので、一度ご確認いただけたらと思います。
参考: 「外部サービスの画像コンテンツの貼り付けについて」
もし回避できる方法があればご教示いただければ対応いたします。
例えばこのページの上部に設置している画像になります。 現在は閲覧数は落ち着いてますが、6月～8月くらいになると閲覧数が爆上がりします。 https://wikiwiki.jp/eft/CUSTOMS
別の機能で提供できることもあるので、 その機能がどのような目的で必要なのかを教えていただければと思います。
上記の現象を確認しました。 調査いたしますので、今しばらくお待ちください。 ご不便をおかけして申し訳ございません。
具体的にどの画像でしょうか？ 掲載しているページのURLと表示させている画像を教えてください。
同感です。 フラッシュ機能は、使い方によっては、かつてのポケモンショック同様、 閲覧者に対し光過敏性発作を引き起こしかねません。 チカチカ鬱陶しいだけですし、個人的にも要りません。
点滅文字は設定次第で目にダメージが入ります。 そもそもスクロール文字を実装しているのは昔からの名残であると認識しており、その観点からも新たな追加は不要であると思っています。
どうしてもというのであれば、フェードイン/フェードアウトかつ、フェードインからフェードアウトまで3秒以上など、目に優しい形で制限するならば構いません。
応答不能になる例のリンク先は、ほんらいハイライトされるべきURLの文字列がハイライトされませんね。 タスクマネージャを見ていると表示が完了するまでブラウザーのCPU使用率が高いままです。 HTML Convert timeは短いことから、クライアント側の処理が上手く行ってないように見えます。 ただ普通にブラウザー側の機能の文字列検索を使えば一瞬で対象がハイライトされます。wikiwikiがhtmlに仕込ませてるscript処理になにか問題があるのだと思います。
詳しく検証してみました。
応答不能になる条件 同じページに後半(末尾)が異なる文字列がある 文字列にアルファベットが多い場合(数字のみでは起こらない)
ページの例
HHHHHGGGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0 (全41文字) HHHHHGGGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA1 (全41文字)
HHHHHGGGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0 (全41文字)
HHHHHGGGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA1 (全41文字)
Chromeで「これらのキーワードがハイライトされています」が表示されるまでの時間は ”FFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(31文字)の場合6秒 ”GFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(32文字)の場合13秒 ”GGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(33文字)の場合32秒 ”GGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(34文字)の場合1分39秒 ”GGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(35文字)の場合2分15秒 と1文字増えるごとにかなり時間が伸びました。 (途中で「ページが応答しません」となっても放置した場合)
なお、どちらの行にも共通する ”HHHHHGGGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA”(40文字)の場合は瞬時に表示されます。
運営の方に質問があるのですが、ディスコードなど外部に添付した画像をWikiに表示させたページがたくさん閲覧された場合は負担をかけることになるのでしょうか？ なるべく高画質なものを添付したい考えがありますので、Wikiのサイズ制限を回避するような形をとっておりました。
もし負担になるようでしたら、半年ごとで1日あたり10000~30000閲覧くらいあるページがいくつかあるので今まで結構な負担をかけてしまってたかなと懸念しております。 もし回避できる方法があればご教示いただければ対応いたします。
ご返信ありがとうございます。 再現性のある現象のようで安心しました。修正を期待しております。
ご回答ありがとうございます。参考にさせていただきます。
ダメもとでsvg(309KB)を試してみたところ、最適化されないことが分かりました。
申し訳ございません。 写真のような解像度のSVGは非推奨とさせていただきます。
ということですが、具体的にはどの解像度でどのくらいのサイズが理想なのでしょうか？ 今後も同じように画像を圧縮してほしくない際の参考にもなると思うので、共有いただければ幸いです。
パスする基準について、参考にしてください。 インライン表示の解像度とそのリミットサイズです。
32x32 6.87KB 50x50 8.35KB 200x200 25.29KB 400x400 54.97KB 500x500 71.79KB 800x600 107.06KB 800x800 128.00KB
sharp_yuv オプションは検討いたします。
色の劣化に限っては、非可逆圧縮時に-sharp_yuvオプション（より正確にRGBからYUVへの変換を行う）をつけることでかなりマシになるようです。
そのようなオプションがあったのですね。 自分が使用しているフリーの画像コンバーター(Converseen)には無かったので盲点でした。 88KBで試したところ、無事最適化をパス致しました。
なので、一先ずこのトピックは解決済みとさせていただきます。 るーさん、運営の方、ご協力いただいた皆様ありがとうございました。
ファイルサイズの大きいsvgでは画像圧縮の本来の目的である「転送量の削減」を悪化させてしまうので、やめておいた方が良いでしょう……。
仰る通りです。勿論止めにします。
WIKIWIKI側の自動圧縮でsharp_yuvオプションを使うのはどうでしょうか？
賛成です。使えるなら是非お願い致します。
色の劣化に限っては、非可逆圧縮時に-sharp_yuvオプション（より正確にRGBからYUVへの変換を行う）をつけることでかなりマシになるようです。 https://squoosh.app/ では「Sharp RGB→YUV conversion」にチェックを入れることで使えます。 ただ、圧縮に掛かる時間が少し長くなり、ファイルサイズも通常より少し増えます。
参考までにSquooshでEffort=6、Quality=70、Sharp RGB→YUV conversionにチェックして圧縮した画像です (約59KB)。パッと見で違いが分からないくらいにはなったかと思います。
スレ主さんはおそらく色の劣化が気になっていらっしゃると思うので、自前で前述の非可逆圧縮をするか、WIKIWIKI側の自動圧縮で前述のオプションを使うのはどうでしょうか？
個人的には文字色が明らかに薄くなっている以外では、他の劣化はほぼ気にならないレベルですし。
この画像（940x540pxの24bit画像）を89KB以下にロスレス圧縮する方法
こちらでlibwebp 1.3.0を使って最大のロスレス圧縮をしてみましたが、157.382KBでした。 画像の可逆圧縮ではwebpが最強だと思うので、これ以上小さくしたいなら非可逆圧縮するしかなさそうですね。
svg(309KB)を試してみたところ、最適化されないことが分かりました
最後にWIKIWIKI運営さんにおききしたいのですが、
解像度に見合った最適解のファイルサイズがある
行頭にスペースなり適当なエスケープ文字列を入れて一旦保存。
プラグインとして認識させなけれはページ名に置換される。
改めて編集してエスケープ文字を取り除く。
「メニューにしか使ったことがない」と言うように、むしろ特殊な用途なので、tablesortのようにそれを適用したい箇所にだけ{{}}で上下囲むという書き方でも間に合います。
自分の関心では、サイドメニュー以外に上の要求を覚えないので、コンパネから一括ですとメニュー編集を凍結してしまうこととだいたい同じです。その必要は感じません。
他からの移植について触れてしまったので挙げると、
#region(close,remember,テキスト)
rememberと書き足すことでコントロールしている例があります。
また、
#treemenu(flag=ex)
flag=exとかいう、いかがわしい呪文で指示している例もありますが、できるなら読んでそれと意味のわかる文字にしてほしいです。時間が空くと忘れていちいちマニュアルに戻っていた。
同様の上限にかかる件に最近当たりましたので報告します。それなりに重要なテーマを含んでいると思います。まず、自分の編集者/管理者としての関心は、テキスト情報の収集、整理編纂、その快適な閲覧に集中しており、情報をまとめる記事を作成し関連項目への誘導整理を行う際に「何事かをランダムに表示すること」に興味が寄りません。
randommesについては存在は知っていましたが、所詮おまけのお遊びの機能だと思っていました。Wiki上でゲームや何かのシミュレーターを作る必要もないです。ですが、このたび扱った内容が「多数のキャラクター(人物)のプロフィール」であったことと、そのプロフィール作成の作業中にキャラクターのポートレートに当たる画像を挿むように進んだとき、多数の中から無作為に選んだワンショットをちら見せ、そういうものを常時表示させておくことで、閲覧者の関心を惹く目的ではそこそこ意味がある。固有の利用形態だと思いました。
それでヘッダエリアに入れてみたところ、なかなか面白い。「まず目を引き、最初に読み始める興味関心をそこから始める」意味で、これは使えます。
作成中なりに8000件のようなシャッフルをのほほんと想像してしまいましたが、やってみると早速500上限に当たりました。案の定かと臍を噛んだものの、管理者としては上の方針であり、このコンテンツ自体サイトの主目的では絶対になく、「本当に必要か」といえば不要なことはあらためて言います。また、上限があることについてはWIKIWIKI運営の方の通りにすぐに腑に落ちました。
「500」という具体的な数については判断できないものの、判断できないものは運営の方針にお任せすればよく、制限があればその制限にしたがうべきとの考えに至り、その後は500以内でシャッフルの条件を適宜可変にする形に収めています。8000を空想し、実用的に要るのは300くらいでした。その際に意識に昇ったのは、情報の編集・編纂は常にその操作より、操作を行う意図が重要という基本です。扱う対象が多ければ何ブロックかに分けてそこそこの数ごとに仕分けるようにすれば、その仕分けの意図を考え直す機会にもなるかと思います。実際に馬鹿げた操作をしかけてから上限に気づくので、上限数についてはマニュアルに載せておいてください。
AVIF image format につきまして、検討いたします。
本来の目的がショート動画の埋め込みなら別の要望になると思います。
ページ内の全ての開閉記録を保持してページ遷移後、記録をページに反映させる機能でよろしいでしょうか？
以下の項目を踏まえて引き続き議論いただけたら幸いです。
例えば一括開閉ボタンを作るとか
動的に動かす機能はコストがかかります。
WIKIの機能として本当に必要なのかも踏まえて、引き続き議論をお願いします。
同様のトピックが作成されましたので、
こちらで議論をお願いします。
https://zawazawa.jp/wikiwiki-request/topic/188
同様のトピックがありましたのでまとめます。
プラグインの引数にプラグインを指定することは非推奨です。
本来のやりたいことを別のトピックで要望として、議論していただけたら幸いです。
はい、極端な例ですとそうなります。
実際は妥当な画像サイズに最適化されます。
はい、ブラウザのキャッシュがあればそちらから読み込みます。
画像の最適については、以下のトピックもご確認ください。
表示画像の最適化について
https://zawazawa.jp/wikiwiki-request/topic/184
どのような場面で表組の枠線を消したいのでしょうか？
レイアウトでの使用なら、別の要望になると思います。
例えば1500x1500でアップロードした画像もサイズを100x100に指定したら100x100の画像になって転送量を削減できるということですか？
また、一度読み込んだ画像はキャッシュに保存されブラウザ更新してもキャッシュから読み込まれますか？
「最近更新されたWiki」は必要ないからやめてくれということなのか、「一日単位での追記件数」ランキングを作ってくれというのか
結局、何を要望しているのか分かりにくいです。
以下は昔のWIKIWIKIのよくある質問を抜粋したものです。
これを見て「最近更新されたWIKI」って検索サイトのクローラーに見つけてもらうためにあるんじゃないかと勝手に思ってます。
更新しても数時間で埋もれてしまうのでタイミングが合わなければだめですけどね。
自分の作ったWikiも一切宣伝してませんが訪問者が来るようになりましたし。
関係ないですが、WIKIWIKIにはいくつのWikiがあるんでしょうね。どこかで公表してましたっけ？
話がそれましたが「ネットに存在するあらゆるWikiに関心を持ちながらその通知を見ている人」とはまさに「検索サイトのクローラー」なんじゃないでしょうか。(人じゃないけど)
ということで「最近更新されたWIKI」は必要だと思いますよ。
こちらの希望としてはrecent・zrecentと全く同じ表示ですので、>> 2はその場しのぎとしてはありかなぁ、という印象です。
類似の話題で言及されている通りlsxは重めのものですので、長年愛用して数万ページに達しているとまた話は別なのかなと。
zawazawaのより手軽な利用方法要望については別トピックで議論したほうがいいと思います。
Wiki編集ってボランティア活動の一種だと思いますが、その行為を評価するのって必要なんですか？というか確認できる仕組みを求めてることに強い疑問を感じます。
そちらが積極的に編集に参加していて、他の編集者のアクティビティを見たいという意見なら分からなくもないですが、編集に参加しない人側からの視点での意見ということであれば取り下げたほうがいいです。
調べたらでてくるボランティアの4原則などを一度見てみてください。
ご対応ありがとうござます。Headerが意図したとおり表示されることを確認しました。
この不具合の対応で上記の現象が発生しました。🙇♂️
大変遅くなり申し訳ございません。
:Header でも flexbox が動作するように対応いたしました。
実は :Header や MenuBar はスタイルに「特別ルール」が実装されています。
例えば、:Header は表組の枠線が表示されません。
昔からレイアウトを組む方法として表がよく使われてきました。
:Header では 表組にデータを入れる用途で使われないため、レイアウト専用として枠線を消していました。
このガラケー時代の名残が原因で flexbox が動作しておりませんでした。
今は flexbox があるので、不具合の原因になりやすい :Header の「特別ルール」を無くすことを検討しております。
もし、:Header で表組でレイアウトを組んでおられる方は flexbox でレイアウトを組むようにしてください。
対応いたしました。
大変ご迷惑をおかけいたしました。🙇♂️
時間を置いて元の内容を記述したところ、直りました。
一時的に発生した不具合の模様です。
ご不便をおかけして申し訳ございません。
対応しておりますので、今しばらくお待ちください。
ChromeとFirefoxで瞬時に表示されることを確認しました。
ご対応ありがとうございました。
申し訳ございません。
アイコンが常時表示される不具合が発生しておりました。
修正し、正常に動作するようにいたしました。
特定の文字列の「表記ゆれ文字の対応処理」でブラウザに負荷がかかっていたようです。
この機能を無効化して対処いたしました。
共有ありがとうございます。
結論から申し上げますと、負荷は問題ないと思われます。
外部画像も最適化を行っています。
実際にインラインで表示されている画像は最適化済みです。(413KB)
もとの画像サイズと比較して十分最適化されています。
相手側(cdn.discordap)へのアクセスはインライン表示では、ほぼゼロです。
クリック時に拡大表示させた時だけ相手側のCDNから直接読み込みます。(6.6MB)
ここだけ相手側とユーザー側に負荷(転送量含む)が発生します。
相手側の画像は、閉じられた空間でのアクセスを想定されていると思いますので、一度ご確認いただけたらと思います。
参考: 「外部サービスの画像コンテンツの貼り付けについて」
例えばこのページの上部に設置している画像になります。
現在は閲覧数は落ち着いてますが、6月～8月くらいになると閲覧数が爆上がりします。
https://wikiwiki.jp/eft/CUSTOMS
別の機能で提供できることもあるので、
その機能がどのような目的で必要なのかを教えていただければと思います。
上記の現象を確認しました。
調査いたしますので、今しばらくお待ちください。
ご不便をおかけして申し訳ございません。
具体的にどの画像でしょうか？
掲載しているページのURLと表示させている画像を教えてください。
同感です。
フラッシュ機能は、使い方によっては、かつてのポケモンショック同様、
閲覧者に対し光過敏性発作を引き起こしかねません。
チカチカ鬱陶しいだけですし、個人的にも要りません。
点滅文字は設定次第で目にダメージが入ります。
そもそもスクロール文字を実装しているのは昔からの名残であると認識しており、その観点からも新たな追加は不要であると思っています。
どうしてもというのであれば、フェードイン/フェードアウトかつ、フェードインからフェードアウトまで3秒以上など、目に優しい形で制限するならば構いません。
応答不能になる例のリンク先は、ほんらいハイライトされるべきURLの文字列がハイライトされませんね。
タスクマネージャを見ていると表示が完了するまでブラウザーのCPU使用率が高いままです。
HTML Convert timeは短いことから、クライアント側の処理が上手く行ってないように見えます。
ただ普通にブラウザー側の機能の文字列検索を使えば一瞬で対象がハイライトされます。wikiwikiがhtmlに仕込ませてるscript処理になにか問題があるのだと思います。
詳しく検証してみました。
応答不能になる条件
同じページに後半(末尾)が異なる文字列がある
文字列にアルファベットが多い場合(数字のみでは起こらない)
ページの例
Chromeで「これらのキーワードがハイライトされています」が表示されるまでの時間は
”FFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(31文字)の場合6秒
”GFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(32文字)の場合13秒
”GGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(33文字)の場合32秒
”GGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(34文字)の場合1分39秒
”GGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(35文字)の場合2分15秒
と1文字増えるごとにかなり時間が伸びました。
(途中で「ページが応答しません」となっても放置した場合)
なお、どちらの行にも共通する
”HHHHHGGGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA”(40文字)の場合は瞬時に表示されます。
運営の方に質問があるのですが、ディスコードなど外部に添付した画像をWikiに表示させたページがたくさん閲覧された場合は負担をかけることになるのでしょうか？
なるべく高画質なものを添付したい考えがありますので、Wikiのサイズ制限を回避するような形をとっておりました。
もし負担になるようでしたら、半年ごとで1日あたり10000~30000閲覧くらいあるページがいくつかあるので今まで結構な負担をかけてしまってたかなと懸念しております。
もし回避できる方法があればご教示いただければ対応いたします。
ご返信ありがとうございます。
再現性のある現象のようで安心しました。修正を期待しております。
ご回答ありがとうございます。参考にさせていただきます。
申し訳ございません。
写真のような解像度のSVGは非推奨とさせていただきます。
パスする基準について、参考にしてください。
インライン表示の解像度とそのリミットサイズです。
32x32 6.87KB
50x50 8.35KB
200x200 25.29KB
400x400 54.97KB
500x500 71.79KB
800x600 107.06KB
800x800 128.00KB
sharp_yuv オプションは検討いたします。
そのようなオプションがあったのですね。
自分が使用しているフリーの画像コンバーター(Converseen)には無かったので盲点でした。
88KBで試したところ、無事最適化をパス致しました。
なので、一先ずこのトピックは解決済みとさせていただきます。
るーさん、運営の方、ご協力いただいた皆様ありがとうございました。
仰る通りです。勿論止めにします。
賛成です。使えるなら是非お願い致します。
色の劣化に限っては、非可逆圧縮時に-sharp_yuvオプション（より正確にRGBからYUVへの変換を行う）をつけることでかなりマシになるようです。
https://squoosh.app/ では「Sharp RGB→YUV conversion」にチェックを入れることで使えます。
ただ、圧縮に掛かる時間が少し長くなり、ファイルサイズも通常より少し増えます。
参考までにSquooshでEffort=6、Quality=70、Sharp RGB→YUV conversionにチェックして圧縮した画像です (約59KB)。パッと見で違いが分からないくらいにはなったかと思います。
スレ主さんはおそらく色の劣化が気になっていらっしゃると思うので、自前で前述の非可逆圧縮をするか、WIKIWIKI側の自動圧縮で前述のオプションを使うのはどうでしょうか？
個人的には文字色が明らかに薄くなっている以外では、他の劣化はほぼ気にならないレベルですし。
こちらでlibwebp 1.3.0を使って最大のロスレス圧縮をしてみましたが、157.382KBでした。
画像の可逆圧縮ではwebpが最強だと思うので、これ以上小さくしたいなら非可逆圧縮するしかなさそうですね。
ファイルサイズの大きいsvgでは画像圧縮の本来の目的である「転送量の削減」を悪化させてしまうので、やめておいた方が良いでしょう……。
最後にWIKIWIKI運営さんにおききしたいのですが、
ということですが、具体的にはどの解像度でどのくらいのサイズが理想なのでしょうか？
今後も同じように画像を圧縮してほしくない際の参考にもなると思うので、共有いただければ幸いです。