アイデアマンズ株式会社の研究ノート
Webページの表示スピード改善は、やはり実際に変更して計測をしてみないと効果がわからないことがほとんどである。そのため、できれば本番環境には手を加えず、どこを変えたらどうなるかを何度も繰り返しシミュレーションしたい。そのための技術として「http-playback-proxy」をオープンソースで公開している。
ideamans/rust-http-playback-proxy - GitHub
このツールは、Webページ表示に必要なすべての通信を記録し、それを再生することでWebページの精巧なコピー環境を作り上げる ものである。以前はTypeScriptで開発していたが、現在はRustで書き直し、より高速かつ動作が正確になるよう改善している。
実際の通販サイトにおいて一部のユーザーの体験を わざと遅くする 禁断のA/Bテストを実施した。遅い体験を強いられたユーザーの行動にどんな違いが現れたか、衝撃的な結果を報告する。
CDNといえば、大量のアクセスを高速・安定的にさばくためのインフラである。しかし、さくらインターネットのCDNサービス「ウェブアクセラレータ」には、料金体系の特性を活かした「ずるい使い方」がある。
それは、AWSでいうAmazon Data Firehoseのようなストリーミングデータの収集基盤としてほぼ無料で使うという方法だ。
弊社のサービスでも実際に活用しているので、その仕組みを紹介したい。
PageSpeed InsightsやLighthouseでWebサイトの表示スピードを計測すると、スコアやLCP、Speed Indexなどの専門的な指標が数値で示される。しかし正直なところ、これらの数値だけを見て「このサイトは速い」「遅い」と直感的に理解できる人は少ないのではないだろうか。
そこで開発したのが、Webページの読み込みプロセスを動画として録画するCLIツール「Loadshow」だ。今回、Go言語で完全にリニューアルし、オープンソースとして公開した。
弊社ではサイトスピードと通販サイトの収益性の関係を定量的にモデル化することに多大な情熱を注いでいる。その成果を反映したアクセス解析ツールが Speed is Money だ。
このたび、関係モデルを大幅に改良した。従来のモデルでは説明しきれなかった現象がクリアに説明でき、サイトスピード改善時の収益性への影響も精度高く予測できるようになった。
結論から言えば、セッションの代表LCPとして「最小値」を採用することで、サイトスピードとCVRの関係が驚くほど明瞭になる。
LCPとINP
LCP(Largest Contentful Paint) は、ビューポート内の最大要素が表示されるまでの時間を測る指標。典型的にはファーストビューのメインビジュアル画像が対象となる。Googleが定めるCore Web Vitalsのひとつで、2.5秒以内が「良好」とされる。
INP(Interaction to Next Paint) は、ユーザーの操作(クリック、タップ、キー入力など)に対するページの応答性を測る指標。操作してから視覚的なフィードバックが得られるまでの時間を表す。同じくCore Web Vitalsのひとつで、200ms以内が「良好」とされる。
以下のグラフを見ていただきたい。これは実際の通販サイトにおける過去90日間のデータで、横軸に最小LCP、縦軸にCVR(成約率)をプロットしたものだ。
グラフを見ると、LCPの体験が良かったユーザーではCVRが2%近くに達している。しかしLCPが悪化するにつれてCVRは急激に低下し、1秒を超えるあたりからほぼ0%に近づいてその後は横ばいになる。
サイト全体のCVRは0.51%だが、これは良いLCP体験をした一部のユーザーが売上を支えており、悪いLCP体験のユーザーはほとんどコンバージョンせず売上に貢献していないという構造を反映している。
AI に退屈な作業をまかせ、自分の時間を確保する自動化は個人的に大きなテーマだ。以前、こちらの記事に多くの反響をいただいた。
あれから Claude Code や Gemini CLI などの AI コーディング CLI が続々と登場し、状況はまた大きく変わった。
前回は Mastra を用いて作業の自動化を図ったが、今回は AI コーディング CLI を活用し、もっと手軽にあなたが 「寝ている間に仕事をしてくれる小人のくつ屋さん」 を実現する方法を紹介する。
WebPやAVIFといった次世代画像フォーマットと、従来フォーマット(JPEG・PNG・GIF)に両対応し、ブラウザの対応状況によって出し分けるサイトが増えている。
弊社でもそのようなアシストを行うサービスを提供しているが、
次世代画像フォーマットに対応していない古いブラウザはもう絶滅寸前で、表示確認が面倒になってきた。
そこで対応画像フォーマットをサーバーに伝える役割を持つ、画像リクエストのAcceptヘッダを書き換えて旧ブラウザをシミュレートするChrome拡張機能を開発した。
📢 モデルの改訂について
本記事で使用している予測モデルには、選択バイアスによる歪みがあることが判明した。平均LCPが良好でも離脱したユーザーを「冷やかし層」として分析対象から排除した結果、残った「気まぐれ層」において高速体験ができたユーザーのパフォーマンスを過大評価してしまっていた。
このバイアスを補正した新しい予測モデルを公開している。収益予測には以下の記事を参照されたい。
弊社ではサイトスピードと収益の関係を研究し、「サイトを高速化すると結局、いくら儲かるのか？」 の予測モデルを考案している。
今回その予測モデルを改良して、ユーザーの行動をさらに明らかにしたところ意外な教訓が明らかになった。それが、
「サイト高速化で収益を上げるなら、遅い体験を救うより、すでに早い体験をさらに爆速にせよ」
である。
以下のグラフを見ていただきたい。これは実際の通販サイトにおいてサイトスピードに行動を左右されうるユーザー群の 平均LCPと注文成約率(以下CVRとする)の関係 を示したものだ。
平均LCPが約 1.19 秒までのユーザーのCVRは 13.22% にも及ぶが、平均LCPが悪化するにつれてCVRは急速に低下し、約 3 秒を超えると 0.35% 以下に落ち込む。
もっと衝撃的なのは次の事実だ。
全注文の57%は平均LCP 1.19 秒までの高速体験ができたユーザーによって占められ、90% は 2.3秒 までの準高速体験ができたユーザーによって支えられている。
通販サイトとは、
「魅力に気づいたユーザーのうち、たまたま快適な体験ができた一部だけが注文に到達する接客システム」
なのである。
なぜこのような分析結果が得られたか順を追って解説しよう。サイトスピードと収益に関する理解の解像度が格段に高まることを約束する。
Web開発は特に、ほとんどOSSの組み合わせと言ってよい。自分では何を書くかというと、ユニークなコアロジックや、アプリケーション固有のビジネスロジック、そしてそれらとOSS同士をつなぐ「接着コード」と言ってよいのだが、ビジネスロジックと接着コードは癒着しやすく肥大化しやすい。そうすると技術負債になる可能性が高い。
なぜ接着コード肥大化するかというと、「ちょうどいい粒度の部品」がないからだ。別にぴったりちょうどいいOSSがあればそれを使いたいのだが、それがないから接着コードにロジックを書いて、OSSの組み合わせを新たに書く。それがビジネスロジックと地続きに癒着していってしまう。
地味なツールだが、JPEGファイルのサムネイル(EXIF)を削除するGo言語のパッケージを公開した。
Go言語用のローカライゼーション(自然言語メッセージ翻訳)のためのパッケージをOSSとして公開した。
このローカライゼーションパッケージは、Movable Typeのローカライゼーションにインスパイアされた仕様となっている。
弊社ではWeb画像に関するサービスを展開しているが、一言にJPEG、PNG、GIFといっても内部的に多くのバリエーションがある。例えばJPEGであれば、Exifの有無や圧縮方式の違いなどだ。
これまで試験用の画像は断片的に収集、変換するなどして用意してきたが、それらバリエーションを包括的に網羅するデータセットを生成プログラムとともにOSSとして公開した。
弊社の画像系サービスでも今後はこのデータセットを活用していきたい。
ClaudeとClaude Codeを使ったAIコーディング(Vibe Coding)に夢中になっている。止められない時代の変化を感じた。
先ほど次のGo言語パッケージを公開したのだが、READMEにいたるまで100% AIによるコーディングである。
機能はシンプルだが、テストがかなり充実している。自分で書くとなると(そもそもこのテストが書ける自信すらないが)、数日〜1週間を要したと思う。しかしClaudeによる所要時間はたった3時間だ。
Vibe Coding (ヴァイブコーディング)が賑わっている。生成AIを積極的に利用し、自然言語によるVibe(雰囲気)でコーディングを進行する潮流だ。
まさにこのネットミームが相応しい。
自分も古いプログラマーなので、中身がよくわからないものを残す勇気は未だない。しかし使い捨てのプログラム、PoC的なプロトタイプ、個性のない小さなライブラリ開発などには今後、積極的に使っていこうと思う。
Webサイトの画像軽量化には、オープンソースによる内製から、さまざまな外部のサービスの活用まで多くの選択肢がある。
外部サービスはもちろんのこと、内製するにしても工数がかかり、費用は発生する。しかしこれまで画像軽量化の費用の妥当性についてはほとんど見聞きしたことがない。
サービスの料金表や、出された見積もりについてそれが妥当なのか、それとも払い過ぎなのか、画像軽量化サービスを提供する企業として費用対効果を真剣に考えてみた。
画像軽量化を検討する方にぜひ参考いただきたい。
研究ノートと銘打ったこのブログもだいぶ記事が溜まってきた。以前に投稿した記事もXなどで露出を図るとよいのだが、文面を考えるのが面倒でつい放置してしまっていた。
そこでAIに文面を考えてもらい、GitHub Actionsのスケジュールワークフローで定期的な宣伝を繰り返す仕組みを構築した。
ひとまず1日2回、以下のような過去記事へ誘導する投稿が無人で行われるようになった。
最近、Macbook ProをM1 ProからM4 Proにアップグレードしたので、LM Studio でローカルLLMを動かしてみたらさすがに早い。
そこに Qwen3 というまたすごそうなオープンソースのLLMが公開されたので、
Mastraに繋いでMCPサーバーを使うことを試してみた。
弊社アイデアマンズ株式会社のミッションについて少し言語化をしたい。
いくつかの事業を手掛けているが、共通するのは技術的な工夫で「Webにおけるムダを減らしたい」という思いである。
TypeScriptによるプログラムで、Zodで型を規定しつつ、Googleスプレッドシートを簡易的なデータベースとして利用できるモジュールを開発した。
グリム兄弟の「小人のくつ屋さん」を聞いたことがあるだろう。寝静まった真夜中に不思議な小人たちが靴を仕上げてくれる童話だ。
最近話題のAIエージェントとPlaywright MCP(ブラウザ操作MCP)は、自然言語による指示に基づき、あたかも人間に頼んだかのように自律的にブラウザを操作してくれる。
例えば先日、AIエージェントがブラウザを操作し、ヒューリスティックなUX診断を行う例が話題になっていた。
このようなAIエージェントによるブラウザ操作とGoogleスプレッドシートと連携し、何らかのテーマで多数のサイトやページを横断的に調査するバッチ処理に仕立ててみよう。すると調査対象リストをシートに書いておけば、寝ている間にAIエージェントが働いてシートを埋めてくれる。「小人の調べ屋さん」が実現する。
そのような仕組みを Mastra を用いて実装してみた。ソースコードも公開したので、ぜひアレンジして不思議な小人を見つけてほしい。
さまざまなサイトでアクセスランキングを目にするが、実際どのくらい採用されているのだろうか？ 記事コンテンツを中心としたいわゆるニュース系メディアサイト220サイトについて調査してみた。
その結果、約 74% のサイトでアクセスランキングが表示されている ことがわかった。
また、一般性の高いメディアにはアクセスランキングが多く、専門性が高いメディアには採用が少ない傾向も見られた。
ランキングコーナーの名称もさまざまだが、「アクセスランキング」という呼称が最も多かった。
弊社でGA4を利用したアクセスランキング表示サービス Rankelt4 を運営している一環としての調査だが、メディアサイト運営者の参考になれば幸いである。
メディアサイトについて横断的な調査をしたいと思い、AIでリストを作ってみた。ディープリサーチによるリスト作成がどのくらいの分量まで行ってくれるのかも確かめたかった。
以前であれば数十件でも素人がバランスよく集めるのは大変だったが、今はコーヒーを飲む間にできてしまう。本当にすごい時代になった。
今回の手順と、作成されたリストを共有したい。
なお、SNSやUGCも広い意味ではメディアサイトだが、ここではメディアサイトは「責任編集された記事コンテンツを配信するニュース形式のサイト」としている。
体感スピードの速い通販サイトを実現するにはどうすべきか、これまでの経験をもとに設計と実装のプラクティスを紹介する。
この記事は、新たに立ち上げるサイトや大幅なリニューアルを行うことを前提としている。既存サイトの手直しにはあまり実践的な内容ではないので、あらかじめ注意されたい。
また、最新の技術は全く紹介しない。最新情報をキャッチアップしたい方には不向きだろうが、本当に汎用的で実績のあるプラクティスだけを解説する。
Web 画像データを WebP や AVIF などの次世代画像フォーマットにすると、同じ画質でもそのデータ量を大幅に削減できる。AWS などの海外クラウドサービスではデータ送信料金を削減でき、ユーザーの通信負担も軽くなる。その効果は小さくない。
しかし、将来的には次世代画像フォーマットの全面移行もあるだろうが、従来フォーマット(JPEG・PNG・GIF)はその活躍期間が長すぎた。供給側のスキルやシステム仕様がすぐには追いつかないし、次世代画像フォーマット自体への信頼感の醸成(WebP や AVIF は本当に次の標準になるのか？)にもまだ当面の時間を要すると考える。
したがって当面の間は、元画像は従来フォーマット(JPEG・PNG・GIF)で供給しつつ、次世代フォーマットへの変換は配信目的に留まる体制が続くと踏んでいる。
この記事では次世代画像フォーマットの代表を仮に WebP とし、従来フォーマットの画像をどのタイミングで WebP に変換するのがよいか論じてみたい。
システムにおいて、キャッシュファイルやバックアップファイルはできるだけ長く保持しておきたいが、それによりストレージの空き容量が枯渇することは避けたい。
findコマンドを使い、例えば「1 週間以上古いファイルを削除する」といったスクリプトの例はよく目にする。しかし本質的な解決にはなっていない。1 週間でどのくらいストレージを消費するかは正確には予測できないからだ。
そこで以下の Go 言語製ツールを公開した。
このツールを使えば「10GB に収まるよう古いファイルから削除する」といった目標使用量に応じたクリーニングを実行できる。
AWS に代表される海外クラウドサービスの利用は、貿易という観点では輸入になる。国内における海外サービスの利用は増す一方であり、IT 分野においては輸入超過の赤字が体質化している。それが「デジタル赤字」の問題だ。
この デジタル赤字を縮小する意外な方法が Web 画像の軽量化だ。
画像軽量化というと表示高速化のイメージが強いが、ネット回線が高速になった現在では期待するほどのインパクトはなくなった。
それよりはクラウドコストの面において確実な効果があり、事業者・ユーザー・国の貿易収支にメリットのある、まさに「三方よし」の打ち手になる。
次のグラフィックツールの拡張機能(プラグイン、アドオン、アプリなどの呼称)について軽く調査した。
いずれも Web 技術(HTML・CSS・JavaScript)で作ることができる。HTML と CSS でユーザーインターフェースを整え、JavaScript でアプリケーションとの連携や独自の機能を実装する。
これはまさにブラウザの拡張機能と同じアプローチであり、多くのアプリケーションがそれに寄せてきている流れを感じる。
プラグイン開発と言うとハードルが高い印象があるが、今や Web のフロントエンド技術があれば簡単に挑戦できる時代になった。簡単なものであれば AI だけで実装できてしまうかもしれない。
個人的なメモも兼ねて、それぞれのグラフィックツールの拡張機能の作り方を紹介する。
Core Web Vitals をはじめとする多くサイトスピード指標は対数正規分布に基づくとされている。
その計算についてこれまでプロジェクトに応じて実装していたが、共通して利用できるユーティリティライブラリを公開した。
インストールや基本的な使い方は日本語の README を参照されたい。
Core Web Vitals をはじめとするサイトスピード指標の多くは、対数正規分布 に基づくとされている。
実際に Google はその前提に基づき PageSpeed Insights のスコアを設計しており、弊社も「そのようなものだ」としてデータを扱っている。
しかし今一度、その前提を自分の目で確かめてみようと思った。
この記事では、サイトスピードに特化した無料のアクセス解析ツールである Speed is Money で計測したサイトスピード指標が本当に対数正規分布に基づくのか、いくつかの視点から確認をしてみた。
弊社が提供するアクセスランキング機能運用サービス Rankelt4 に、AIレビュー機能 を追加した。
CDTV(カウントダウンTV)のようなランキング形式の音楽番組をイメージしてほしい。先週のトップ10を振り返り、今週のトップ10を楽しみながらMCがコメントする。
AIレビュー機能はいわばそのようなレポート機能だ。Ranklet4に設定いただいたアクセスランキングを活用し、生成AIで上位記事とその推移に関するレビューを自動作成する。
レビューは毎週または毎月、メールで自動配信もできる。メディアやブログ運用のアシスタントとしてぜひ活用いただきたい。
Core Web Vitalsが検索順位に影響すると言われて数年が経った。SEOに関わらず、サイトスピードに関心のあるサイトは少なくないだろう。
そこで日本の主要なECサイト100サイトについて、Core Web Vitalsが改善の方向に向かっているのか調査してみた。
やはり感覚のとおり、CLSは多くのサイトで改善済みだがLCPはほとんど改善が進んでいない実態が見えた。
このブログでは最近、Core Web VitalsやPageSpeed Insightsに関する記事を続けて書いた。
きっかけは2024年11月23日のMTDDC Meetup TOKYO 2024にて登壇させていただくことになり、これまでの集大成を語りたく「これで完璧！超実践的Core Web Vitalsの健全化手法」と仰々しいテーマにしたのだが、プレゼンテーションの構成を検討するうち、話したいことが多すぎてまったく完璧ではなくなってしまった。
そこで講演では話しきれない内容を補完するために、テーマについて詳細な記事を書き始めた。
本記事はその講演のまとめと、これまで書いた記事の総集編をお届けする。
INP(Interaction to Next Paint)は、2023年4月にFID(First Input Delay)と置き換わる形でCore Web Vitalsに昇格した指標だ。
この指標はページの読み込みに関する指標ではなく、ユーザーの操作に対する応答の速さを示す値である。
性能の低いPCを使っていると、画面上のメニューやボタンなどをクリックしてもすぐに反応せずイライラすることがあるだろう。同じ事象はWebページでも起こりうる。それがINPと捉えて間違いない。
本記事では、このINPの改善術について解説する。
Core Web Vitals改善術の一環としてサードパーティタグの扱いについて解説する。
サードパーティタグがCore Web Vitalsに影響するというのは奇異に聞こえるかもしれないが、実は大いに関係がある。
サードパーティタグはGoogle Tag ManagerやGoogle Analyticsに代表される、外部の企業から提供されるHTMLタグであり、そのほとんどはJavaScriptを実行する。JavaScriptの動作は本来とても重いものだ。
多くの企業がサードパーティタグのメリットだけに注目し、負荷については空気のようなものと思い込んでいるが、筆者の経験上、Core Web Vitals改善の鍵はこのサードパーティタグの扱いにあると言っても過言ではない。
いわゆるWeb技術によるスピード改善と、サードパーティタグについて改善は、アプローチも責任者も違う異質な業務となる。そのためひとつの独立した記事として論じたい。
Core Web Vitalsのひとつ、LCP(Largest Contentful Paint)の改善手法について解説する。
同じCore Web VitalsのCLS(Cumulative Layout Shift)は丁寧にコーディングを行えば改善できるが、それに比べてLCPの改善は難しい。
実際にSEOの文脈でCore Web Vitalsが話題になった2021年〜2022年ごろ、CLSの改善は多くのサイトで見られたが、LCPまで改善できたサイトは少ない。
加えて、ネットの記事にはLCPの改善について誤解が多い。よく見られるのが画像の軽量化であるが、画像データがLCP悪化の主な要因であるケースなどほとんどない。
この記事ではLCP改善の実践的な手法を紹介したい。
Core Web Vitalsの中で INP(Interaction to Next Paint) は、実際のユーザーがWebページを操作して初めて計測される指標だ。
そのため指標が悪い原因を正確に特定するのが難しい。
そこでユーザー環境で生じたINPを計測、BigQueryに収集し、調査に活かす仕組みを構築した。
そのデータを用い、理論に頼るだけではない実践的なINPの改善提案サービスを開始する。
Core Web Vitalsのひとつ、CLS(Cumulative Layout Shift)の改善方法について解説する。
CLSの改善は他の指標に比べて難しくはない。丁寧にコーディングを行うことでほぼ解決できる。それゆえ改善済みのサイトも多い。
しかしJavaScriptによるコンポーネントのレイアウトを制御できていないWebページはまだ散見される。
この記事ではJavaScriptによるコンテンツの挿入が行われるページや、カルーセルスライダーを用いたページについて実践的なアドバイスを記した。
PageSpeed InsightsはWebページのスピードを評価する際に便利なツールではあるが、非常にミスリードを起こしやすい。
目立つのはパフォーマンススコアと指摘事項の数々だが、弊社がフロントエンドのスピード改善を提案する上でそれらを見ることはほとんどない。
厳しい言い方をするとスコアはまやかしで、指摘事項は時代遅れである。加えてスコアと指摘事項に因果関係もない。
断っておくがツールを非難したいのではない。スコアと指摘事項に振り回されては、サイトを高速化したいという本来の目的は一向に果たせないことをお伝えしたい。
アクセスランキングはWebサイトの人気機能のひとつであるが、弊社ではGA4を活用したアクセスランキング表示のWebサービス Ranklet4 を提供している。
「どのサイトでもGoogle Analyticsでアクセス解析をしているのだから、そのデータを活用してアクセスランキングを簡単に表示できるようにしよう」というアイデアから始めた無料サービスだ。
Google Analytics(以下GA4)のデータを使うのは、単に「せっかくデータを取っているから」といった受け身な理由に限らない。アクセスランキングを自前で実現するのはなかなか大変なのだ。
そんなアクセスランキング実現のつらみと、GA4を活用することの意義について話をしたい。
サイトスピードが遅いとサイトの収益性が悪化し、逆に早ければ儲かる。それはよく知られている。しかし なぜそうなるのか説明 するには、少し高い解像度で理解していないと難しい。
サイトスピードが早くなると収益が上がると言うが、その財源は一体どこにあるのか？ 誰がどう払ってくれるものなのか。
単純化すると、サイトスピードは機会損失率と成約率のトレードオフを調整するレバー のようなものだ。
実はWebサイトは、サイトスピードに起因する機会損失を常に抱えている。サイトスピードが早くなれば機会損失率が減って成約率が増える。遅くなればその逆に作用する。
機会損失という見えないものを見るにはデータが要る。通販サイトの実例を交えて詳しく見てみよう。
ChatGPT with canvasをご存知だろうか。AIとともに、ソースコードや文章を編集できる機能だ。
GitHub CoPilotもそうだと言えるし、これまでも近いことはできた。しかし**「共通の作業対象」**がインターフェースや出力として明確になった点が新しい。
このような共同作業を、Difyのチャットでも実現する方法を解説したい。
アイデアマンズ株式会社のロゴマークはプログラムで自動生成している。
この度、ロゴマークの生成プログラムを刷新し、alogorithm2としてリリースした。
 |
 |
 |
 |
 |
 |
