この記事は NewsPicks Advent Calendar 2025 の9日目の記事です。
ソーシャル経済メディア「NewsPicks」のエンジニアの堀です。
今回の記事では、今年プロダクトチームを横断して取り組んできたアプリにおける記事画面の表示速度改善について紹介したいと思います。
また、この記事を通してNewsPicksというプロダクトが色々なチームの協力のもと日々進化しているということが伝われば良いなと思います。
表示速度の重要性
Webサイトやアプリの表示速度が遅いと、ユーザーの離脱率の上昇を招きます。
ユーザーはコンマ数秒でも待たされていると感じると、それだけでサービスを使う意欲をなくすのです。
離脱率が高まればユーザーの継続利用や拡散が阻害され、結果的にサービスの成長を妨げることになります。
NewsPicksにおいてもコンテンツの表示速度はユーザー体験を左右する重要な要素ですが、メインコンテンツである記事の表示速度に課題があったため、改善に取り組むことになりました。
どれだけ速くなったのか
最初に結果を紹介したいのですが、その前に今回の改善スコープについて説明します。
今回の改善スコープは、提携メディアの取込記事のアプリ上での表示速度です。
提携メディアの取込記事というのは、 NewsPicksと提携しているメディアからRSS配信された記事情報（HTMLなど）を、NewsPicksのデータベースやストレージに保存し、NewsPicksのサービス上で表示している記事です。
NewsPicksにはこれ以外にも、編集部が作成しているオリジナル記事や、提携メディア以外の外部メディア記事（こちらは外部サイトのURLにリダイレクトして表示しています）などがあります。
NewsPicksのアプリではこれら全ての記事をWebViewで表示していましたが、今回の速度改善の一環で、取込記事の記事画面をネイティブUI化 しました。
注意点として、オリジナル記事と外部メディア記事については現在もWebViewで表示されています。
前置きが長くなりましたが、以下のグラフは直近10日間の記事の表示速度（ = 記事をフィード上でタップしてから画面遷移して表示されるまでの時間）をOSおよび表示形式単位で比較したものです。
4つの線のうち、上2つが各OSのWebView、下2つがネイティブUIの数値を表しています（数値は日次集計の中央値）。
WebViewでは両OSともに1秒前後ですが、ネイティブUIでは約300msです。
あくまで中央値なので通信状況によっては個人差はありますが、ネイティブUIに対応したことによって劇的に速度が改善されたことは確かです。
この改善はネイティブUI化によるものが大きいですが、それ以外の取り組みも含めて紹介したいと思います。
取込記事のネイティブUI対応
上述の通り、NewsPicksの記事はWebViewで表示していました。
アプリ内でブラウザをもう一つ起動し、その上でHTMLやCSSなどを解釈して描画するWebViewに対し、ネイティブUIはアプリのプロセス内で即描画するため高速になります。
NewsPicksの取込記事は、上述の通りRSS配信された記事のHTMLデータをNewsPicks内に保存しています。
このHTMLをテキストデータとしてアプリ側で解析し、ネイティブUIで表示するようにしました。
ネイティブUI化における主な課題は表示崩れでした。
Web標準の表現はほぼ使えるWebViewとは異なり、ネイティブUIは対応していない表現が多くあります。
RSS配信されるHTMLデータは、あらかじめ決められたフォーマットに沿った構造になっていますが、そのままではネイティブUIで表示できないHTML要素もありました。
この課題については以下のステップで解決をはかりました。
- 共通フォーマットでサポートしている全HTML要素の洗い出し
- 各HTML要素についてデザインレギュレーションをデザイナーチームと協力して整理
- 全HTML要素に対応したサンプルHTMLを用意し、モバイルエンジニアチームと協力してネイティブUI化の検証
- デザイン調整の繰り返し
これらのチーム横断的な取り組みによって、取込記事の表示速度は約500ms以上改善されました。
WebViewの記事と比較した場合、一目で違いを認識できるレベルの改善幅でした。
500msという数値ではイメージがつきづらいかもしれませんが、人間の瞬き1回が100〜400msなので、瞬き1回分は速くなったと言えます。
また、取込記事はNewsPicksのトップフィードに表示される「今日のニュース」の約半分を占めます。
それらの記事の表示速度が改善されたことは、ユーザー体験を大きく向上させたと言えます。
しかし、画面遷移後から描画までの間にまだ改善の余地があったので、次の改善施策を取ることにしました。
APIのスリム化
さらなる表示速度改善のため、記事情報を取得するAPIの改善にも取り組みました。
まずは記事画面に遷移するタイミングで呼び出しているAPIのレスポンスから無駄な情報を削り、APIのスリム化をはかりました。
記事画面では、記事の本文や画像以外にも記事の発行元、著者、関連記事、PICK数、ブックマーク状態など、様々な静的情報と動的情報が必要です。
これらの情報は、記事画面遷移後にAPIで一括取得していたわけですが、サービス開始から機能追加や改修を重ねる過程でレスポンスが肥大化し、不要な情報も含まれるようになっていました。
この肥大化したAPIレスポンスのプロパティの要否を、モバイルエンジニアチームの協力のもと1つずつ精査し、必要最低限のレスポンスを返却するようにAPIを改善しました。
このAPIは記事情報を取得するという影響度大＆超重要APIということもあり、QAチーム協力のもと、あらゆる記事パターンを網羅したテストを実施した上でリリースしました。
これによって速度は数十ミリセカンドほど改善されました。
APIの分割および先読み
次の改善として、「記事画面遷移後に取得していた情報を事前に取得する」という対応を実施しました。
上述の通り、記事画面を表示する要素には静的情報（記事本文テキスト、発行元、著者 etc）と動的情報（PICK数、ブックマーク状態 etc）があります。
それまでは記事画面に遷移後に全て1つのAPIで一括取得していましたが、情報の属性によってAPIを分割し、静的情報についてはフィード上で事前に取得、キャッシュしておき、動的情報のみを画面遷移後に取得する、という実装に切り替えることにしました。
このAPIの分割および先読みを実装するに当たっては、サーバーの負荷に関しても注意する必要がありました。
フィード上で記事情報を事前に取得してキャッシュするということは、アプリを開いた時の通信量が増えることになります。
特に速報ニュースのプッシュ通知が送られた直後などはユーザーのアクセスが集中するため、サーバー負荷を考慮する必要があります。
NewsPicksではNew Relicを活用しているため、負荷監視にはそちらを活用しました。
SREチームにも相談してAPI単体のコストを確認した限りでは、プッシュ通知後にもサーバーがダウンするようなことは無いと予想できましたが、念のためA/Bテスト形式で20%ずつ段階的にユーザーに適用しつつ負荷を確認しました。
ちなみに、ちょうど100%適用したタイミングで自民党総裁戦があり、速報のタイミングではアクセスが集中しましたが、問題は起きておりません。
この対応によって、記事の表示速度はさらに体感で分かるレベルで改善され、最初に紹介した数値まで改善されました。
4. おわりに
今回は記事の表示速度改善について紹介しましたが、この改善で私自身が対応した範囲は一部です。
NewsPicksのプロダクト開発には、モバイルエンジニアやデザイナー、QA、SREなど様々なプロフェッショナルが携わっており、この改善もチーム横断で取り組んできた結果です。
このブログで紹介した通り、取込記事の表示速度は劇的に改善されましたが、NewsPicksのオリジナル記事についてはまだこれからです。
現在はオリジナル記事のネイティブUI化に取り組んでおり、課題は山積みですがユーザー体験向上のためにやり切りたいと思います。
