Developers.IOの記事ページが生まれ変わります！ーさらなる読みやすさを目指して

従来のページの課題などを踏まえた上で、新しい記事ページの特徴をご紹介いたします。

#ブログ

諏訪悠紀

2020.03.19

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

このたび Developers.IOの記事ページのリニューアル作業 が概ね完了しました。一部の記事にはすでに反映されていますが、順次切り替えを予定しています。

Lighthouseによる評価では、下図のように評価をかなり引き上げることができました。従来の記事ページより、より読者にとって読みやすいリニューアルにできていると期待しています。

本記事では、これまでの歴史的なところも踏まえた上で、新しい記事ページの特徴をご紹介したいと思います。

背景と目的

約6年半でのDevelopers.IOの価値の変化

従来の記事ページのデザインは遡ること2013年9月にリニューアルされました。

この時はiOS 7がリリースされた直後で、本ブログでは「iOS 7解説記事70本一挙公開！」を公開しました。iOS 7で刷新されるUIにあわせて、ブログのデザインも近しいものにリデザインされました。

それから約6年半経ったいまでは、数多くの記事が公開され続け、当時では考えられないくらいに多くの技術者が知っているメディアへと発展していきました。いま振り返ると「70本」って大した数字じゃないな、と思えてしまうくらいに記事投稿数、記事投稿頻度は右肩上がりに上がっていくばかりです。

Developers.IOで大切にしていることは 新しい技術をいち早く届けること や 圧倒的な情報量 、 ”やってみた”で検証済みであること などが挙げられます。これらを体現し続けたことによって、多くの読者の方々、あるいはたまたま検索して訪れた方々に対しての価値提供ができています。

Web技術の変化と "検索体験"

世の中も状況は変わり、以前よりも多くの企業が技術ブログを抱えるようになったり、技術記事専門のメディアやまとめサイト、サービスなども増えました。

それによって、いま現在ではデベロッパーのほとんどが技術記事を書いたことがあるくらい 技術記事が世の中に日々増え続けることが当たり前 になっています。気になる技術をちょっとググってみるだけで、膨大な数の技術記事がヒットします。

Webに関わる技術も、6年半でかなり変わりました。いまではPWAを使うとアプリのように扱えるようになったり、ユーザー体験を高めるためのシングルページアプリケーション (SPA)、それに関連したサーバーサイドレンダリング (SSR)…ブラウザもChromiumを中心にしながら、日々進化し続けています。

また、SEO (Search Engine Optimization)の評価基準もWeb技術の変化に合わせたものに変わっていき、新しい基準に対応していなければ「検索の上位に上がりづらい」なども起きたりします。こういった変化（主に技術）に対して、ずっと同じデザイン、アーキテクチャ、Webフロント技術でやっていくことには限界が来ます。

Webメディアは「検索の上位に来ることを目指す」わけですが、その目的は様々です。

Developers.IOの目的は 技術に困っている人を助けるために上位を目指したい です。実際、社内だけでも「○○○にハマってて何とか解決したんだけど、うちのブログに書いてあったわ」みたいなことも良く起きます。技術に困ったり、ハマったり、理解したいと思っている人が、ちょっと調べたらDevelopers.IOに辿り着き、解決することができた。この "検索体験" を最大化したい と言うのが今回のリニューアルの一番の目的です。

コンセプト

とにかく速く表示する

以前、かなり話題になった、全てを捨て去り速さに徹した「dev.to」、そしてベストを尽くした「阿部寛のホームページ」。これらのサイトに憧れを抱き、チャレンジしたデベロッパーの方は多いと思いますが、自分もその一人です。

技術記事に関して言うと、技術記事を読みたい人は とにかく早く内容を参照したい 以外はないと思っています。

もしかするとシステム障害が発生していて、その解決をするためにブログ記事を見に来たのかも知れません。あるいは、ネットワーク環境の悪い場所からブログ記事を見ようとしているのかも知れません。

多くの人々の助けになるよう いち早く内容を表示すること を絶対的な基準とし、記事内に載せたいコンテンツやGoogle Tag Manager (GTM)など利用ツールの使い方を調整しました。

例えば以下のようなポリシーです。

余計なコンテンツ、要素は減らす
過度なCSS装飾は使わない
JavaScriptの計算処理を最小限にする
表示に必要なライブラリ以外は極力使わない
Webフォントは使わない
アイコンセットなどは使わず、必要なファイルのみ使う

「デザインより質」は大事な観点ですが、Developers.IOでは 最小のデザインと最大の質 を心がけています。

Lighthouseの高評価を目指す

指標として分かりやすいのは何と言ってもLighthouseです。LighthouseではHTMLコードを中心に、パフォーマンスで改善すべきところはないかかなり細かくチェックしてくれています。この評価を高めていくことが、Webサイトのチューニングの最も効率的な方法です。また、あまり気にかけづらいところであるアクセシビリティについてもしっかりチェックしてくれます。

リニューアル前とリニューアル後の評価を見ると一目瞭然です。同じ内容の記事で比較しました。

従来の記事ページの評価がこちら。全体的に高い評価ではありません。

