現代のブログの驚くほど高い賭け金
結論: 最近、ブログ テクノロジーにどれだけの費用が費やされているかを過小評価している可能性があります。
注: これらの意見のほとんどを私自身の swyxkit スターター テンプレートにまとめました。
読者エクスペリエンス
- 記事のヘッダーと本文 – 優れたタイポグラフィ – 読みやすく、アクセスしやすく、ブランド化されたスタイル – リッチ メディアの埋め込み (特に YouTube と Twitter の埋め込みだけでなく、Repl/Sandbox の埋め込みも – モバイル ビューに注意) – 脚注 (本文を肥大化させずに追加のコンテキストを追加する非常に優れた方法) – ページネーション用の切り捨てマーカー
– コンテンツ トランスクルージョン
– コードの構文ハイライト (主なプレーヤー: Prismjs、Highlightjs、Shikijs – 静的な場合に推奨 – CSS/JS 埋め込みは必要ありません) – git diff 表示を含む – 最近これで問題が発生しました – オーバーフロー コード ブロックを必ずテストしてください – 一般に防御的な CSS を実装してみてください- デスクトップではポップオーバーとしてレンダリングし、モバイル/電子メールでは脚注としてレンダリングしますか?
- メタデータ
- 目次の抽出/表示/強調表示/折りたたみ
- 読書時間の見積もり (議論の余地あり)
- 読者のコメント (Disqus? 発言?) とウェブメンション
- コメントをサニタイズ/管理しますか?
- 社会的証明
- リーダーのハイライト (Medium と同様)
- 拍手/いいね/など
- HN/Reddit/Twitterなどでのメタ会話
- テーマ設定
- ブログインデックスの閲覧機能
- アクセシビリティ
- 安全
そして、モバイルデバイスや（少なくともウルトラワイドモニターでは）すべてが美しく見えるはずです。
もちろん、Web パフォーマンスは読書体験の大きな部分を占めますが、均等な間隔を保つため、以下のセクションに記載しました。
著者の経験
- WYSIWYG ライティング (キーボード ショートカットを使用) – CMS を使用しますか?自分で巻きますか？マークダウンとブロック?
- 静的マークダウン ファイルに書き込む場合、静的ファイル (PDF など) をファイルの隣に配置する機能 (どの投稿に属しているかわからない大きな “ファイル” フォルダーにダンプされる代わりに)、書き込みパスに変換されるマークダウン内に静的ファイルへの相対リンクを簡単に書き込むことができます。
- カスタマイズ可能なメタデータ (指定されていない場合でも適切な推論が可能)
- ナメクジ
- 出版日
- 日付に編集されました
- 正規URL
- 説明
- と:画像
- レイアウト
- ショートコード/展開
- 画像のアップロード – 最良のワークフローは、画像をクリップボードからテキストボックスに直接貼り付けてアップロードすることです。 Github Issues と同様に。
- 静的データ入力
- 分析
- サーバー側分析 (Netlify Analytics)
- Googleアナリティクス
- プライバシーを保護するクライアントサイド分析 (Fathom など)
- モバイルでのオーサリング/編集経験
分布/リーチ
- OpenGraph タグ – これらは展開を決定します。
- テンプレートから自動生成された og:image ですか?リクエストに応じて、それともビルド時に?あなたのタイトル/説明/og:image は、投稿自体よりも多くの人に読まれます。
- 最近、サイトマップは必要ですか?
- ファビコン + ウェブマニフェスト
- 移動または壊れたリンクのリダイレクト
- RSS フィード: さらに優れた – トピックごとにカスタマイズ可能な RSS フィード
- これは巨大です 忠実な読者にリーチするため: 投稿ごとまたは毎週のダイジェスト ベースで発行されるニュースレター。私の意見では、これは Substack の大きな勝利であり、これを真剣に受け止めている唯一のプラットフォームです
- AMPのサポート？議論の余地のある
- ウェブパフォーマンス (Google のランキングに影響するため、ここに記載します)
- 灯台のスコアに注意してください
- すべてのサードパーティ製スクリプトの「ライト」バージョンを検索します
- CDN キャッシュ/エッジ ワーカーからの提供 (Cloudflare、Deno、Fly)
- PWA/オフラインキャッシュ（例）
- リソースのヒント/事前接続
開発者のエクスペリエンス
- 上記のすべての機能を追加するためのプラグイン システム (例)
- ビルド時間は次のようになります。
- データスキーマのタイプセーフ
- 高速コンテンツ プレビュー (できればローカル サーバーを実行する必要なし)
- 監視/警告 – サイトがダウンしたり、何らかの理由で人気のあるページが 1 つ消えた場合、誰が最初にそれを発見しますか?読者ですか、それともあなたですか？
これは、ブログが Jamstack であるべきかどうかという議論と結びついていることがよくあります。Jamstack は主に静的に生成され、CDN 上でホストされます。それとも、従来は主にリクエストに応じて生成され、一定期間キャッシュされていました。
その他
コンテクスト
Ruby から Rust まで、新しい言語を学習する最良の方法の 1 つは、静的サイト ジェネレーターを実装することであるとよく言われます (面白い事実です。実際、これは Netlify での私の持ち帰り面接でした!)。要件に応じて、ファイルシステムへのアクセス、ネットワークリクエストの作成、コードの並列化、構成の解析、ライブラリの使用、プラグインシステムの作成、JavaScript の挿入、CLI の作成、デプロイメントに至るまで、あらゆることを学習する必要があります。
それに応じて静的サイト ジェネレーターが非常に多く存在するため、ほとんどの人は「週末でこれを構築できる」というような形で静的サイト ジェネレーターの価値を下げ、最終的には「鋭さを保つ」方法として数年ごとに独自のブログ プラットフォームを構築する傾向があります。しかし、それはブログ テクノロジーに対する非常に 90 年代的な見方であり、現代のブログの要件は、過去 30 年間で静的サイト生成の基本から大きく乖離してきました。最終的には、読者のエクスペリエンスが低下し、ブログに値するリーチが得られない可能性があります。
もちろん私も例外ではなく、Svelte エコシステム用の私自身の小さなブログ テンプレートの管理者です。私は Dev.to や Hashnode などの最新の開発者ブログ プラットフォームに精通しており、最近は読書に多くの時間を費やしています。 多くのデータ エンジニアリング サブスタック、そして、彼らが私たちにどれだけのことをしてくれるかだけを感謝していますが、手でロールするべきではありません（または、本当に素晴らしい機能なので、DIYの場合は構築することを検討する必要があります）。
これは、私が約 5 年間継続的にブログを書き続けた後に初めてたどり着いた評価です。そのため、特定のソリューションを売り込むのではなく、次の優れたブログ プラットフォームを検討する際に評価してもらえるように、「賭け金」として私が考えるものを書き留めておこうと思いました。
価値があるとしても、開発者であっても、ほとんどの人は自分のブログを手動で作成すべきではなく、それに応じて Devto/Hashnode/Substack (もちろん WordPress はオプションです) を使用するよう努めるべきだと私は思います。なぜなら、ほとんどの人は手動で作成したブログ ソフトウェアの PM と開発に夢中になりすぎて、執筆までたどり着けないからです。結局使わなくなってしまったブログ ソフトウェアのコーディングに多くの時間を費やす前に、実際にブロガーになれることを証明するために、たとえば 20 週間連続で定期的にブログを書いてみてください。
ブログの最も重要な特徴はそのコンテンツです – 良いコンテンツを書けば、人々はどんなハードルも乗り越えて読みに来てくれるでしょう。それを忘れないでください。
