HTTP/2をフル活用して、初めて実現するアーキテクチャですね。他にも、サーバ側でJavaScriptコードを分析して必要な関数のみをクライアントに送るといったアグレッシブな転送量削減や、サードパーティ製スクリプトを自分のドメインから配信してHTTP/2の恩恵を最大限受けることも可能です。モバイル向けのライブラリとかもあるのですが、本当に高速ですよ。速度のためにTCPの代わりにUDPを使用していて、そうなるとパケットのエラー検知と再送制御が必要になるわけですが、一定のパケット数ごとに誤り検知のためのチェックサムを付与して、ライブラリ内でエラー制御することで解決しています。機械学習やHTTP/2といった、基盤技術の進化をフル活用して、コンテンツの配信をこれまでにないレベルで最適化するというわけですね...。あと、パフォーマンス業界の最新動向という点でいくと、アメリカでは「パフォーマンス・バジェット」という考え方が浸透してきています。それは?初めて聞く単語ですが。パフォーマンスの目標を立てると、使えるリソースの量は限られてくるわけです。前回の座談会でもお話した「モバイルで3秒以内に表示を開始するためには、リソースを200kb以内に抑えるべき」といったように。そのリソースをどう割り振るかをサイトの設計段階から計画しておくという考え方です。その考え方は面白いですね!全然知りませんでした。いう概念が出てくるくらい、海外ではパフォーマンスの重要性が浸透しているということなんですねえ...。パフォーマンスを「リソースの量」という点で定量化することで、リソースのサイズやフェッチのタイミング、開発コストの投下量など、いろんなものをコントロールできるようになりそうです。うちみたいなスタートアップ企業(TechFeedというサービスの運営企業)とかだと、機能実装が優先になっちゃって、パフォーマンスという項目がどうしても優先順位上がらないんですが、そういう状況の改善にも役立つかもしれませんね。パフォーマンス・バジェットの考え方は、スタートアップにも有効だと思います。計測サービスにお金を払い続けるのが厳しい...という事業規模の企業にも有用かな、と。優秀な計測サービスって、やはりそれなりに高額なんですよね。規模の小さい企業だと、サービスを運営しながらずっと使っていくのは厳しい。それでもパフォーマンスを担保したいという場合、パフォーマンス・バジェットを見積もるために、最初だけ計測サービスを使用するということができるわけです。あとはそのバジェット内でリソースをやりくりするよう注意していけば、一定のパフォーマンスが担保された状態になります。そもそも、パフォーマンス・バジェットを見積もるには、ある程度の計測と実績値が必要だと。そのために計測サービスに最初だけ課金するということですね。見積もったバジェットを守りさえすれば、パフォーマンスが担保された状態になる、というのもロジカルでスッキリしますね。Assurance)という分野は非常に重要になると思っているのです。2019年に民法が改正されて、システム開発の受注側が品質保証の責任を負わなくちゃいけなくなります。現在の「瑕疵担保期間」という単語は条文から消えて、品質保証を行って納入しないと「重過失」という扱いになって、永遠に瑕疵責任を負うことになるんです。品質を満たすまで、タダ働きになるってことです。それはすごい変化ですね...。開発や制作を受託している企業にとっては大問題だ。いうこともあるので、今後はQAのスキルが非常に求められてくるのは間違いありません。現在日本にはQAという職種がほとんどない状態ですが、だからこそQAを行えるエンジニアは非常に希少価値があると思います。それができるようになれば、今後のキャリアを考える上でも非常な強みになるのではないでしょうか。うーん、最後まで大変示唆に富む発言、感謝です。本日は大変勉強になりました。