ハリーロバーツとのスマッシングポッドキャストエピソード34：Webパフォーマンスの状態は何ですか？

公開: 2022-03-10

簡単なまとめ↬このエピソードでは、Webパフォーマンスについて説明します。 2021年のパフォーマンスの状況はどのようになっていますか？ドリュー・マクレランが専門家のハリー・ロバーツと話をして調べます。

このエピソードでは、Webパフォーマンスについて話します。 2021年のパフォーマンスの状況はどのようになっていますか？私は専門家のハリー・ロバーツと話をして調べました。

メモを表示

ハリーは、2021年5月にSmashingを使用してWebパフォーマンスマスタークラスワークショップを実施しています。公開時点では、アーリーバードの大幅な割引がまだ利用可能です。

Twitterでハリー
ハリーのコンサルティングサイトCSSWizardry
ビデオコース15％割引を含むCSSウィザードリーを高速化するために私が行ったすべてのこと
15％割引を含むコンサルタントeBookへの質問
WebVitalsのWeb.devガイド
ドリューのお気に入りのOXOGoodGripsエッグビーター

毎週の更新

Webデザイントレンド2021：SuzanneScaccaによって書かれたレポート
FortuneIkechiによって作成されたReactアプリケーションでのGrommetの使用
JohnAgbanusiによって書かれたEthereumブロックチェーン用のNode.jsAPIを構築する方法
VitalyFriedmanによって書かれたSmashingMagのパフォーマンスをどのように改善したか
BeccaKennedyによって書かれたフリーランスプロジェクトにノーと言うとき

トランスクリプト

チャーリー・ジェラルドの写真 Drew McLellan：彼は、英国のリーズ出身の独立したコンサルタントWebパフォーマンスエンジニアです。彼の役割では、世界最大で最も尊敬されている組織のいくつかが、より速く、より信頼性の高いエクスペリエンスを顧客に提供できるように支援しています。彼は招待されたGoogleDeveloperExpert、Cloudinary Media Developer Expert、受賞歴のある開発者、そして国際的な講演者です。つまり、彼はWebパフォーマンスに関しては自分のことを知っていますが、彼が14本の腕と7本の脚を持っていることを知っていましたか？私のスマッシングの友達、ハリー・ロバーツを歓迎してください。こんにちはハリー、お元気ですか？

ハリー・ロバーツ：ねえ、私は大破している。どうもありがとう。明らかに、14本の腕と7本の脚…それでも通常の問題を引き起こしています。ズボンを購入することはできません。

ドリュー：そして自転車。

ハリー：うん。さて私は3台半の自転車を持っています。

ドリュー：それで、残念ながら自転車についてではなく、今日あなたと話をしたかったのですが、それ自体は楽しいでしょう。 Webパフォーマンスについてお話ししたいと思います。個人的にはとても情熱的なテーマですが、ボールから目を離して他の仕事に携わった後、パフォーマンスの仕事に戻ったときに心配する分野の1つです。私が扱っている知識が本当にすぐに古くなるのではないかと心配しています…最近のWebパフォーマンスは、私が認識しているほど速く動いていますか？

ハリー：これは…私はこれをあなたに良いと言っているだけではありません。私はこれについてかなり最近考えていて、半分あると思うので、それはとても良い質問です。私がクライアントに伝えようとしていることの1つは、実際にはそれほど速く動かないということです。主な理由は、これが私がいつも使用しているサウンドバイトであるため、ブラウザに賭けることができるからです。もちろん、ブラウザは20年間のレガシーを維持しなければならないため、ブラウザの動作を根本的に変更することは実際には許可されていません。したがって、一般的に、ブラウザに賭けて、それらの内部がどのように機能するかを知っていて、TCP / IPが決して変わらないことを知っている場合…したがって、かなり固まっている特定のものは、概して、ベストプラクティスは常にファンダメンタルズが関係するベストプラクティス。

ハリー：それがもっと面白くなるのは…私がますます目にしているのは、サイトの速度の問題に関しては、自分たちを隅々まで描いているということです。ですから、私たちは実際に自分たちのために多くの問題を引き起こしています。つまり、現実的に意味するのはパフォーマンスです…それは動くゴールポストだと思います。 Webの風景や地形が変化し、Webの構築方法や作業方法が変化すればするほど、私たちは新たな課題を提起します。したがって、クライアントでより多くの作業を行うようになると、5年前に解決した場合とは異なるパフォーマンスの問題が発生しますが、これらのパフォーマンスの問題は、ブラウザの内部に関係しており、概して5年間変更されていません。その多くは状況によって異なります…そして、それには確かに2つの明確な側面があると思います…クライアントはブラウザに頼り、標準に頼ることをお勧めします。変更することはできず、ゴールポストは実際には動かないからです。。しかし、もちろん、それはより現代的で、おそらくもう少し興味深い開発手法と融合する必要があります。だからあなたはあなたを守ります…まあ、私は「両方のキャンプに1フィート」と言うつもりでしたが、私の7フィートでは、私は…4と3にする必要があります。

ドリュー：ファンダメンタルズは変わらず、TCP/IPのようなものも変わらないとおっしゃいました。変化したことの1つ…「ここ数年」と言いますが、これは実際には少し前に戻っていると思いますが、クライアントとサーバー間で通信するための確立されたプロトコルHTTPを使用していたという点で、HTTPです。 H2を取得しましたが、これはすべてバイナリで異なります。そして、それは多くのことを変えました…それはパフォーマンス上の理由で、既存の制限のいくつかを取り除くことでした、しかしそれは変化であり、そのプロトコルのために最適化する必要がある方法が変わりました。それは今安定していますか？それともまた変わるのでしょうか、それとも…

ハリー：それで、私がもっと学びたいことの1つは、質問の後半であり、再び変化することです。 QUICとH3をもっと調べる必要がありますが、クライアントにとって役立つには少し遠すぎます。 H2に関しては、状況は大きく変化しましたが、H2は多くの誤った約束であり、H1が発売されたことを考えると、それは注目に値することだと思います。つまり、1.1は1997年でした。そのため、H2に取り組む時間はたくさんあります。

ハリー：主な利点は、それを理解している、または現在のフライトリクエストで無制限であると認識しているWeb開発者だと思います。したがって、一度に6つのディスパッチおよび/または6つの実行中のリクエストではなく、潜在的に無制限、無限です。ただし、非常に興味深い問題が発生します。視覚的な補助なしで説明するのは非常に困難ですが、H1またはH2を実行しているかどうかに関係なく、同じ量の帯域幅を使用できますが、プロトコルによって接続が高速化されることはありません。したがって、一度に24個のファイルを要求することでネットワークをフラッディングする可能性は十分にありますが、そのための十分な帯域幅がありません。したがって、一度に管理できるのはおそらくそのほんの一部であるため、実際にはこれ以上速くなることはありません。

ハリー：そして、あなたが考えなければならないことは、ファイルがどのように反応するかということです。そして、これは私がクライアントのワークショップなどで経験するもう1つのプロのヒントです。人々はH2ウォーターフォールを見ると、従来の6つのディスパッチリクエストの代わりに24が表示される可能性があることがわかります。24のリクエストをディスパッチすることは実際にはそれほど有用ではありません。便利なのは、それらの応答が返されるときです。また、24個のリクエストをディスパッチする可能性があるため、ウォーターフォールの左側は非常に美しく急勾配に見えますが、帯域幅の量を制限する必要があるため、すべてがかなりずらして順番に返されます。すべての応答を同時に実行することはできません。

ハリー：もう1つは、すべての応答を同時に実行すると、応答がインターリーブされるということです。つまり、夜は各ファイルの最初の10％を取得し、次の20％…JavaScriptファイルの20％は役に立たないのです。 JavaScriptは、100％が到着するまで使用できません。つまり、実際には、応答を見るとH2の滝がどのように現れるかがわかります…とにかく、H1のように見えますが、よりずらされています。それで、H2、それは売られ過ぎだったと思います、あるいはおそらくエンジニアはそれがどれほど効果的であるかについて上限があると信じるように導かれなかったでしょう。アセットを過度にシャーディングしている人がいて、20個ある可能性があるため…24という数字を維持しましょう。2つの大きなJSファイルではなく、24の小さなバンドルがある可能性があります。彼らはまだかなり順番に戻ってきます。より多くの帯域幅を自分で魔法にかけたことがないため、すべてが同時に到着することはありません。

ハリー：もう1つの問題は、各リクエストに一定量のレイテンシがあることです。たとえば、2つの大きなファイルを要求していて、往復が100ミリ秒でダウンロードが250ミリ秒、つまり250ミリ秒の2倍だとします。最大24のリクエストを乗算しても、一定のレイテンシがあります。これは100ミリ秒と決定したため、2400ミリ秒のレイテンシと24回のレイテンシがあります。250ミリ秒のダウンロードではなく、25ミリ秒のダウンロードとしましょう。レイテンシーは一定のままであり、そのレイテンシーをより多くのリクエストに掛けるだけなので、実際には時間がかかります。したがって、H2がこの魔法の弾丸であることを読んだクライアントを見ることになります。彼らは破片になります…ああ！開発プロセスを単純化することはできませんでした。バンドルや連結などを行う必要はありません。そして最終的には、リクエストを分散させることができたため、最終的には遅くなります。これは約束でしたが、レイテンシーは一定のままであるため、実際にはブラウザーでn倍のレイテンシーが発生します。私が言ったように、ビジュアルなしでそれを説明しようとすると、本当に難しい、おそらく無意味ですが、人々が期待していることと比較して、H2がどのように現れるかは注目に値します。

