Scrapboxとマルチペイン
Scrapboxは小さいページを軽快に飛び回る設計になっている割に読み込みが遅い・マルチペインをサポートしないのがよくわからない マルチペイン欲しいinajob.iconnishio.icon
ブラウザを複数タブで開くのではだめ？基素.icon
いまはそうしてますが、ツールとしてサポートしてもらえると便利なこともありそうという気持ちinajob.icon
あるリンクをホバーすると右タブで開くボタンが出てくるとか
左右のペインの内容を入れ替えるとか
読み込みの速さとマルチペインの必要性は独立だと思うinajob.icon
切り出し作業のやりやすさなどに関係する
2窓開いて切り出し作業するときに、初期の読み込みが早いとありがたいとは思うけど、早ければマルチペインが不要になる感じはしない
この使い方ゆえSPAでページ遷移が早い、はこの件とは明らかに関係がない
初期のページ読み込みが早いは、若干関係するか？
下の方で、ページ遷移が早いと埋め込み・マルチペイン不要みたいな話が盛り上がっているが、ページ遷移の速度とは関係なくマルチペインがほしいと思っているので、眺めているだけ
shokaiさんは読み込みが早いと認識しているはずtakker.icon
ページ遷移が十分速ければマルチペインや埋め込みも必要ないという考えなのだと思う
実際にはこのようにだいぶ遅い場合がある
前提でズレが生じている
「読み込みが極限まで早ければ要らなくなるはず」とまでしか言ってない認識sta.icon
見逃してるかもですが
光速はこれですtakker.icon
cacheを表示しているので光回線で太平洋を横断する速度を超えたという意味に見えるmtane0412.icon
実際に高速化されているのでそういう比喩もあるだろうけど
この辺の発言を拾い上げて、shokai.iconが(いかなる場面でもScrapboxは)読み込みが早いと言っていると捉えるのは少し無理がある気がする
強引な援用でした、すみませんtakker.icon 言うほど強引か？はるひ.iconMijinko_SD.icon
「強引」という感じはしない、詳細に見なければ思い出せないので普通にそう解釈しそうmtane0412.icon
僕はshokaiさんは(いかなる場面でもScrapboxは)読み込みが早いと認識しているとはとても思えないmtane0412.icon
これが正しいかどうかはわからないが、現在出ている情報では妥当な読みだと思っている
あるいは「shokaiさんは(Scrapboxの)読み込みが早いと認識しているかどうかはわからない」というのが現状言えることの限界
高速ならば埋め込みは不要、かつ埋め込みはつくらない、というスタンスだと読める
妥当mtane0412.icon
これはScrapboxは既に十分に高速であると見ているものによるのではないか
「十分に高速だから埋め込みは作らない」と推測しているのはなぜ？mtane0412.icon
十分に高速ならば埋め込みは不要である
Scrapboxに埋め込みはない
∴Scrapboxは十分に高速である
妥当ではないmtane0412.icon
もしくは不要でなくてもつくらないという書かれていない前提がある
近々めちゃくちゃ高速になる見込みがあるなど
「リンククリックの画面遷移を滅茶苦茶高速にすれば不要な気がしています」と発言しているので、見込みがあるかどうかはともかくこの方向性で考えてると読むのが妥当にみえるmtane0412.icon
「書かれていない」としたら、これとはまた別の方向性
新機能の必要性に対してデメリットの方が大きい
自分も同じ認識Mijinko_SD.icon
「高速になれば不要」という意見は実際に高速になっていないと使えない
そして、仮に以前と比べて高速になったとしても、地域差で高速にならないところが出てくるんじゃないかとも思っています（道民感）
shokaiさんは読み込みが早いと認識している
判断基準
1. 「リンククリックの画面遷移を滅茶苦茶高速にすれば不要な気がしています」
2. (Prefetchが)「光速を超えた」
1だけでは導けないので2が重要
2を「遷移が速い」と解釈するなら「強引ではない」というのももっとも
「遷移が速くなった」という理由だけで「光速を超えた」と言っているならすごいダサい表現mtane0412.icon
光速を超えてないのだから
「光速を超えた」という表現には別解釈がある
サーバーはアメリカにあるのに、clickした瞬間に画面が表示される
アドレスバーが書き換わった直後にUIスレッドはfetchしている
そこからパケットが太平洋を往復する間、待つ必要があった
ここで「光速を超えた」というのは「Prefetchによって、太平洋の光ケーブルを横断するよりも早くなった」という意味になる
これなら「光速を超えた」というのはウィットな表現になるmtane0412.icon
ここまで丁寧に書かれているのに「光速を超えた」というのを単純に「遷移が速くなった」とだけ解釈する方が無理筋に見えるmtane0412.icon
Scrapboxの哲学や、特にテロメアの命名とかでshokai.iconの言語センスは高いと思っているので、1だけで解釈する線は薄いと思っているmtane0412.icon
Prefetchによってある技術的な限界点を超えることができた
実際に頭打ちだったページ遷移はより高速化できた
PrefetchによってScrapbox全体が十分に高速化されたと解釈するのが謎
mtane0412.iconレベルのカスみたいな人間でもわかってる事実を作り手が気づかないというのは不自然な推測
「リンククリックの画面遷移を滅茶苦茶高速にすれば不要な気がしてい」ると考えているエンジニアが、自分が最高責任を負っているプロダクトのパフォーマンスについて正しく把握できていないって考えてるということですよね？あり得るのかな？mtane0412.icon
私もScrapboxの速度は（マルチペイン要らないレベルで爆速という意味では）まだまだだと思ってますsta.icon
かなり頑張っているとは思う（他のツール使う気が起きないくらいには）
深さで色が変わるCSSを全体適用すればこういう警告は不要になりそうinajob.icon
無効化されてるけど
切り出したい.iconcFQ2f7LRuLYP.icon
雑に切り出してみたsta.icon
すでに構築済みのHTMLを返しているからだと思うtakker.icon
scrapbox.ioはHTMLの<body>のほぼすべてをブラウザで生成しているから、その分遅い
まあ「速さ」より「リアルタイム共同編集」を重視してるのだろうから仕方がないnishio.icon
比較
SSR:
1. サイトにアクセスする
2. 構築済みのHTMLを返す
3. おわり
動的にコンテンツが生成される物と相性悪そう基素.icon
scrapbox.io
1. サイトにアクセスする
2. HTMLの骨組みだけ返す
3. JSが読み込まれる
4. JSがscrapbox.ioからページデータを取得する
5. 取得したページデータをもとにHTMLの中身を構築する
6. おわり
cacheが効いていると、2~4が通信なしで処理される
なるほどはるひ.iconyosider.icon
これを軽くする方法はなにかありますか？
5.で作ったHTMLをCacheに格納するとか？takker.icon
cacheが効いているときに5.をスキップできる
しかしいくら読み込みが早かろうと人間がリンクをクリックする速さも0に近づけないと高速さも半減止まりなのでははるひ.icon
視線を当てた時点でプレビューが浮かんで欲しい
リンクを開くキーボードショートカットとかマウスポインタをリンクにスナップさせるみたいな仕掛けが要る
マルチペインも、読み込みの高速化も、おそらく普通のWebページでは不要だろうMijinko_SD.icon それなのに必要という声があるのは、複数のページを同時に見る必要があるから？
って気がした
文章内にリンクが大量にあるっていうwiki形式だからなのかなwogikaze.icon
他のサイトでも引用・参考にされているサイトに飛んだりするが数ページ程度
これがscrapboxだと関連ページ含めて20ページはある
読み込み時間がPV（だったかな？）に影響するということで、各社それぞれ高速化を頑張っている印象があるinajob.icon
雑に調べた
まぁ3秒は遅いよね
0.1秒と0.05秒だとどうなんだろう基素.icon
YouTube shortsは1分の短い動画だけど最初の数秒でテンポ悪いと切り替えちゃうのを思い出した基素.icon
逆にScrapboxはPVを理由に読み込み速度向上を頑張る必要がないtakker.icon
PVを全く求めていないから