こちらがリニューアル後の評価。ここまで持っていくことができました！

パフォーマンスについては、記事内のコンテンツによって変わってくるので、90% ~ 98%あたりが揺らぐ形になります。記事の書き方によっては他の評価も下がってしまうので、このあたりはしっかりと社内の啓蒙活動をしないといけなそうです。

実装については、採用しているフレームワーク「Nuxt.js」の標準の機能で満たせたところがほとんどです（すでに使われている方が多いと思いますが、本当にオススメ）。それに加えて前述している 過度なCSS装飾は使わない や JavaScriptの計算処理を最小限にする などを念頭におきながらコーディングしています。レスポンシブデザインを実現しようとすると難しいところや妥協しているところは少しあるので、調整すればもう少しパフォーマンスが向上できると思います（実際、パフォーマンスのモバイルのスコアはまだそこまで高くありません）。

アーキテクチャについては、また別な記事で紹介できればと思います。

新しい記事ページの解説

ファーストビューでだいたい分かる

本文を読まなくても、どのようなことが書いてある記事なのか「忙しい人でも分かる技術記事」を目指しました。

アイキャッチ

アイキャッチは以前まで正方形の画像を用意していましたが、OGP画像としてベターである「1200x630」を用意する必要も場合によって出てきます。例えばイベントを開催する場合はイベント専用画像を用意してブログ、またはイベントサイトに登録などをします。

場合によっては長方形と正方形の画像を用意することになるわけですが、クリエイティブ作業の手間が都度かかってしまっていました。そこでブログを1200x630に統一することで、OGP用の画像だけ用意すれば良くなるようにしています。

従来のデザインではアイキャッチが正方形である前提のレイアウトだったため、今回は長方形を前提にレイアウトしています。画像が大きく表示できるようになりました。

リボン

Developers.IOではシェア数に応じてリボンが付く仕組みになっていますが、リボンの色だけではパッと見でどういう意味があるのか分かりづらいです。そこで「注目の記事」のようなラベルのようにすることで、初めてDevelopers.IOを読みに来た人でも意味のあるデザインに変更しました。

概要

概要はもともとOGP向けに追加した機能ですが、記事の表示部には反映されていませんでした。新しい記事ページではタイトルの下に置くことで、ほぼファーストビューでどのような内容の記事か分かるようになっています。もちろん 執筆者が分かりやすく簡潔にまとめるスキル も必須ですが。

特集カテゴリ / シリーズ / タグ

特集カテゴリとシリーズはもともとリンクが表示されていましたが、新しい記事ページではタグも表示されています。タグをクリックすることで、同じタグが付いた記事を検索できます。

ミニマルなシェアボタン

前回のリニューアル時（約6年半前）にはGoogle+やTumblrなどのシェアボタンも用意されていました。しかしながら利用率を計測したところほぼ使われていないことが分かり、削除した経緯がありました（Google+についてはサービスが終了）。Facebook、はてブ、Twitterがよく使われていましたので、その3つに絞ってミニマルに表示しています。

読みやすさを重視した本文

Developers.IOをよく読んでいただいている読者は本文の1行の文字数が少なくなっていることにお気づきかと思います。これは 人間が読みやすい長さ に調整した形になります。

一行あたりの文字数は、長すぎず短すぎないくらいがベストです。一行が長すぎると、端から端まで視線を動かさなければならないため、次の行を見失ってしまったり、反対に短すぎると、適切な文章の切れ方でないため、内容が理解しづらくなります。

使っているフォントの大きさにもよりますが、基本的に一行あたり 30〜40 字の間が読みやすい文字数だと言えます。

約35文字程度にすることで 読むのに疲れる という暗黙的な感覚を解消しようと狙っています。旧レイアウトとはギャップがあるのではじめは慣れないかもしれませんが、慣れると以前より読みやすくなっていると思います。

Developers.IOはとにかく記事が頻繁に投稿されるので、自分にとって有用な情報でも見落としてしまう可能性があります。本来参考にしたい記事の内容に加えて、関連の記事もあわせて読むことで技術知識をより豊かにできるように用意しました。

ここは表示される記事の条件など調整可能な場所ですので、目的が果たせているのかどうかを観察しながら試行錯誤していければと思います。

構造化データ

構造化データ は、Google検索エンジンに対して、ページの内容をより理解させるために用意するデータです。構造化データをソースコードに用意することで、Google検索で表示される結果をよりリッチにすることができます。

Google 検索では、ページのコンテンツを理解するよう取り組んでいます。ページに構造化データを含めて、ページの内容についての明確な判断材料を提供すると、Google でそのページをより正確に理解できるようになります。構造化データとは、ページに関する情報を提供し、ページコンテンツ（たとえばレシピのページでは、材料、加熱時間と加熱温度、カロリーなど）を分類するための標準化されたデータ形式です。

新しい記事ページでは、記事内のコンテンツを利用して構造化データを作るように設定しています。設定しても何か減るものではないので、試験的に導入しています。こちらも、実際のGoogle検索の結果の表示を確認しながら改良していければと思います。また、構造化データと切っては切れない関係であるAMP対応も順次進めていく予定です。