ここにはすべての優れた回答がありますが、2 セントも投入します。
でコントロールをバインドするとif (!IsPostBack)、暗号化されたビューステート フィールドが Web フォーム ページに書き込まれます。次のリクエスト中に、その状態のすべてがサーバーに送信され、復号化/逆シリアル化されます。ページに GridView がある場合、そのすべての行がビューステートになるため、再度データバインドするために別の db 要求を行う必要はありません。
この意味で、サーバーのパフォーマンスが向上する可能性があります。ただし、ここで他の人が言ったように、そのすべてのビューステートをサーバーに送信することでネットワークに打撃を与えます。また、状態を押し下げる必要があります。潜在的なビューステートの悪用を克服し、Web フォームのパフォーマンスを向上させるために、意図的にビューステートを軽くしているようです。ビューステートは悪用されたり無視されたりすることが多いため、これは間違いなく良い習慣です。
ページ分割された GridView をクライアントにプッシュ ダウンする例を考えてみましょう。GV に 15 行が含まれている場合、すべてをクライアントにプッシュし、バックアップの途中でデシリアライズし、最初のロード後にデータベースにヒットしないようにすることで、パフォーマンスが向上する可能性があります。ただし、GV に 1500 行が含まれている場合、viewstate で送信せず、代わりに各ページネーション リクエスト中にデータベースにアクセスすると、エンド ユーザーのパフォーマンスが向上する可能性があります。(ただし、GV から詳細ページにリンクし、[戻る] ボタンをクリックするとすぐに、データを再投稿するように求められます。これは、行数に関係なく、常に面倒です)。
最終的には、Web フォーム ページを提供および使用しているマシンで開発しているときに、パフォーマンスが向上するように見える場合があります。ただし、viewstate のサイズによっては、ネットワーク経由でコンテンツにアクセスする人は、あなたほどの速度を感じない場合があります。それはすべて、ビューステートがどれだけ太いかによって異なります。
多くの MVC ファンが気に入っている理由の 1 つは、特定のアクションを実行するために必要な最小限のリクエストをサーバーに送信するだけで済むためだと思います。ページ上のすべての Web コントロールのすべてのデータと状態を送信する 1 つのモノリシック フォームを使用する代わりに、フォーム全体を逆シリアル化する代わりに、フォームを分割し、セクションまたはチャンクのみを異なるアクションに送信できます。
他の人がここで言っているように、あなたの質問に対する簡単な答えは NO です。MVC が Web フォームよりも常に高速であったり、パフォーマンスが優れているとは限りません。白黒はありません。多くの場合、それは可能であり、実行しますが、他の人が言っているように、一部のアプリは webform に適しています。また、パフォーマンスはあなたの唯一の関心事ですか? MVC は、パフォーマンスが常に「依存」する可能性がある場合でも、他の領域の Web フォームよりも白黒の利点があります。