ドリュー：シャーディングプロセスにはまだメリットがありますか？それでも、ロット全体を取得するには同じ時間がかかりますが、最初のロットの100％を取得するまでに、24番目に作業を開始できます。 24日が終わる前に実行を開始します。

ハリー：ああ、男、別の素晴らしい質問。したがって、絶対に、物事が正しく進み、よりH1に見える応答で現れる場合、アイデアは、ファイル1が最初に返され、2、3、4になり、次に到着した順序で実行できるようになります。したがって、物事が同時に到着することを保証することにより、実際に総時間を短縮することができます。ウォーターフォールの代わりにWebページを見て、リクエストがインターリーブされていることに気付いた場合、それは悪いニュースです。私が言ったように、JavaScriptファイルの10％は役に立たないからです。

ハリー：サーバーが適切に機能し、送信、送信、送信、送信、送信を行うと、サーバーの速度が向上します。そして、キャッシュ戦略のノックオンのメリットをよりきめ細かくすることができます。したがって、本当に厄介なのは、日付ピッカーウィジェットのフォントサイズを更新することです。 H1の世界では、サイトのワイドCSSのおそらく200キロワットのバストをキャッシュする必要があります。一方、今は、バストのdatepicker.cssをキャッシュするだけです。ですから、そのような派生的なメリットがあります。これは間違いなく、間違いなく非常に価値があります。

ドリュー：魔法のようにすべてのリクエストを一度に取り戻すシナリオでは、明らかにクライアントをダウンさせる可能性がありますね。

ハリー：ええ、潜在的に。そして実際に起こることは、クライアントが大量のリソーススケジューリングを行わなければならないことです。そのため、最終的にはすべての応答が同時に返されるウォーターフォールになり、その間にかなり大きなギャップが生じます。到着した最後の応答とその実行能力。したがって、理想的には、JavaScriptについて話しているときは、ブラウザーがすべてを要求順序で、基本的には定義した順序で要求し、サーバーがすべてを正しい順序で返すようにして、ブラウザーが実行できるようにする必要があります。それらを正しい順序で。なぜなら、あなたが言うように、それらがすべて同時に戻ってきた場合、一度に実行する大規模なJavaScriptがありますが、それでもスケジュールする必要があります。そのため、ファイルが到着してから有用になるまでに最大2秒の疑問が生じる可能性があります。つまり、実際には、H1…理想的には、H2要求のスケジューリング、H1スタイルの応答であると思います。そうすれば、到着したときに便利になります。

ドリュー：基本的に、スキーで滑れるような応答の滝を探しています。

ハリー：そうだね。

ドリュー：しかし、パラシュートは必要ありません。

ハリー：うん。そして、それは本当に難しいです…大声で言うと、それは本当に些細なことのように聞こえますが、H2の販売方法を考えると、それはかなり…難しいことではありません。彼らにとって…H1がどのように機能するかを考えると、それほど悪くはありませんでした。そして、そのような応答を受け取った場合、「そうそう、私は今それを見ることができます」。私はこれまでパフォーマンスエンジニアにこれを教えなければなりませんでした。私がしていることをする人。私はパフォーマンスエンジニアに、リクエストがあったときにあまり気にしないことを教えなければなりませんでした。私たちはいつ応答が役立つかを本当に気にかけています。

ドリュー：特に過去5年間で、物事が非常に急速に進んでいるように見える理由の1つは、パフォーマンスがGoogleにとって大きなトピックであるということです。そして、グーグルがこのようなものの後ろに重みを置くとき、それは牽引力を得る。基本的に、パフォーマンスはユーザーエクスペリエンスの側面ですよね？

ハリー：ああ、つまり…これは本当に良いポッドキャストです。私はこれについて30分前に考えていました。私は、これについて30分前に考えていたことを約束します。パフォーマンスはアクセシビリティに適用されます。あなたは誰かがあなたのコンテンツにアクセスできる可能性を保証または増加させています、そして私はアクセシビリティは常にただ…と思いますああそれはスクリーンリーダーですよね？視力のない人です。アプリではなくウェブサイトを構築するという決定…決定は、より多くのオーディエンスにアクセスすることです。つまり、パフォーマンスはアクセシビリティに適用されるため、ユーザーエクスペリエンスになります。そして、そのユーザーエクスペリエンスは、「誰かがあなたのサイトを体験することさえできますか」という終止符に帰着する可能性があります。または、「その経験は楽しいものでしたか？ボタンをクリックすると、タイムリーに反応しましたか？」だから私は100％同意します。それがGoogleがそれに重点を置いている理由の多くだと思います。それはユーザーエクスペリエンスに影響を与えるためです。誰かが検索結果を信頼する場合は、その人に次のようなサイトを提供したいと考えています。彼らは嫌いになることはありません。

ドリュー：そしてそれは…あなたが考えるすべて、あなたが考えるすべての利点、ユーザーエクスペリエンス、エンゲージメントの増加など、それは間違いなく本当ですよね？遅い経験よりも早くユーザーをサイトから遠ざけるものはありません。とてもイライラしますね。ナビゲーションがそれほど明確ではないことがわかっているサイトを使用し、リンクをクリックして「これは私が欲しいものですか？そうじゃないの？」そして、そのクリックを行うためのコスト、ただ待つ、そしてあなたは戻るボタンをクリックし、そしてそれを待つ必要があります、そしてそれはただ…あなたはあきらめます。

ハリー：ええ、それは理にかなっています。あなたがスーパーマーケットに立ち寄り、それが絶対に人でいっぱいになっているのを見るなら、あなたは最低限のことをするでしょう。あなたはそこでたくさんのお金を使うつもりはありません、それは「ああ、私はただミルクが必要です」のようです。いい経験なら、「ああ、まあ、ここにいる間に…ああ、そうだね…ああ、明日の夜に料理する」などとか。それでも、Webを構築してから30年経った今でも、Webを構築する人々でさえ、無形であるために苦労していると思います。彼らは、実際の店であなたを苛立たせるものがオンラインであなたを苛立たせるだろうと本当に考えるのに苦労しています、そしてそれはそうです、そして統計はそれが持っていることを示しています。

ドリュー：ごく初期の頃は、90年代後半のことを考えていて、ここで自分の年齢を示しています。ウェブサイトを構築するときは、パフォーマンスについて非常に考えていましたが、人々のつながりという観点からパフォーマンスについて考えました。使用はとても遅かった。ダイヤルアップ、モデム、電話回線、28K、56Kモデムについて話しているのですが、ある時点で、画像の1行おきに無地で空白にして、これを実現する傾向がありました。ベネチアンブラインドを通して画像を見ているようなものだと想像できます。そして、それが圧縮に役立ったので、私たちはそれをしました。 1行おきに圧縮アルゴリズムが可能であるため-

ハリー： 1つのポインターに折りたたむ。

ドリュー：うん。そのため、画像サイズを大幅に縮小しながら、取得することができます…そしてそれはデザイン要素になりました。みんなやってた。おそらくジェフリーゼルドマンはそのアプローチを開拓した最初の一人だったと思います。しかし、私たちが考えていたのは、主に、どれだけ迅速に問題を解決できるかということでした。ユーザーエクスペリエンスではなく、私たちが考えていなかったからです…つまり、基本的にユーザーにサイトを離れてほしくないので、ユーザーエクスペリエンスだったと思います。しかし、私たちは物事を本当に速くなるように最適化するのではなく、それが理にかなっているのであれば、本当に遅くなることを避けようと考えていました。

ハリー：うん、うん。

ドリュー：そして、ADSL回線のような速度が普及するにつれて、私たちはそれらの用語で考えるのをやめ、まったく考えなくなったと思います。そして今、私たちはモバイルデバイスを使用している状況にあり、それらは接続が制限されており、おそらくCPUが遅いので、もう一度考えなければなりませんが、今回は利点を得るという観点からです。物事のユーザーエクスペリエンスの側面だけでなく、それはコストと利益を上げる能力の点で真のビジネス上の利益をもたらす可能性があります。そうじゃない？

ハリー：うん、すごい。つまり、それをどのように表現するかわからない。ここで自分自身を撃つことはありませんが、私がクライアントに強調しようとしていることの1つは、サイトの速度が競争上の優位性をもたらすということですが、競争上の優位性をもたらすことができるのは1つだけです。誰も購入したくない製品を持っているなら、あなたのサイトがどれほど速いかは問題ではありません。同様に、誰かが本当に世界最速のWebサイトを望んでいる場合は、画像を削除し、CSSを削除し、JavaScriptを削除してから、提供する製品の数を確認する必要があります。これは、サイトの速度が要因ではないことを保証するためです。しかし、調査によると、数百万のオーダーまで高速であるという大きなメリットがあります。私が話している間、私はクライアントと協力しています。特定のページを1秒速くレンダリングできる場合、またはペイントの最大コンテンツが1秒速くなった場合、年間1.8百万の価値があり、これは大きな数字です。

ドリュー：それはほとんどあなたの料金を支払うでしょう。