DifyのソースコードにはDocker Composeプロジェクトが同梱されている。
それを利用すると自分専用のDify環境をサクッとセルフホストできるのだが、それを本番運用に利用するのは心許ない。
ではAWS上で、ガチ目のDifyスタックを展開するとしたらどうするか考えてみた。
Difyでナレッジを取り込むと、その内容はベクトルデータベースに格納される。
Difyは多種多様なベクトルデータベースに対応しているようで、環境設定ファイルを眺めているだけでも興味深い。
Difyが対応していると思われるベクトルデータベースを調べてみた。
この記事はVPSでお安く自分専用のDifyを持つ方法の続きだ。
Difyは、WebクローラーであるJina ReaderまたはFirecrawlと連携することで簡単にRAGを実現できる。
Firecrawlもオープンソースでセルフホストできる。そこでDifyをインストールしたVPSにFirecrawlもインストールし、こちらもお安く実現してみた。
その手順を紹介する。
LLMアプリ開発が楽しいDifyだが、無料だとできることが限られ、有料プランは個人にはちと高い。3アカウントも手に余る。
そこでオープンソース版をVPSにセルフホストしてみた。これなら月額1500円程度から、自分だけのDifyを持つことができる。
その手順を紹介したい。
LLMアプリの開発プラットフォームDifyを使い始めた。もう楽しすぎる。
「便利そうだけど、APIを使ってプログラミングした方が柔軟じゃないか？」とすぐに飛びつかなかったかつての自分に、「Difyはいいぞ！」と諭すつもりで、どんなことができて、どんなメリットがあるか紹介したい。
まだ触りたてなので間違っているところもあるかもしれない。間違いは容赦いただきたい。
以前こちらの記事「サイトスピードと幸福の心理学」の要約をXに載せた。サイトスピードに関する心理学的エピソード集で大変面白かった。
「サイトの速度と人間の幸福の心理学」
— アイデアマンズ@フロントエンドWeb高速化 (@ideamans) February 1, 2024
The psychology of site speed and human happinesshttps://t.co/UfaSTXQIOg
この記事のトピックをまとめてみました。
1.
当たり前だが人間は待ち時間が嫌い。待たされるくらいなら歩かされた方がまし、というくらい。…
VPSなどの素のサーバでWebアプリを公開するとき、SSLをどうするかという問題がある。
弊社では、Amazon Route 53でDNS運用、lego (Go言語製のLet's Encryptクライアント)で取得した証明書を用い、nginxのDockerコンテナを使った汎用的なSSLゲートウェイを立てている。
そのノウハウを共有したい。一度慣れておくとWebアプリの公開が気楽になる。
そろそろWeb画像はWebPのみの配信でよいのではないか？
このテーマについて賛成論と反対論をしてみたい。
弊社ではクライアントとのソースコード共有や、Wikiによるドキュメントの共有のためにGitLabをセルフホスティングしている。
GitHubがあるのにセルフホスティングするのは時代に逆行していると思われるが、動機やメリットもある。
そしてこのGitLabセルフホスティングは、いろいろ工夫をしながら実質的に月額500円程度のコストで実現している。
その辺の話をとりとめもなくしてみようと思う。GitLabの自社運用を検討している方の参考になれば嬉しい。
弊社ではクライアントとのソースコードやWikiによるドキュメント共有に、自前のGitLabを使うことがある。
よくある操作を毎回GUIから行うのが手間なので、Go言語によるCLIツールを作り、せっかくなのでオープンソースにした。
