Git LFSは小さなファイルをどの程度うまく処理しますか？
Git LFSに保存されているタイプファイルのベストプラクティスはありますか？特に最小サイズについては？
たとえば、10mbの音楽ファイルは明らかに適合しますが、25kbのpngはどうでしょうか？ LFSを導入する価値はありますか、それともGitに処理させる方がよいでしょうか？
私の懸念は、LFSリポジトリにチェックインする小さなファイルが多すぎる場合のパフォーマンスの低下です。 LFS拡張機能が多数の小さなバイナリファイルにどのように耐えられるかについてのデータはありますか？特定のサイズのしきい値を超えるファイルのみを保存することをお勧めしますか？
正確なしきい値が与えられるとは思いません。
LFSは、リモートリポジトリと同期するために交換する必要のあるデータの量を節約します。ただし、保存は、大きなファイル自体が変更されていない場合にのみ適用されます。実際には、変更されたファイルの場合、LFSオブジェクトの変更を処理するために2回目のラウンドトリップが必要になります。
したがって、ユースケースでファイルが（頻繁に）変更されない場合は、LFSに小さなファイルを含めることができます。特定の損益分岐点は、サーバーのI/O速度に依存し、主にリポジトリとクライアント間の遅延とスループットに依存します。
あなたの例では、pngがほとんど変わらない場合に備えて、改善が期待されます。コミットごとに（ほぼ）変更されるとすぐに、さらに大きなファイルがLFSに配置されてもメリットがない場合があります。
また、2回目の往復の追加コストは、一般的なファイルが大きくなるほど重要性が低くなります。特に、ファイルクラス（サフィックス）のサイズが広範囲にわたって変化する場合、および/またはファイルクラス内の変更頻度が広範囲をカバーしている場合、あなたの質問に対する明確な答えがない可能性があります。