ハリー：ねえ！ええ、ほとんど。私は彼らにこう言いました。「ほら、2年後にはこれはすべて報われるでしょう。あなたも壊れるでしょう」。私は望む。しかし、ええ、クライアント向けの側面はありますか…申し訳ありませんが、E-Comサイトを持っている場合、顧客向けの側面はより多くのお金を費やすことになります。あなたが出版社である場合、彼らはより多くの記事を読むか、より多くの分数のコンテンツを見るでしょう、あるいはあなたがすることはあなたが測定するあなたのKPIです。それはSmashingサイトにある可能性があり、バウンスしなかった可能性があります。私たちが本当に簡単かつ高速にしたので、実際にはさらにいくつかの記事をクリックします。そして、より高速なサイトは実行するのに安価です。キャッシュ戦略を分類した場合は、サーバーから人々を遠ざけることになります。アセットを最適化すると、サーバーから取得する必要のあるものはすべて、はるかに軽量になります。実行するのがとても安いです。

ハリー：問題は、そこにたどり着くにはコストがかかるということです。スコット・ジェールはおそらく最も多くのことを言ったと思います…そして最初に彼からそれを聞いたので、彼がそれを思いついたと思いますが、「速いウェブサイトを作るのは簡単ですが、ウェブサイトを作るのは難しいです速い"。そして、それはとても簡潔です。 Webパフォーマンスがやるべきことのリストに押し下げられるかもしれない理由は、クライアントに「私があなたのサイトを1秒速くすると、年間1.8ミル余分に稼ぐ」と言うことができるかもしれないからです。「ApplePayをチェックアウトに追加したばかりの場合は、さらに5ミルを稼ぐことになります。」したがって、それはWebパフォーマンスのすべてではなく、決定的な要因でもありません。これは、特にE-Comオンラインの場合、はるかに大きな戦略の一部です。しかし、その証拠は、私が小売クライアントであるE-Comクライアントで直接測定したことです。その場合はまさにそこにあります、あなたは絶対に正しいです。それは競争上の優位性であり、それはあなたにより多くのお金を稼ぐでしょう。

Drew：昔もさかのぼりますが、Steve Soudersのような人々は、Webパフォーマンスについて実際に書き始めた最初の人々の一部でした。そして、スティーブのような人々は基本的に、「バックエンドインフラストラクチャを忘れてください。ここでは、すべての利益がブラウザにあり、フロントエンドでは、すべてが遅くなります」と言っていました。それは15年経った今でもそうですか？

ハリー：うん、うん。彼は当時と現在の間にテストを再実行しましたが、実際にはギャップが広がっていたため、実際にはネットワーク上でよりコストがかかります。しかし、それに対抗するものがあります。つまり、バックエンドのパフォーマンスが非常に悪い場合、ゲートからゆっくりと出発した場合、フロントエンドに戻ることができるのはそれほど多くありません。現時点でクライアントを取得しました。最初のバイトまでの時間は1.5秒です。したがって、1.5秒より速くレンダリングすることはできないため、これが上限になります。フロントエンドで時間を取り戻すことはできますが、最初のバイトまでの時間が非常に悪い場合は、バックエンドの速度が低下し、フロントエンドのパフォーマンスの取り組みがどれだけ速くなるかには限界があります。しかし、絶対に。

ハリー：しかし、それは変化しているからです…まあ、それは変化していないと思います、悪化していると思います。私たちはクライアントにもっとプッシュしています。以前は「サーバーは高速ですが、その後は疑問符がたくさん表示されます」というケースでした。これはいつも聞いているからです。「すべてのユーザーはWiFiで実行しています。彼らはすべて私たちのオフィスで働いているので、すべてデスクトップマシンを持っています。」ええと、いや、今はみんな家で仕事をしています。あなたは選ぶことができません。つまり、ここですべての疑問符が出てきます。ここでスローダウンが発生し、実際に制御することはできません。その後、私たちは今、クライアントにもっと多くを置く傾向があるという事実。つまり、クライアントでの実行時間全体です。とにかくすべてのアプリケーションロジックをサーバーから移動したので、最初のバイトまでの時間は非常に最小限に抑えられます。 CDMから私のサーバーにいくつかのバンドルを送信する場合ですが、あなたは自分のサーバーを指定できるようになり、誰かがあなたのWebサイトを表示しようとしているのと同じマシンでNetflixを実行していないことを期待しています。。

ドリュー：私たちがサイトをデザインする方法については本当に良い点です。従来のベストプラクティスは、あらゆる種類のブラウザー、あらゆる種類の接続速度、あらゆる種類の画面サイズに対応することです。ユーザーが何を期待しているのかわからない。そして、あなたが言ったように、あなたは人々が「ああ、私たちはすべてのユーザーが仕事で発行されたデスクトップマシンを使用していることを知っています、彼らはこのブラウザを実行しています、それは最新バージョンです、彼らはLANに配線されています」と言うシナリオがありますしかし、その後、物事が起こります。 Webアプリを使用することの大きな利点の1つは、従業員を突然自宅に分散させて作業を継続できることですが、それはエンジニアリングの品質が回転している人のようなものである場合にのみ当てはまります。 IE11が搭載されている可能性のあるホームマシンなど、作業の品質がそこにあるかどうかに関係なく、実際にはWebが真にアクセス可能なメディアであるという可能性を満たしていることを意味します。

ドリュー：あなたが言うように、ブラウザにますます多くのものをシフトするこの傾向があります、そしてもちろん、ブラウザが遅い場合、それは遅いことが起こるところです。「これは良いトレンドですか？これを行うべきですか？」私が特に考えているサイトが1つあり、ほぼ100％サーバーでレンダリングされていることに気づきました。 JavaScriptはほとんどなく、非常に高速です。行くたびに「ああ、これは速い、誰が書いたの？」と思います。そして、「そうそう、それは私だった」と気づきます。

ハリー：それはあなたがローカルホストにいるからです、それが速く感じるのも不思議ではありません。それはあなたの開発サイトです。

Drew：それでは、私の日常業務では、サーバーがボトルネックになっているため、シングルページアプリケーションを構築し、サーバーからデータをシフトしています。ブラウザを使用する方がパフォーマンスが高いと言えますか？または、サーバー上にいるパフォーマンスが高いですか？ケースバイケースで測定して取得するだけの場合ですか？

ハリー：あなたは自分の文脈を非常に、非常に、非常に意識する必要があると思います。そして…本当にエラーは…人々が「ああ、私のブログは誰かのブラウザでレンダリングされるに値する」と考えるナルシシズムだと思います。バウンス率が89％の私のブログでは、ブラウザで独自のランタイムが必要です。後続のナビゲーションを高速にする必要があるため、データの差分を取得したいだけです。」とにかく、誰もあなたの次の記事をクリックすることはありません。ですから、あなたは自分の文脈をよく知っている必要があります。

ハリー：そして、私は知っています…ジェレミー・キースがこれを聞いていると、彼はおそらく私に打撃を与えるでしょうが、ウェブサイトとウェブアプリの間に違いがあり、その定義は非常に、非常に暗い。ただし、読み取りと書き込みのアプリケーションが多い場合は、データの入力やデータの操作などを行う必要があります。基本的に、私のサイトはWebアプリではなく、Webサイトであり、読み取り専用であり、Webサイトキャンプにしっかりと配置します。私の会計ソフトウェアのようなものはWebアプリであり、Webアプリであり、20分、1時間、何でもそこにいることがわかっているので、起動時間のコストが少しかかる準備ができています。したがって、少しコンテキストが必要です。また、ナルシシズムは少し厳しいかもしれませんが、実際の「この新聞をクライアント側のアプリケーションにする必要がありますか？」が必要です。いいえ、しません。いいえ、しません。人々は広告ブロッカーをつけています、人々はとにかく通勤新聞サイトが好きではありません。彼らはおそらくその記事を読んだり、Facebookでそれについて怒鳴ったりすることすらしないでしょう。クライアントレンダリングアプリケーションとしてそのようなものを構築しないでください。それは適切ではありません。

ハリー：それで、クライアントにもっと移動することが役立つポイントは確かにあると思います。それは、チャーンに対する感度が低くなっているときです。たとえば、どのcomタイプでも、あるサイトの監査をしばらく行っています…それはE-Comサイトだと思いますが、クライアントでは100％です。 JavaScriptを無効にしても何も表示されず、空のdiv id =“ app”だけが表示されます。 E-Comは…あなたはどんな問題にも非常に敏感です。あなたのチェックアウトフローは微妙に間違っています、私はどこか別の場所にいます。遅すぎる、私はどこか別の場所にいる。しばらくの間、誰かがそのアプリに積極的に参加するという状況はありません。

ハリー： Photoshop。 Photoshopを開いて、スプラッシュ画面が45秒かかることを知ってとてもうれしく思います。そこにいるのは、基本的に45秒は45分の価値があるからです。そして、定義するのが非常に難しいので、「ユーザーがいつまでそこにいると思いますか」とは言えないので、クライアントに「これをしないでください」と説得するのに本当に苦労しています。そして、バウンス率の89％が2番目のページの表示に最適化されていない場合は、次のようにプロキシできます。最初にそのバウンス率を下げます。私は間違いなく分裂があると思いますが、私が言うことは、ほとんどの人がその線の間違った側に落ちるということです。ほとんどの人は、そこにあるべきではないものをクライアントに入れます。たとえば、CNNは、JavaScriptアプリケーションが完全に起動されるまで、CNNWebサイトの単一の見出しを読むことはできません。サーバーがレンダリングするのはヘッダーとフッターだけで、これは人々が気にしない唯一のものです。

ハリー：それはただのように感じます…どうやってその時点に到達したのかわかりません。それがより良い選択肢になることは決してありません。事実上役に立たないページを配信すると、「かっこいい、Webアプリだったものを取得しますが、ブラウザーで実行してから、見出しを要求します。、それからあなたは始めることができます…ああ、あなたは去りました。」それは本当に、本当に私を苛立たせます。

