- 個人サーバーで Nextcloud を最適化しても反応が遅い原因は、過剰なJavaScript読み込み の構造にある
- 初期ページ読み込み時に 15〜20MBのJavaScript がダウンロードされ、圧縮後でも 4〜5MB 程度と依然として重い
core-common.js(4.71MB)、NotificationsApp.chunk.mjs(1.06MB)、Calendarアプリ 5.94MB、Filesアプリ 18.8MB、Notesアプリ 20.91MB など、各アプリごとのスクリプト容量が非常に大きい- このような構造により、iPhone 13 miniでもTasksアプリの起動に5〜10秒の遅延 が発生
- 一部機能は Vikunja(1.5MB JS) 、Immich などで代替したが、Nextcloudの統合機能性のため完全な置き換えは難しい状況
Nextcloudの性能低下の原因
- Nextcloudはファイル、カレンダー、連絡先、ノート、ToDo、写真など多様な機能を統合提供しているが、体感速度が遅い
- 開発者ツールで分析した結果、遅延の主な原因はJavaScriptの過剰な量 にある
- 初期ページ読み込み時に 15〜20MB のJavaScriptがダウンロードされる
- 圧縮転送後でも 4〜5MB 程度で、一般的なWebアプリの基準(1MB)よりはるかに大きい
- ブラウザキャッシュがあっても、訪問のたびに大量のコード実行 が必要なため読み込み遅延が発生する
主なJavaScriptバンドルサイズ
core-common.js : 4.71MBで、複数のアプリに共通機能を提供NotificationsApp.chunk.mjs : 1.06MB- Calendarアプリ: 基本のカレンダー表示だけでも 5.94MB が必要
- 低速なネットワーク環境では 30秒以上の読み込み遅延が発生
- Filesアプリ:
EditorOutline(1.77MB)、previewUtils(1.17MB)、index(1.09MB)、emoji-picker(0.9MB) など多数のスクリプトを含む
- 合計 18.8MB に達し、実環境では1分以上読み込み待ちになることもある
- Notesアプリ:
notes-main.js だけで 4.36MB、全体では 20.91MB 程度
ユーザー体験への影響
- Tasksアプリ の起動時にも 5〜10秒の遅延が発生
- 例: 店内で買い物リストを開いてもすぐに表示されない
- 機能に対するバンドルサイズの比率が異常に高く、機能性と性能の不均衡 が起きている
- Nextcloudの構造上、共通ライブラリやツールが多く、統合体験を提供する代償として性能低下 が生じている
代替サービスの活用
- 一部機能は Vikunja(ToDo管理、1.5MB JS) や Immich(写真管理) に分離して運用
- Vikunjaは完璧ではないが、JS容量が小さいため 体感速度に優れる
- しかしNextcloudの 統合性と利便性 のおかげで、完全な代替は難しい
結論と認識の変化
- Nextcloudの現在の構造には、正当な理由や人手不足 など現実的な制約があるかもしれない
- それでも、ユーザー体験とアクセシビリティの低下 は明確な問題として指摘されている
- Webパフォーマンスの専門家 Alex Russell の文章を通じて、Webパフォーマンスの重要性と開発チームの 性能・アクセシビリティ管理の不注意 という問題を認識するようになった
- Webアプリ開発では パフォーマンス不平等(performance inequality) の問題を考慮する必要がある
3件のコメント
単純に遅いです。クライアントだけでなくサーバーも遅いです。
8745HSマシンで数百個のPDFサムネイルを作るのに何時間かかっても終わりません。
他のファイルサーバーを適当に動かすほうがマシです。クライアントがWindowsならSMB、それ以外はrcloneやdufsでWebDAVサーバーを使うほうがよかったです。
copyparty、良かったです
Hacker Newsの意見
Nextcloudは好きになりたいと思っている。存在自体はすごいと思う
ただ、見た目はちゃんと動いていても、ときどき完全に壊れてしまうような復旧不能なエラーが起きる
iOS/Androidアプリで家族写真を自動バックアップしようとしたが、iOSアプリはたまに「locked webdav」エラーが出たり、同期が止まってしまったりする
結局、80GBの写真を最初から再アップロードしなければならない状況になった
家族で使うには不安定すぎるので、信頼できる代替が必要だ。実質的にiCloud以外に代替がない
Filesアプリ連携で貼り付けたが、同期されず、警告もなくデータが消えた
copyparty GitHub — 必要な機能だけがあり、無駄な肥大化がない
ただし、Dropbox代替としては依然として決定打がない
公式アプリはバグが多いが、サーバー側は安定している
NextcloudはJavaScript呼び出しが多すぎて遅い
カレンダーページの更新時に124件のネットワーク呼び出しが発生し、そのうち31件はキャッシュされない
各カレンダーごとに30ms以上かかるため、カレンダー数が多いほど遅延が積み上がる
ローカルネットワークでも1秒、4G環境では33秒以上かかる。設計自体が非効率だ
こうしたRESTベースの構造はモバイルネットワークでは往復遅延が大きく、遅くならざるを得ない
もうRESTではなくWebSocketを使うべき時だと思う
予定の追加や修正がしづらくなり、UIも幼稚になった。まともに使えるオープンソースのWebカレンダーがない
Electric SQL のようなアプローチは興味深い
また、TC39 import proposal のようなJS改善案も役立つかもしれない
以前、Nextcloudのソフトフォークを保守していたが、基本構造が複雑すぎる
パフォーマンス改善パッチをいくつか当てるだけで、ファイルマネージャーのレンダリング速度が何倍にも速くなった
しかしコードベースは層の上にさらに層を重ねた構造で、信頼しにくい
結局プロジェクトを断念した。この複雑さがホスティング事業者の生態系を支えている要因にも思える
各機能が独立したプラグインとして始まったため、統合性がない
今では1つの怪物になってしまっており、むしろ複数のツールをSSOで連携したほうがよいと思う
それに、実際にはNextcloudの運用はそこまで難しくない。一度セットアップすれば保守は簡単だ
記事で言われているJS容量よりも、非効率なロジックこそが遅さの原因だと思う
多すぎるAPI呼び出しとUI更新が問題だ
昔は200KBを超えたら最適化を点検していたが、Nextcloudは15MBもある
私はNextcloudを7年間、家族写真のバックアップ用に使っている
プライバシー保護がしっかりしていて安定しているが、Google Docs代替としては絶対に勧められない
大容量アップロードやサムネイル読み込みが不安定で遅い
それでも代替がなく、データを大企業のAIに預けたくない
家族がもっと積極的に使ってくれたらと思っている
いろいろなセルフホスト型ファイルマネージャーを使ってきた
Ajaxplorer → Pydio → Nextcloud → FileRun の順で使ってきたが、FileRunが最も満足度が高かった
高速で安定しており、モバイルブラウザでもよく動く
今は有料だが、その価値はある
copyparty も軽量で高速だが、一般ユーザー向けではない
FileRunの「ファイルリクエスト」機能が恋しい
filebrowser GitHub
filebrowser-docker
デモリンク
Syncthingとの組み合わせを試そうとしているが、CPU負荷が気になる
Nextcloudは遅くて肥大化しているが安定している
8人規模の会社で何年も問題なく使っている
Webアプリは遅いのでほとんど使わず、主にデスクトップ同期クライアントを使っている
IMAP認証プラグインが非常に便利で、ユーザー管理がしやすい
uBlock, userstyle, userscript などで自由にカスタマイズできる
以前、NextcloudのPDFビューア脆弱性を発見して報告した
古いJSベースのPDFビューアを含めていたのが問題で、16歳のときに100ドルを受け取った
私のブログ記事
オープンソースプロジェクトへの不満は多いが、自分で改善しようとする人は少ない
私はNextcloudが大好きだ。遅くても自分のデータを自分で所有でき、AGPLコードなので修正もできる
無料で使え、拡張機能を「買い物するように」追加できる
6年以上大きな問題なく使っており、こうした自由は本当に素晴らしい
完璧ではないが、存在してくれてありがたいプロジェクトだ
Nextcloudの利点は、1つのプラットフォームでコラボレーションツール全体を扱えることだ
ファイル、カレンダー、ノート、オフィス、写真、Talk など統合された体験を提供する
AIOパッケージは更新や安定性の問題をかなり解決した
ただしPHPベースなので性能は劣り、UIはSynology DSMのように洗練されてほしい
問題は非効率なI/O構造と大量のXHR呼び出しだ
PHPは敷居が低く、コミュニティ貢献には有利だ
公式ドキュメント — ただしDocker依存が多く、環境制約も大きい