ハリー：それは誰のせいでもありません。この種のJavaScriptエコシステムの初期段階であり、その周りの誇大宣伝であり、また、これは非常に厳しいように聞こえますが…基本的には多くの単純な実装です。確かに、FacebookはReactを発明しました、そして何でも、それは彼らのために働きます。 10人のうち9回は、Facebookの規模で働いていません。100回のうち、95回は、おそらく最も賢いFacebookエンジニアではありません。それは本当に、本当に残酷で、言うのは恐ろしいことですが、得ることができるのは…これらはデフォルトで高速です。それらを正しくするためには、これらのものの非常にエレガントな実装が必要です。

ハリー：私は昔の人とこの話し合いをしていました…彼は私が10年前にスカイにいたチームのリードエンジニアでした。私は先日彼とこれについて話していました、そして彼はクライアントレンダリングされたアプリを速くするために非常に一生懸命働かなければなりませんでしたが、サーバーレンダリングされたアプリを速くするためにあなたは何もする必要はありません。あなたはそれを再び遅くする必要はありません。そして、バラ色のメガネ、素朴さ、マーケティングがたくさんあるように感じます…私はとても暗いように聞こえます、私がここで本当に人々を失い始める前に、私たちは先に進む必要があります。

Drew：業界として、ユーザーエクスペリエンスよりも開発者エクスペリエンスに重点を置く傾向があると思いますか？

ハリー：全体としてではありませんが、あなたが期待する場所で問題が発生すると思います。格差を見ると…これを見たかどうかはわかりませんが、あなたはそうだと思います。あなたは、どのフレームワークとHTTPアーカイブのデータとの間の格差であるパルスに非常に注目しているようです。 JavaScriptライブラリは、JavaScript調査の状態に対して実際に使用されています。JavaScript調査の状態に従うと、「ああ、開発者の75％がReactを使用しています」と表示されますが、サイトの5％未満がReactを使用しています。ですから、大まかに言って、それは問題ではないと思いますが、期待する分野では、たとえば1つのフレームワークへの強い忠誠心、たとえば開発者の経験は…おそらくユーザーよりも先に伝道されていると思います。開発者の経験を見逃してはいけないと思います。つまり、すべてにメンテナンスコストがかかります。あなたの車。「まあ、このキー、その機能をメカニックから隠すと、そのメカニックが修正するのにかなり時間がかかるので、そのようなことはしません」という決定がありました。したがって、人間工学と使いやすさのバランスをとる必要があります。それは重要だと思います。主に開発者の経験に焦点を合わせるのは私には困惑していると思います。あなたのために最適化しないでください、あなたの顧客のために最適化してください、あなたの顧客はあなたにそれが逆ではないことを支払います。

ドリュー：つまり、オンラインエコーチェンバーは、誰もが「これを使うべきだ、そうすべきだ」と言っているのを見ると、現実を正確に表していないのです。実際、それはごくわずかな割合の人々にすぎません。

ハリー：正解です。それは良いことです。安心です。エコーチェンバー…あなたがそれをそれと呼びたいのなら、おそらくその種のモノカルチャーを持つことは健康的ではありません。しかしまた、私は…そしてそれを私自身の多くの仕事、多くの開発者…のように感じています。コンサルタントとして、私は多くの異なる会社と仕事をしています。多くの人がWordPressで素晴らしい仕事をしています。そしてWordPressはウェブの24％を支えています。そして、そのような開発者がバックエンドでWordPressやPHPのようなもので作業している場合、カスタムコードは、それが何であれ、「ああ、誰もがReactを使用していると思いますが、私たちはそうではありません。」ですが、実際にはありません。誰もがReactについて話しているが、あなたはまだ流れを続けており、あなたはまだ大多数を占めている。サイレントマジョリティを見つけることは非常に心強いです。

Drew：静的サイトジェネレーターとその後完全にCDNでサイトをホストする傾向、一種のJAMstackアプローチ、ソフトウェアタイプのサイトではなく、そのような種類のパブリッシングタイプのサイトについて話しているとき、それは本当に健全な傾向だと思います、あなたは思いますか？

ハリー：絶対に大好きです。 SSGを「フラップファイル」と呼んでいたことを覚えていますか？

ドリュー：うん。

ハリー：それで、JekyllがフラップファイルのWebサイトと呼ばれていたときに、JekyllでCSSWizardryを構築しました。しかし今、私たちは発電機にサービスを提供しています。 There's no disadvantage to it really, you pay maybe a slightly larger up front compute cost of pre-compiling the site but then your compute cost is… well, Cloudflare fronts it, right? It's on a CDN so your application servers are largely shielded from that.

Harry: Anything interactive that does need doing can be done on the client or, if you want to get fancy, what one really nice approach, if you are feeling ambitious, is use Edge Side Includes so you can keep your shopping cart server rendered, but at the edge. You can do stuff like that. Tremendous performance benefits there. Not appropriate for a huge swathe of sites, but, like you say, if we're thinking publishing… an E-Com site it wouldn't work, you need realtime stock levels, you need… search that doesn't just… I don't know you just need far more functionality. But yeah, I think the Smashing site, great example, my site is an example, much smaller than Smashing but yeah, SSG, flap filers, I'm really fond of it.

Drew: Could it work going deeper into the JAMstack approach of shifting everything into the client and building an E-Commerce site? I think the Smashing E-Commerce site is essentially using JavaScript in the client and server APIs to do the actual functionality as service functions or what have you.

Harry: Yeah. I've got to admit, I haven't done any stuff with serverless. But yeah, that hybrid approach works. Perhaps my E-Commerce example was a bit clunky because you could get a hybrid between statically rendering a lot of the stuff, because most things on an E-Com site don't really change. You filter what you can do on the client. Search, a little more difficult, stock levels does need to go back to an API somewhere, but yeah you could do a hybrid for a definite, for an E-Com site.

Drew: Okay, so then it's just down to monitoring all those performance metrics again, really caring about the network, about latency, about all these sorts of things, because you're then leaning on the network a lot more to fetch all those individual bits of data. It hosts a new set of problems.

Harry: Yeah, I mean you kind of… I wouldn't say “Robbing Peter to pay Paul” but you are going to have to keep an eye on other things elsewhere. I've not got fully to the bottom of it, before anyone tweets it at us, but a client recently moved to an E-Commerce client. I worked with them two years ago and that site was already pretty fast. It was built on… I can't remember which E-Com platform, it was .net, hosted on IIS, server rendered, obviously, and it was really fast because of that. It was great and we just wanted to maintain, maybe find a couple of hundred milliseconds here and there, but really good. Half way through last year, they moved to client side React for key pages. PP… product details page, product listing page, and stuff just got marketable slower lower, much slower. To the point they got back in touch needing help again.

Harry: And one of the interesting things I spotted when they were putting a case for “We need to actually revert this”. I was thinking about all the…what's slower, obviously it's slower, how could doing more work ever be faster, blah blah blah. One of their own bullet points in the audit was: based on projections, their yearly hosting costs have gone up by a factor of 10 times. Because all of a sudden they've gone from having one application server and a database to having loads of different gateways, loads of different APIs, loads of different microservers they're calling on. It increased the surface area of their application massively. And the basic reason for this, I'll tell you exactly why this happened. The developer, it was a very small team, the developer who decided “I'm going to use React because it seems like fun” didn't do any business analysis. It was never expected of them to actually put forward a case of how much is it going to cost the dude, how much is it going to return, what's the maintenance cost of this?

Harry: And that's a thing I come up against really frequently in my work and it's never the developer's fault. It's usually because the business keeps financials away from the engineering team. If your engineers don't know the cost or value of their work then they're not informed to make those decisions so this guy was never to know that that was going to be the outcome. But yeah, interestingly, moving to a more microservice-y approach… And this is an outlier, and I'm not going to say that that 10 times figure is typical, it definitely seems atypical, but it's true that there is at least one incident I'm aware of when moving to this approach, because they just had to use more providers. It 10x'ed their… there's your 10 times engineer, increased hosting by 10 times.

Drew: I mean, it's an important point, isn't it? Before starting out down any particular road with architectural changes and things about doing your research and asking the right questions. If you were going to embark on some big changes, say you've got a really old website and you're going to structure it and you want it to be really fast and you're making all your technology choices, I mean it pays, doesn't it, to talk to different people in the business to find out what they want to be doing. What sort of questions should you be asking other people in the business as a web developer or as a performance engineer? Who should you be talking to you and what should you be asking them?

Harry: I've got a really annoying answer to the “Who should you be talking to?” And the answer is everyone should be available to you. And it will depend on the kind of business, but you should be able to speak to marketing “Hey, look, we're using this AB testing tool. How much does that cost as a year and how much do you think it nets as a year?” And that developer should feel comfortable. I'm not saying developers need to change their attitude, what I mean is the company should make the developers able to ask those kind of questions. How much does Optimizely cost as a year? Right, well that seems like a lot, does it make that much in return? Okay, whatever we can make a decision based on that. That's who you should be talking to and then questions you should ask, it should be things like…

Harry: The amount of companies I work will, they won't give their own developers to Google Analytics. How are you meant to build a website if you don't know who you're building it for? So the question should be… I work a lot with E-Com clients so every developer should things like “What is our average order value? What is our conversion rate? What is our revenue, how much do we make?” These things mean that you can at least understand that “Oh, people spend a lot of money on this website and I'm responsible for a big chunk of that and I need to take that responsibility.”

Harry: Beyond that, other things are hard to put into context, so for me, one of things that I, as a consultant, so this is very different to an engineer in the business, I need to know how sensitive you are to performance. So if a client gives me the average order value, monthly traffic, and their conversion rate, I can work out how much 100 milliseconds, 500 a second will save them a year, or return them, just based on those three numbers I can work out roughly “Well a second's worth 1.8 mil”. It's a lot harder for someone in the business to get all the back information because as a performance engineer it's second nature to me. But if you can work that kind of stuff out, it unlocks a load of doors. Okay, well if a second's work this much to us, I need to make sure that I never lose a second and if I can, gain a second back. And that will inform a lot of things going forward. A lot of these developers are kept quite siloed. “Oh well, you don't need to know about business stuff, just shut up and type”.

Drew: I've heard you say, it is quite a nice soundbite, that nobody wants a faster website.

Harry: Yeah.

Drew: What do you mean by that?

Harry: Well it kind of comes back to, I think I've mentioned it already in the podcast, that if my clients truly wanted the world's fastest website, they would allow me to go in and delete all their JavaScript, all their CSS, all their images. Give that customer a Times New Roman stack.

Harry: But fast for fast sake is… not chasing the wrong thing but you need to know what fast means to you, because, I see it all the time with clients. There's a point at which you can stop. You might find that your customer's only so sensitive to web perf that it might mean that getting a First Contentful Paint from four seconds to two seconds might give you a 10% increase in revenue, but getting from that two to a one, might only give you a 1% increase. It's still twice as fast, but you get minimal gains. So what I need to do with my clients is work out “How sensitive are you? When can we take our foot off the gas?” And also, like I said, towards the top of the show… You need to have a product that people want to buy.

Harry: If people don't want to buy your product, it doesn't matter how quickly you show them it, it'll just disgust them faster, I guess. Is your checkout flow really, really, really seamless on mobile, for example. So there's a number of factors. For me, and my clients, it'll be working out a sweet spot, to also working out “If getting from here to here is going to make you 1.8 mil a year, I can find you that second for a fraction of that cost.” If you want me to get you an additional second on top of that, it's going to get a lot harder. So my cost to you will probably go up, and that won't be an extra 1.8, because it's not lineal, you don't get 1.8 mil for every one second.

Harry: It will tail off at some point. And clients will get to a point where… they'll still be making gains but it might be a case of your engineering effort doubles, meaning your returns halve, you can still be in the green, hopefully it doesn't get more expensive and you're losing money on performance, but there's a point where you need to slow down. And that's usually things that I help clients find out because otherwise they will just keep chasing speed, speed, speed and get a bit blinkered.

Drew: Yeah, it is sort of diminishing returns, isn't it?

Harry: That's what I was look for-

ドリュー：うん。

Harry: … diminishing returns, that's exactly it. Yeah, exactly.

Drew: And in terms of knowing where to focus your effort… Say you've got the bulk of your users, 80% of your users are getting a response within two, three seconds, and then you've got 20% who may be in the long-tail that might end up with responses five, ten seconds. Is it better to focus on that 80% where the work's really hard, or is it better to focus on the 20% that's super slow, where the work might be easier, but it's only 20%. How do you balance those sorts of things?

Harry: Drew, can you write all podcast questions for everyone else? これすごくいいね。 Well, a bit of a shout out to Tim Kadlec, he's done great talks on this very topic and he calls it “The Long-Tail of Web Performance” so anyone listening who wants to look at that, Tim's done a lot of good firsthand work there. The 80, 20, let's just take those as good example figures, by the time you're dealing with the 80th percentile, you're definitely in the edge cases. All your crooks and web file data is based around 75th percentile. I think there's a lot of value investing in that top 20th percentile, the worst 20%. Several reasons for this.

Harry: First thing I'm going to start with is one of the most beautiful, succinct soundbites I've ever heard. And the guy who told me it, I can guarantee, did not mean it to be this impactful. I was 15 years old and I was studying product design, GCSE. Finally, a project, it was a bar stool so it was a good sign of things to come. And we were talking about how you design furniture. And my teacher basically said… I don't know if I should… I'm going to say his name, Mr. Brocklesby.

ハリー：彼は尊敬の念を示しましたが、彼は若者の一人でした。私たちは皆、彼が本当に好きでした。しかし、彼はあらゆる面で巨大でした。身長は6フィートをはるかに超えていますが、ただの大きな若者です。大きい、大きい、大きい、大きい人。そして彼は私たちに「もしあなたが出入り口をデザインするなら、あなたはそれを普通の人のためにデザインしますか？」と言いました。そして、15歳の頭脳は「ええ、みんながおよそ5'9なら、ええ」と言っています。彼は「まあ、すぐに、ハリーはそのドアを使うことができません」のようでした。あなたは平均的な人のためにデザインするのではなく、ほとんどの人に役立つようにしたいので、四肢のためにデザインします。あなたが普通の人のために椅子をデザインしたなら、Brocklesby氏はそれに合うつもりはありませんでした。それで彼は私に本当に、本当に年齢の、あなたの四肢のデザインを教えてくれました。

ハリー：そして、それがWebパフォーマンスで本当に興味深いのは、はしごを想像して、ボットがはしごを手に取った場合です。その後私。はしごを想像してみてください。下の段ではしごを持ち上げます。そして、それはあなたの最悪の経験です。はしごの一番下の段を選んで持ち上げます。はしご全体が付属しており、潮の満ち引きがすべてのボートを浮かび上がらせます。比喩が機能しない理由は、はしごを一番上の段で持ち上げると、すべてが持ち上げられ、はしごであるためです。そして、私がそれをロープのはしごに変えても、比喩は機能しません。なぜなら、ロープのはしごを持ち上げると、何も起こらないからです…私のポイントは、90パーセンタイルの経験を向上させることができれば、あなたの10パーセンタイルのためにそれを上げてくださいね？

ハリー：これが私がクライアントに言う理由です。クライアントは「ほとんどのユーザーはiPhoneで4Gを使用しています」などと言ってくれるので、大丈夫です。Androidで3Gのテストを開始します。いいえ、ほとんどのユーザーはiPhoneです。」わかりました…つまり、平均的なユーザーの方がエクスペリエンスが向上しますが、50パーセンタイルに達していないユーザーはさらに取り残されます。したがって、期待値をかなり低く設定して、自分の基準をかなり高く設定します。

ハリー：申し訳ありませんが、短い質問に非常に長い回答をするという非常に悪い習慣があります。しかし、それは素晴らしい質問でした。まとめると、100％間違いなく、ロングテールを見たい、それを見たいということに同意します。すべての経験を取り入れれば、80パーセンタイルになります。サイトと中央値を見て、中央値を改善します。これは、すでにかなり満足している人々にとって、中央値をさらに改善したことを意味します。事実上無視されている人々の50％は正しいアプローチではありません。そして、ええ、それはいつもブロックルズビー氏に戻ってきて、「ハリーはドアを使うことができないので、普通の人のためにデザインしないでください」と言っています。ああ、聞いている人にとって、私は193センチなので、かなりひどいです、それはそれが何であるかです。

ドリュー：そしてそれらすべての腕と脚。

ハリー：うん。これもまた良いものです。私のガールフレンドは最近iOSのユーザー補助設定を発見しました…だから、誰もが自分の電話を黙秘権を持っていますよね？実際に鳴る電話を実際に持っている人は誰もいません。誰もがそれを黙っています。彼女は、「メッセージを受け取ったときにフラッシュが点滅するように設定できます。また、スマートフォンの背面を2回タップすると、スクリーンショットが表示されます。」これらはユーザー補助設定であり、95パーセンタイル用に設計されています。それでも彼女は「ああ、これは本当に便利だ」と言っています。

ハリー： OXOグッドグリップと同じです。 OXO Good Grips、台所用品。私は台所にそれらをたくさん持っています。創業者の妻が関節炎を患っており、彼がより快適な道具を作りたかったので、それらは設計されています。彼は99パーセンタイル用に設計されており、ほとんどの人は関節炎を患っていません。しかし、99パーセンタイル用に設計することで、うっかりして、他のすべての人は「なんてことだ、なぜすべてのジャガイモの皮むき器がこれほど快適になれないのか」のようになります。そして、私はそれが本当に、本当に…私がこの種のシナリオで動かしたい感じの良いまたは逸話が好きだと感じます。しかし、ええ、あなたがそれらのために最適化するならば…まあ、上昇する潮はすべてのボートを浮かびます、そしてそれ故にそれは人々の最後尾を最適化します、そしてあなたはそれ以上の多くのさらに幸せな顧客を捕らえるでしょう。

ドリュー： OXOグッドグリップの手動泡立て器はありますか？

ハリー：私はしません。私はしません、それは良いですか？

ドリュー：調べて。とても良い。

ハリー：先週、指先を外したOXOGoodGripsマンドリンスライサーを持っています。

ドリュー：ええ、私はそれらの1つに近づくことはありません。

ハリー：ええ、それは私自身の愚かな過ちです。

ドリュー：そのロングテールのケータリングに関する私自身の経験からの別の例は、私が現在取り組んでいるプロジェクトでは、そのロングテールが最後にあり、パフォーマンスが最も遅い人々がいるということです。しかし、それらの顧客が誰であるかを見ると、彼らはビジネスにとって最も価値のある顧客です-

ハリー：わかりました。

ドリュー： …彼らは最も多くのデータを持っている最大の組織だからです。

ハリー：そうですね。

Drew：ページに表示するデータが非常に多く、そのユースケースを支援するためにそれらのページを少しリファクタリングする必要があるため、ボトルネックになっています。つまり、彼らは最も遅い体験をしていて、それに関して言えば、彼らは無料のユーザーであり、少量のデータで、すべてうまく機能し、高速です。

ハリー：それは魅力的な次元ですね。実際、私は似たようなものを持っていました…あなたが今説明したようなビジネスへの影響はどこにもありませんでしたが、数年前にクライアントと仕事をしました、そして彼らのサイトが遅かったので彼らのCEOが連絡を取りました。のように、遅い、遅い、遅い。本当にいい人でもあります、彼は地球の人に本当にいい人です、しかし彼は適切な金持ちのように指導されています。そして彼は最新のiPhoneを持っている、彼はそれを買う余裕がある。彼は数百万長者であり、出身地であるオーストラリアと現在拠点を置いているエストニアの間を飛行することに多くの時間を費やしています。

ハリー：そして彼はファーストクラスで飛んでいます、もちろん彼はそうです。しかし、それは彼の素敵で光沢のあるiPhone 12 Pro Maxでの彼の時間のほとんどが、飛行機のWiFiを介していることを意味し、それはひどいことです。そして、彼がサイトを所有し、それを頻繁に使用するのは、この本当に素晴らしい並置でした。それは彼が使用するサイトです。そして彼はそれを推し進めていました…つまり、彼らの最も裕福な顧客は彼らのCEOでした。そして、彼はこの奇妙な特権的な立場にあり、ジョー・パブリックよりも悪いつながりを持っています。なぜなら、彼はシンガポールのどこかで、シャンパンを首に流し込んでいるクォンタスのフライトで、苦労しているからです。そして、それは本当に魅力的な洞察でした…そうそう、95パーセンタイルを持っているので、基本的にどちらの方向にも進むことができます。

ドリュー：ええ、片手にシャンパングラスを片手にサイトを使用するための最適化を始めたとき、「たぶん私たちは少し道に迷い始めている」と思います。

ハリー：そうだね。

ドリュー：パフォーマンスの測定について少し話しましたが、私自身のパフォーマンス作業の経験では、すべてを測定することが非常に重要です。gAは問題がどこにあるかを特定できるので、Bは実際に何かに取り組み始めたときに、あなたは違いを生み出していて、どれだけの違いを生み出しているのか。サイトのパフォーマンスをどのように測定する必要がありますか？どのようなツールを使用でき、どこから始めればよいですか？

ハリー：ああ、もう一つの素晴らしい質問です。したがって、サイトの速度を修正するための時間、リソース、傾向に応じて、さまざまな答えがあります。だから私がクライアントでやろうとしていることは…特定の既製の測定基準は本当に良いです。ロード時間、もう気にしないでください。非常に、非常に、非常に…つまり、ロード時間が120秒であれば、非常に高速なWebサイトはないと思いますが、あいまいすぎて、実際には顧客向けではありません。バイタルはユーザーエクスペリエンスを測定するため、正しい方向への本当に良いステップだと思いますが、技術的な入力に基づいています。最大のコンテンツフルペイントは視覚的には本当に素晴らしいものですが、そこにある技術的なものはクリティカルパスのブロックを解除し、ヒーロー画像がすぐに到着することを確認し、Webフォント戦略が適切であることを確認します。これらの指標には技術的な底流があります。それらは棚から本当に良いです。

ハリー：ただし、クライアントに時間があれば、通常は時間です。データをキャプチャしたいが、実際にデータをキャプチャするには時間が必要だからです。ですから、私がクライアントと一緒にやろうとしていることは、「ほら、私は満員であるため、次の3か月間は一緒に仕事をすることができません。つまり、私たちができることは、Speedcurveの無料トライアルをすばやく設定し、いくつかのカスタムメトリックを設定することです。つまり、出版社のクライアントである新聞の場合、「記事がレンダリングされましたか？記事のリード画像はどのくらいの速さでレンダリングされましたか？」 Eコマースクライアントの場合、私は測定したいと思います。なぜなら、明らかに、レンダリングの開始などを受動的に測定しているからです。パフォーマンス監視ソフトウェアの使用を開始するとすぐに、実際のパフォーマンスメトリックを無料でキャプチャできます。つまり、最初の満足のいくペイント、最大の満足のいくペイントなどです。私が本当にキャプチャしたいのは、ビジネスとして彼らにとって重要なことです。

ハリー：それで、私たちが相関できる瞬間にE-Comクライアントと協力します…開始レンダリングが速いほど、カートに追加する確率はどのくらいですか。あなたが彼らにもっと早く製品を見せることができれば、彼らはそれを買う可能性が高くなります。そして、これは設定するのに多大な労力を要します。これは、本当に野心的なクライアントにとっては一種のストレッチゴールですが、私が言うように、あなたが自分の最大のものを実際に測定したくないので、あなたが本当に測定したいものは何でもContentful Paintは、収益を測定したいのですが、Large Contentful Paintの影響を受けましたか？したがって、最終的な目標であるストレッチゴールは、そのビジネスのKPIと見なされるものになります。新聞では、誰かが記事をどこまでスクロールしたのでしょうか。そして、それは最初の入力遅延と何らかの形で相関していますか？ CLSが低ければ、人々はより多くの記事を読みましたか？しかし、カスタムのカスタムメトリックを開始する前に、正直に言って、Webバイタルは開始するのに非常に適した場所であり、非常によく正規化されていると思います。 …になります言葉が何なのかわかりません。最小公分母だと思います。業界の誰もがこのレベルの競技場でのパフォーマンスについて話し合うことができます。

ハリー：私が抱えている問題の1つは、バイタルチームとのミーティングを実際に設定する必要があることです。また、Lighthouseは素晴らしいと思いますが、CLSはWebバイタルの33％です。 LCP、FID、CLSがあります。 CLSはバイタルの33％です。バイタルは、通常、マーケティングチーム、分析部門の前に置かれるものです。これは、検索コンソールにポップアップ表示されるため、検索結果ページのコンテキストで言及されますが、バイタルが関係している場合は、33％、3分の1の重みがあります。バイタルの数はCLSであり、Lighthouseスコアのわずか5％です。つまり、Lighthouseを中心に構築する開発者が得られるのは、ツールに統合できるため、ラボの指標です。バイタルはフィールドデータであり、ラム酒です。

ハリー：つまり、マーケティングチームが「CLSは本当に悪い」と言って、開発者が「DevToolsが私に与えているLighthouseスコアの5％だ、スコアの5％だ」と考えているという、この大規模な切断があります。そのLighthouseCLIは、CircleCIで私たちに提供してくれます」またはあなたが使用しているものは何でも、マーケティングチームにとっては彼らが気にかけているものの33％です。灯台は非常に価値があると思うので、問題は少し途切れていますが、バイタルサインではCLSがスコアの33％であるというかなり大きな違いをどのように調整するのかわかりませんが、スコアではありません。実際にはありません。Lighthouseはわずか5％です。このような議論をシームレスにする前に、まだ解決する必要があります。

ハリー：しかし、繰り返しになりますが、短い質問に対する長い答えです。バイタルは本当に良いです。 LCPは、CLSと同様に、技術的なソリューションに要約できる優れたユーザーエクスペリエンス指標です。ですから、それは本当に良い出発点だと思います。それを超えて、それはカスタムメトリックです。私がクライアントに伝えようとしているのは、サイトの速度をあまり気にせず、昨日からより多くのお金を稼ぐことだけを気にかけているということです。それが少なくなったのは、それが遅くなっていたからですか？私は彼らに神秘的な2秒のLCPを追いかけてほしくありません、私は彼らに最適なLCPを追いかけてもらいたいのです。そして、それが実際にあなたが思っているよりも遅いことが判明した場合、それなら何でも、それは問題ありません。

ドリュー：つまり、興味のあるWeb開発者にとっては、Speedcurveなどのツールに費やす予算がないため、ブラウザ内でLighthouseなどのツールを実行して、適切な測定値を取得することができます。Googleのようなものです。そのレベルに役立つアナリティクス？

ハリー：そうですし、もっと便利にすることができます。アナリティクスは、長年にわたり、基本的なパフォーマンス情報を収集してきました。そして、それはDNS時間、TCPとTLS、最初のバイトまでの時間、プロキシであるページのダウンロード時間になります…まあ、何であれ、ページのダウンロード時間とロード時間だけです。かなり不格好なメトリックです。しかし、これは良い出発点であり、通常、クライアントから開始するすべてのプロジェクトで、New RelicやSpeedcurveなどがない場合は、「分析を見てみましょう」とだけ言います。少なくともそこから状況を代理します。そして、Speedcurve、New Relic、Dynatraceなどのようなものほど優れたものになることは決してありません。カスタムメトリックを本当に、本当に、本当に簡単にアナリティクスに送信できます。聞いている人が送信できるようにしたい場合は…たとえば私のサイト。「私の記事の見出しをどれだけ早く読むことができますか？」などの指標があります。 Aboutページの画像はどの時点でレンダリングされましたか？私を雇うようにあなたに懇願する行動の呼びかけはどの時点でしたか？それはどれくらい早く画面に表示されますか？」このデータをキャプチャするのは本当に簡単で、分析に送信するのもほとんど簡単です。したがって、誰かが私のサイトのソースを表示し、本文の終了タグまでスクロールして分析スニペットを見つけたい場合は、カスタムデータをキャプチャして分析に送信するのがいかに簡単であるかがわかります。また、分析UIでは、何もする必要はありません。通常、カスタムレポートを設定し、データをマイニングして見栄えを良くする必要があります。これらは、GoogleAnalyticsの第一級市民です。したがって、カスタムアナリティクスのキャプチャを開始すると、ダッシュボードのセクション全体が専用になります。 GA自体にセットアップや手間のかかる作業はないので、それは非常に簡単です。クライアントが実際の予算に余裕がある場合、またはカスタムモニタリングの力をクライアントに示したい場合は、「そうそう、約束します。それは本当に良いでしょう、私はSpeedcurveのために24グランドを持っていることができますか？」「ほら、これは初歩的なことです。ここで可能性を見てみましょう。Speedcurveのようなものにアップグレードするように説得できるかもしれません。」

ドリュー：私は、何かがどれだけ速くあるべきか、または変更がどのような影響を与えるべきかについての私の本能が間違っている可能性があることにしばしば気づきました。私は変更を加えて、物事をより速くしていると思い、それを測定し、実際に物事を遅くしました。それは私だけがウェブパフォーマンスでゴミになっているのですか？

ハリー：まったく違います。私はこれの本当に適切な例を持っています。プリロード…プリロードのことを聞いたことがない人のための本当に簡単なイントロです。特定のアセットをWebにロードするのは本質的に非常に遅く、ここでの2つの主要な候補は、CSSとWebフォントの背景画像です。 HTMLをダウンロードし、CSSをダウンロードすると、CSSは「ああ、ホームページのこのdivにはこの背景画像が必要です」と表示します。つまり、CSSの時間のチャンク全体が間にあるため、本質的に非常に遅くなります。プリロードを使用すると、HTMLのheadタグに「まだわかりませんが、この画像が本当に、本当に、本当にすぐに必要になるでしょう」という1行を挿入できます。したがって、このダウンロードを先制的に起動するプリロードをHTMLに含めることができます。 CSSが背景画像を必要とするときまでに、それは「ああ、私たちはすでにそれを持っている、それは速い」のようなものです。そして、これはこのウェブパフォーマンスメサイアとして宣伝されています…これが問題です、そして私はあなたに約束します、私は先週ツイートしました、そして私はそれ以来二度証明されました。人々はプリロードとそれが与える約束について聞きます、そしてまたそれはLighthouseによって非常に強く押されます、理論的にはそれはあなたのサイトをより速くします。人々はプリロードのアイデアにとても結婚しているので、私がそれが機能していないことを証明できたとしても、彼らはそれを再び削除することはありません。「いいえ、でも灯台は言ったからです。」さて、これは理論が正しいものの1つです。 Webフォントを早くダウンロードするのではなく、待つ必要がある場合は、より速く表示されます。問題は、Webが実際にどのように機能するか、最初にヒットしたページ、ヒットした新しいドメインを考えると、限られた量の帯域幅があり、ブラウザがその帯域幅を正しく使用していることです。 HTMLをすばやく調べて、買い物リストを作成します。最も重要なのはCSSであり、次にこのjQueryであり、次にこれです…そして次のいくつかはこれら、これら、そしてこれらの優先度の低いものです。プリロードを使用してHTMLのロードを開始するとすぐに、ブラウザに「いいえ、いいえ、いいえ、これはもうショッピングリストではありません、相棒、これは私のものです。行ってこれらを入手する必要があります。」その有限量の帯域幅はまだ有限ですが、より多くのアセットに費やされることはないため、すべてがわずかに遅くなります。そして、私はこの1週間でこれを2回ブーイングする必要がありましたが、それでも人々は「そうですが、ダウンロードが早くなるからです」のようです。いいえ、すぐにリクエストされますが、CSSから帯域幅を盗んでいます。あなたは文字通りあなたのウェブフォントがあなたのCSSから帯域幅を盗んでいるのを見ることができます。ですから、それはあなたが数字に従わなければならない、しなければならない、それらの事柄の1つです。私は以前に大規模なクライアントでそれを行いました。これを聞いていると、このクライアントのことを聞いたことがあるでしょう。「いいえ、いいえ、ヘッドタグの順序が間違っています。これが本来あるべき姿であり、これを使用する必要があるためです。理論的にはそれが手がかりになるので注文してください…」私がクライアントに向かっていたときでさえ、私は自分がばか者のために準備していることを知っていました。ブラウザの動作方法のため、より高速である必要があります。だから私は策略をしている、この変化は…何百万もの人々に…そしてそれは遅くなった。遅くなりました。そして、そこに座って、「いいえ、でもブラウザはこのように動作します」と憤慨して主張しましたが、動作していないので役に立たないのです。そして、私たちはそれを元に戻しました、そして私は「ごめんなさい！それでも請求書を発行します！」ですから、それはあなたではありません。

ドリュー：これらの数字に従ってください。

ハリー：そうだね。「私は実際にあなたにもっと請求しなければなりません、なぜなら私はそれを元に戻すのに時間を費やしたので、私はより長くかかりました。」しかし、ええ、あなたは絶対に正しいです、それはあなたではありません、それはそれらのことの1つです...私はそれをはるかに小さな規模で何度もやりました、そこで私は「これは理論的にはうまくいくはずです」のようになります't。現実の世界で何が起こっているのかを追う必要があります。そのため、その監視は非常に重要です。

ドリュー：状況が変化し、テクノロジーが発展するにつれて、Googleは物事をより速くするのに役立つ新しいテクノロジーを展開しますが、変化に対応できる良い方法はありますか？ Webパフォーマンスに関して、スキルを最新の状態に保つために検討する必要のあるリソースはありますか？

ハリー：「グーグルメイキング」全体にすばやく対処するために…それは少し舌が出ていることは知っていますが、これに焦点を当てます。私は最初の方で、ブラウザに賭けていると思います。たとえば、AMPのようなものは、せいぜい解決策を考えた後のキャッチです。高速なサイトを構築することに代わるものはありません。AMPのようなものを使い始めた瞬間、それらの非標準的な標準を保持する必要があり、AMPチームの慈悲が彼らの考えを変えます。私はクライアントにAMP許可リストのフォントプロバイダーからフォントのライセンスを取得するために大金を費やしてもらいましたが、ある時点で、AMPは「ああ、実際にはそのフォントは提供されていません。今すぐブロックリストに追加します」と決定しました。 AMPとこのフォントプロバイダーに多額の投資をしていて、「AMPの作業をすべて元に戻すのか、それともWebフォントでこの非常に大きな数を無駄にするのか」を選択する必要がありました。ですから、私は誰にも非常に警戒するでしょう…私はGoogle Developerの専門家ですが、箝口令を知りません…私は批判的である可能性があります。 -AMPのようなすべてのソリューションに適合します。

ハリー：そして、他の誰かに一瞬ダンプするために、Cloudflareにはロケットローダーと呼ばれるものがあります。これは、AMP風の取り組みです。これは、「CDNでこれをオンにするだけで、サイトが高速化される」ように設計されています。そして実際には、そもそもサイトを適切に構築するための単なる代替品です。ですから…その側面に対処するために、可能な限り独立した状態を保ち、ブラウザがどのように機能するかを理解してください。つまり、Chromeのモノカルチャーは、Googleのラップに戻っていますが、ブラウザがどのように機能するかを知っており、いくつかの基本的なイデオロギーに固執しています。サイトを構築するときは、ページを見てください。それがFigmaでも、Sketchでも、どこにいても、デザインを見て、「それはユーザーが最初に見たいものなので、何も邪魔しません。このメイン画像を遅延ロードするのは面倒なので、なぜそうするのでしょうか？」では、「ユーザーに最初に何をしてもらいたいか」について考えてみてください。 E-Comサイトでは、おそらく同時にnavであるその製品イメージになりますが、製品のレビュー、製品のQとA、遅延読み込みがあります。それをJavaScriptの背後に押し込みます。

ハリー：あなたが読んでいるテクノロジーに関係なく、あなたに役立つ特定の基本的な働き方、つまり「顧客が優先するものを優先する」。より多くの作業を行う方が速いので、そのようなことを邪魔しないでください。しかし、人々が気づき、遅れないようにするためのより戦術的なこと…そして再び、Googleに直接戻りますが、web.devフレームワークにとらわれない、スタックにとらわれない洞察のための驚異的なリソースであることが証明されています…したがって、バイタルについて学びたい場合は、PWAについて学びたいので、web.devは本当に素晴らしいです。

ハリー：実際には、パフォーマンス中心の出版物はほとんどありません。 Calibreのメールは、隔週のパフォーマンスメールは驚異的だと思います。これは本当に良いダイジェストです。一般的なWebプラットフォームに注目してください。パフォーマンスワーキンググループがあり、GitHubの提案にたくさんの情報があります。繰り返しになりますが、Googleに戻りますが、このWebサイトとその驚異的なchromestatus.comについては誰も知りません。 Chromeが何に取り組んでいるのか、他のブラウザからのシグナルが何であるのかを正確に教えてくれるので、優先度のヒントでどのような作業が行われているのかを知りたい場合は、関連するすべてのバグトラッカーへのリンクを取得できます。 Chromeステータスには、それぞれのマイルストーンが表示されます…「これはMAT8でリリースされ、67年にリリースされました」など、非常に技術的な洞察を得るには非常に良いことです。

ハリー：しかし、私はこのことに戻り続けています。おそらく「老人がクラウドで叫ぶ」ように聞こえるかもしれませんが、基本に固執します。これまでに獲得したほぼすべてのポンドまたはドル、ユーロは、クライアントに教えてきました。「ブラウザがこれをすでに実行していることをご存知でしょう」または「これがこれ以上速くなることはあり得ないことをご存知でしょう」そしてそれは私にとって本当に正しいことのように聞こえます… 私が稼ぐお金のすべては、削除、減算についてです。あなたがあなたのサイトをより速くするために何かを追加していることに気づいたら、あなたは間違った方向にいます。

ハリー：その好例として、私は名前を付けるつもりはありません…大手の広告/検索エンジン/ブラウザ会社に名前を付けるつもりはありません。JavaScriptフレームワークに名前を付けるつもりはありませんが、現在は非常に大きく、非常に人気のあるJavaScriptフレームワークと、積極的に害を及ぼすものを削除すること、またはオプションで膨大な数のWebサイトのパフォーマンスを害するものを削除することについて話し合います。そして、彼らは「ああ、私たちはループインするつもりです…」のようなものでした。彼らはいくつかの調査を行ったので…そしてそれは「ここ、ここ、そしてここで見ることができるので、このものを削除するオプションが必要です。ここでは、このサイトの速度が低下しています。」そして、彼らの解決策は、「ああ、でもこれもやれば、それを回避できる」のように追加することでした。「いいえ、いいえ、サイトを高速化するために追加するのは間違った解決策に違いありません。確かに、より高速なサイトになるためにより多くのコードが必要な場合は、間違った方向に向かっていることがわかります。」

ハリー：最初は速かったし、追加するものすべてが遅くなるからです。そして、それをより速くするためにさらに追加するという考えは…それはより速いウェブサイトに現れるかもしれませんが、それは間違った方法です。底辺への競争です。申し訳ありませんが、私は本当に元気になっています、あなたは私がしばらくの間暴言を吐いていないと言うことができます。つまり、サイトを高速化する機能を追加していることに気付いた場合は、おそらく間違った方向に向かっていることになります。追加するよりも、削除して高速化する方がはるかに効果的です。

Drew：「CSSウィザードを高速化するために私が行ったすべてのこと」というビデオコースをまとめました。

ハリー：うん！

ドリュー：従来のオンラインビデオコースとは少し違いますね。

ハリー：そうです。正直に言うと、部分的には…怠惰とは言いたくないのですが、非常に厳格で、ゼロからヒーローに移行する必要のあるカリキュラムを設計したくありませんでした。膨大な時間であり、私が持っているかどうかはわかりませんでした。ですから、私が望んでいたのは、すぐに使える資料を用意することでした。「これがブラウザであり、これがどのように機能するか」で始まらないように、スクリーンキャストで話しかけるだけなので、少なくとも注意する必要があります。 Webパフォーマンスの基本ですが、それはハックとプロのヒント、そして実際の例です。

ハリー：そして、完全なカリキュラムを行う必要がなかったので、価格を大幅に下げることができました。ですから、ゼロからヒーローへとあなたを連れて行くのは、10時間の大きなコースではありません。あなたが適切だと思うように、それはニップインとニップアウトです。基本的には、不安定なものや…そこで実験するリスクが非常に低いものの優れた遊び場である私のサイトを見ているだけです。だから私はちょうどビデオシリーズをやりました。録音するのはとても楽しかったです。自分のサイトを解体して、「これがどのように機能するか、そしてこれがどのように使用できるか」について話しているだけです。

ドリュー：それがさまざまな問題の解決に分割されるのは本当に素晴らしいことだと思います。画像の最適化などについてもっと知りたい場合は、「そうです、私の仲間のハリーはこれについて何を言わなければならないのですか？」と考えて、画像についてのビデオに浸り、私は行きます。それはそのように本当にアクセス可能です、あなたは何時間も何時間も座っている必要はありません、あなたはただあなたが望むビットに行きそしてあなたが学ぶ必要があることを学びそしてそして出ることができます。

ハリー：もっと維持しようとしたと思います…厳格なカリキュラムを行わないことの利点は、最初に特定のビデオを見る必要がなく、イントロがなく、「周りを見回して、面白いと思うものを見る」だけです。つまり、LTPの問題に苦しんでいる人は、「ここでこのフォルダーに飛び込む必要があります」のようになります。CSSの問題に苦しんでいる場合は、そのフォルダーに飛び込むことができます。明らかに統計はありませんが、何かを逃した場合に備えて3時間のイントロをたどる必要があるという理由だけで、コースの放棄率が高いと思います。毎日これを続けてください」そして人々はただたくさんのコースを放棄するかもしれません。だから私の考えはただ飛び込んだだけでした、あなたは前の3時間を見る必要はありません、あなたはただ行ってあなたが望むものを見つけることができます。そして、フィードバックは本当に、本当に…実際、私がすることは、まだ存在していませんが、電話の直後にそれを行います。割引コードSMASHING15を使用する人は、15％オフになります。それの。

ドリュー：つまり、コース自体のパフォーマンスを最適化したのとほぼ同じです。必要な部分に直接進むことができ、すべての交渉を行う必要がないためです。

ハリー：ええ、意図的ではありませんが、私はそれを信用します。

ドリュー：それで、私はWebパフォーマンスについてすべて学んでいますが、最近、ハリーは何について学んでいますか？

ハリー：技術的なこと…そうではありません。私は「学ぶ」リストにたくさんあるので、QUIC、H3のようなものについてもう少し実用的な知識を得たいと思いますが、英国での最初のロックダウン中に電子書籍を書いたので、学びました電子書籍の作り方は、HTMLとCSSだけなので、とても楽しかったです。私はそれを回避する方法を知っているので、とても楽しかったです。私はこのコースで非常に初歩的なビデオ編集を学びましたが、それらについて私が気に入ったのは、それが概念的な作業ではないということです。明らかに、プログラミング言語を学ぶには、概念に取り組む必要がありますが、電子書籍を学ぶことは単なるワークフローであり、…これまでいじったことがないものなので、学ぶのは面白かったですが、キャリアを変える必要はありませんでした。、それはとても良かったです。

ハリー：それから、技術的ではないこと…私はたくさんの自転車に乗る、たくさんの自転車から落ちる…そして去年の3月からまったく旅行していないので、ほぼ1年になります。サイクリングとより多くのことに焦点を当てる…それを改善する。ですから、私は出力と機能的閾値パワーについて多くの研究を行ってきました。現在、トレーニングプログラムを行っているので、常に足を疲れさせていますが、サイクリングに関する生理学について多くを学んでいます。乗り続ける以外に何もするつもりがないので、理由はわかりません。本当に魅力的です。複数形の封鎖の間、私は非常に幸運だったように感じますが、私は何とか活動を続けることができました。多くの人は、オフィスへの毎日の通勤、足を伸ばす良いチャンスなどの簡単なことを見逃します。英国では、ご存知のように、サイクリングは非常に支持されているので、私はより生理学的な側面から自転車に乗ることについてもっと学ぶことでもっといじくり回してきました。変化のために何か他のもの。

ドリュー：ウェブでのパフォーマンスの最適化とサイクリングでのパフォーマンスの最適化の間にそれほど大きな違いはないのではないでしょうか。それはすべてわずかな利益ですよね？

ハリー：そうだね。そして、私が自転車で見ているグラフの量…私は自転車から電力データを取得しました。私は乗車に出て、「ああ、ここにさらに5ワットあれば、10を節約できたら」のように戻ってきます。そこにワット、私はこれ、これ、そしてこれをこれまでで最速で行うことができました」そして…それについての大規模なアノラックでした。しかし、ええ、あなたは正しいです。あなたは何を知っていますか、私はあなたがそこで本当に興味のある何かにぶつかったと思います。ちょっとこだわりがあり、数字を追いかけるのが好きな人にとっては、そういうことはいいスポーツ・娯楽だと思います。いくつかのことがあります、私はあなたがこれを知っていることを意味します、しかし、Strava、あなたはあなたのKOMを持っています。私は昨年、そのうちの19個を袋に入れました。これは、私にとっては驚異的な量です。そして、それはほとんどすべて、利用可能なデータに執着し、「私が打ち負かそうとしているこの男、彼はこの時点で700ワットを実行していました。私が1000に到達し、その後テールオフできれば」と何とか、何とか、何とかです。 …それは執着しています。オタク。でもそうですね、似たようなことだと思いませんか？ If you could learn where you afford to tweak things from or squeeze last little drops out…

Drew: And you've still got limited bandwidth in both cases. You've got limited energy and you've got limited network connection.

Harry: Exactly, you can't just magic some more bandwidth there.

Drew: If you, the listener, would like to hear more from Harry, you can find him on Twitter, where he's @csswizardty, or go to his website at csswizardry.com where you'll find some fascinating case studies of his work and find out how to hire him to help solve your performance problems. Harry's E-Book, that he mentioned, and video course we'll link up from the show notes. Thanks for joining us today, Harry, do you have any parting words?

Harry: I'm not one for soundbites and motivation quotes but I heard something really, really, really insightful recently. Everyone keeps saying “Oh well we're all in the same boat” and we're not. We're all in the same storm and some people have got better boats than others. Some people are in little dinghies, some people have got mega yachts. Oh, is that a bit dreary to end on… don't worry about Corona, you'll be dead soon anyway!

Drew: Keep hold of your oars and you'll be all right.

ハリー：うん。 I was on a call last night with some web colleagues and we were talking about this and missing each other a lot. The web is, by default, remote, that's the whole point of the web. But… missing a lot of human connection so, chatting to you for this hour and a bit now has been wonderful, it's been really nice. I don't know what my parting words really are meant to be, I should have prepared something, but I just hope everyone's well, hope everyone's making what they can out of lockdown and people are keeping busy.