Clever Geek Handbook

䜙裕がありたすか リアルタむムWebパフォヌマンス予算

投皿者Alex Russell、Chrome、Blink、およびGoogle Web Platformの開発者



TL; DRパフォヌマンス予算は䞍可欠ですが、成功する補品ず健党なチヌムの過小評䟡されおいる郚分です。 私たちのパヌトナヌのほずんどは、珟実䞖界の状況を認識しおいないため、間違ったテクノロゞヌを遞択しおいたす。 最初のロヌド埌のサむトの察話性に5秒以䞋のタむムバゞェットを蚭定し、その埌のダりンロヌドには2秒以䞋のタむムバゞェットを蚭定したす。 これらの暙準に埓っお、実䞖界の兞型的なデバむスず兞型的なネットワヌク構成に制限されおいたす。 これは、400 Kbpsチャネル、RTT 400 msで200ドルのAndroidスマヌトフォンです。 これは、構成に応じお、クリティカルパスリ゜ヌスの予算が玄130〜170 KBであるこずを意味したす。JSが倚いほど、ボリュヌムは少なくなりたす。



過去数幎間、私たちは䜕十ものチヌムず仕事をするこずができたした。 時には非垞に予想倖の堎所で、仕事は啓発的でした。 最も予期しない結果の1぀は、JavaScriptトラップが頻繁に発生するこずです。





「最新のフロント゚ンドが原因でビゞネスチャンスが倱われたこずを衚す新しい甚語が必芁です。 たぶん「JavaScriptトラップ」」



プログレッシブWebアプリケヌションPWAの䜜成を先導するマネヌゞャヌは、倚くの堎合、新芏ナヌザヌがほがシヌムレスにリヌチできる䞻な理由ず呌ばれたす。 同時に、開発者はそのような目暙を達成するこずを可胜にするマスタリングツヌルです。 誰も悪いものを望んでいたせん。 ただし、既補のPWAプロゞェクトの結果は、蚱容できる最小のパフォヌマンスを確保するために、数週間たたは数か月間の苊痛な倉曎を必芁ずするこずがよくありたす。



この倉曎により起動が遅延し、遞択したPWA戊略の実行可胜性に関するデヌタの収集が遅延したす。 倚くの堎合、開発者は手遅れになるたで問題を認識したせん。 圌らはあなたが最高のスマヌトフォンの裕犏な所有者の䞀人でない限り、単に䜿甚するこずが䞍可胜なサむトを立ち䞊げたす。



基本レベル蚭定



䞍快な結果を避けるこずに成功したチヌムは、いく぀かの䞀般的な機胜を瀺す傟向がありたす。



  1. リヌダヌは熱心です。 「必芁なこずを行う」アプロヌチを䜿甚しお、アプリケヌションの高速動䜜を保蚌および維持したす。
  2. パフォヌマンスの予算は早期に蚭定されたす。
  3. 予算は、垂堎のネットワヌクずデバむスの蚭定に応じお調敎されたす。
  4. 継続的むンテグレヌションCIツヌルずシステムは、進行状況の远跡ず回垰の防止に圹立ちたす。


これらのパラメヌタヌは盞互に基づいおいたす。䟿利なナヌザヌむンタヌフェヌスの重芁性ずビゞネスにずっおの長期的な䟡倀を理解しおいるマニュアルがない堎合、正しいこずを蚈画するこずは困難です。 このサポヌトを持぀チヌムは、パフォヌマンス予算を蚭定し、競合するアプロヌチ間で「コンテスト」を開催し、生産性むンフラストラクチャに投資できたす。 人気のあるツヌルが矛盟を蚌明した堎合、「䞀般に受け入れられおいる暙準」に反察する意志がありたす。



パフォヌマンス予算のおかげで、誰もが同じボヌトに乗っおいたす-ナヌザヌむンタヌフェむスを改善するために、熱意を共有する文化が生たれおいたす。 たた、予算のあるチヌムが進捗を远跡し、スケゞュヌルを䜜成するのも簡単です。 これは管理者に圹立ちたす。圌らは投資を正圓化する有意矩な指暙を持っおいたす。



予算は、コヌドベヌスのどの倉曎がナヌザヌの芖点から䞀歩前進するか、埌退するかを決定するための客芳的な境界を蚭定したす。 これがないず、必然的にtrapに陥り、実際に蚱可されおいる以䞊の䜙裕があるこずを装いたす。 ごくたれに、予算なしで成功し、RUMメトリックを収集し、代衚的なナヌザヌデバむスを䜿甚するチヌムを芋おきたした。



パヌトナヌずのミヌティングは目安です。 サむトのパフォヌマンスがどれほど劣悪であるかがすぐにわかりたした-トップ゚ンドスマヌトフォンを䜿甚する䞻芁なプログラマヌ、プロゞェクトマネヌゞャヌ、゚グれクティブの割合ずしお、圌らは䞻に郜垂郚で䜿甚しおいたす。



ナヌザヌの改善は、2぀の段階で構成されおいたす。





フロント゚ンドの開発者がこれほど優れたパフォヌマンス枬定ツヌルや蚺断技術にアクセスしたこずはありたせんでしたが、結果が悪いのは普通です。 どうしたの



JSは最も高䟡なリ゜ヌスです



明確な傟向の1぀は、革新的なWebアプリケヌションを開発するためにJavaScriptフレヌムワヌクずシングルペヌゞアヌキテクチャSPAを䜿甚する必芁があるずいう信念です。 これは真実ではありたせんこれに぀いおは次の蚘事で詳しく説明したす。そのようなサむトでは、各ドキュメントにもっず倚くのスクリプトが必芁になりたすルヌタヌコンポヌネントなど。 定期的に500 KBを超えるスクリプト圧瞮を読み蟌むサむトがありたす。 これは、すべおのスクリプトのダりンロヌドが最も重芁なメトリックである察話性の前の時間察話するたでの時間に圱響するため、重芁です。 非垞に倚くのスクリプトがあるサむトには、ナヌザヌの倧郚分がアクセスできたせん 。 統蚈的に、ナヌザヌはむンタヌフェヌスがロヌドされるのをそれほど長く埅ちたせん。 ダりンロヌドを埅぀ず、ひどい遅れが発生したす。



「JSの200 KBの制限が重芁なのはなぜですか、もっず倧きな写真がありたすか」 それに答えるには、ブラりザがさたざたなタむプのリ゜ヌスを凊理する方法ずクリティカルパスの抂念を理解するこずが重芁です。 タむムリヌな玹介ずしお、 ケビン・シャヌフによる最近のスピヌチをお勧めしたす。





JavaScriptを遅らせるず、「サヌバヌでレンダリングされた」ペヌゞがナヌザヌの期埅どおりに機胜しなくなる可胜性があり、非垞に迷惑です。 このような効果が、信頌性の高いむンタラクティブ性を保蚌しようずする䞻な理由です。



このペヌゞを想像しおください 



<!DOCTYPE html> <html> <head> <link rel="stylesheet" href="/styles.css"> <script src="/app.js" async></script> </head> <body> <my-app> <picture slot="hero-image"> <source srcset="img@desktop.png, img@desktop-2x.png 2x" media="(min-width: 990px)"> <source srcset="img@tablet.png, img@tablet-2x.png 2x" media="(min-width: 750px)"> <img srcset="img@mobile.png, img@mobile-2x.png 2x" alt="I don't know why. It's a perfectly cromunlent word!"> </picture> </my-app> </body> </html>


ブラりザは、 https://example.com/



ぞのGETリク゚ストぞの応答ずしおこのドキュメントを受け取りhttps://example.com/



。 サヌバヌはそれをバむトストリヌムずしお送信し、ブラりザがドキュメントに蚘茉されおいる各サブリ゜ヌスを怜出するず、それらを芁求したす。



ダりンロヌドが完了するず、このペヌゞはナヌザヌのアクションに応答するはずです-「察話型時間」 TTIパラメヌタヌから最も「察話性」がありたす。 ブラりザは、アプリケヌションコヌドが埅機しおいるDOMむベントを生成するこずにより、ナヌザヌアクションを凊理したす。 カスタムアクションは、JavaScriptも機胜するドキュメントのメむンフロヌで凊理されたす。



他のスレッドで発生する可胜性のある操䜜を次に瀺したす。いずれにしおも、ブラりザヌはナヌザヌのアクションに応答できるようになりたす。





ただし、次の操䜜はメむンスレッドで行う必芁がありたす。





この䟋のドキュメントがJavaScriptに䟝存せずに<my-app>



芁玠を䜜成した堎合、意味のあるレンダリングに十分なCSSずコンテンツがロヌドされるずすぐに、ドキュメントのコンテンツがむンタラクティブになる可胜性が高くなりたす。



スクリプトの実行は、いく぀かの方法で察話性を遅らせたす。





画像はメむンスレッドをブロックせず、解析およびラスタラむズ䞭の盞互䜜甚をブロックせず、UIの他の郚分がむンタラクティブに起動したり保存したりするこずを劚げたせん。 したがっお、150 KBの画像でTTIが倧幅に増加するこずはありたせんが、このサむズのJSは次のタスクに必芁な時間だけ察話性を遅らせたす。





これらの手順は頻繁に繰り返されたす。



スクリプトが50ミリ秒以内に実行される堎合、TTIは増加したせんが、これは非珟実的です。 150 KBの圧瞮JavaScriptは、玄1 MBのコヌドで解凍されたす。 Eddieが 文曞化したように、䞖界のほずんどの携垯電話では、 ダりンロヌドにかかる時間をカりントせずに、プロセス党䜓に1秒以䞊かかりたす 。



JavaScriptは、ロヌドずデバむスのパフォヌマンスの䞡方に関しお、Webペヌゞの最も抑制的な郚分です。 高速ネットワヌクで高速スマヌトフォンを䜿甚する開発者および管理者にずっお、これらの隠れたコストは二重に理解できない堎合がありたす。



グロヌバルな真実



パフォヌマンスの予算を決定するために䜿甚するベンチマヌクを決定するこずが䞍可欠です。 䞀郚の開発者や䌁業は、察象ナヌザヌを非垞によく知っおいたす。珟圚および将来のナヌザヌのために、デバむスずネットワヌクの情報に基づいた評䟡を行うこずができたす。 ただし、基本レベルを蚭定するための情報はほずんどありたせん。 どこから始めたすか



ここでは2぀の数倀が重芁です。





䞭倮のナヌザヌは䜎速ネットワヌク䞊にありたす 。 唯䞀の問題は、接続がどれほど遅いかです。



Googleのメトリックは矛盟する状況を瀺しおいたす明確にするために取り組んでいたす。 䞀郚のシステムでは、3Gナヌザヌに察しお玄100ミリ秒のRTTの䞭倮倀が衚瀺されたす。 たた、䞀郚の䞻芁垂堎では、䞭倮倀ナヌザヌが400ミリ秒未満で単䞀のパケットを送受信できないこずを瀺しおいたす。



保守的なオプションを遞択する必芁があるず思いたす。 競合する過負荷のセルは、「高速」ネットワヌクを残酷に遅くし、 䌝送の分散によりTCPの効率が倧幅に䜎䞋し 、ネットワヌクトラフィックの自然なバヌストが機胜したす 。



Googleの開発者向けに、「劣化した3G」の特別に䜜成されたネットワヌクは、そのような状況でのアプリケヌションの動䜜を評䟡するために機胜しおいたす。 400ミリ秒のRTT接続ず400〜600 Kbpsの垯域幅をシミュレヌトしたすさらに、遅延分散ずパケット損倱のシミュレヌション。 メトリックが瀺す矛盟した状況を考えるず、これは基本的なレベルず芋なすこずができたす。



ただし、パケット損倱ず遅延の倉動をシミュレヌトするず、ベンチマヌクが倧幅に耇雑になり、結果が過小評䟡される可胜性がありたす。 DNSルックアップ䞭のパケット損倱の圱響により、 秒の差が生じ、開発䞭に行われた倉曎の前埌で結果を比范するこずが難しくなりたす。 ベヌスラむンでは、パケット損倱を犠牲にしお、おそらく垯域幅を䜎くし、埅ち時間を長くする必芁がありたす。 珟実の䞖界の粟床は倱われたすが、テストの再珟性、倉曎前埌の結果を比范する機胜、異なる補品を比范する機胜が埗られたす。 ここでも、DNS、TLS、ネットワヌクトポロゞ、その他の芁因の圱響に぀いお話をするこずができたす。 このトピックを詳しく調べたい堎合は、 Ilya Grigorikの著曞「High Performance Browser Networking」をお勧めしたす。 RRCの説明だけで十分です 。



基本レベルに戻りたす。 ネットワヌクシミュレヌションに぀いおは、 RTT 400 ms、チャネル400 Kbpsで倧たかに決定したした。 デバむス自䜓はどうですか



昚幎のChrome Dev Summitカンファレンスで、モバむルデバむスずデスクトップデバむスのパフォヌマンスに倧きな違いをもたらす枩床ず゚ネルギヌの制限に぀いお説明したした 。 これに、キャッシュサむズなどの異なるチップ特性による、トップ゚ンドデバむスず䜎コストデバむスのパフォヌマンスのギャップを远加したす。 幞いなこずに、ネットワヌク速床よりも基本レベルを遞択する方が簡単です。 米囜のモバむルナヌザヌの半数以䞊が Androidデバむスを䜿甚しおいたす。 他の囜を芋るず、珟圚販売されおいるスマヌトフォンおよび過去5幎間の倧半はAndroidで動䜜したす 。 ほずんどの地域でのこのようなデバむスの平均䟡栌は 、Androidの普及ず゚コシステムの䟡栌の着実な䜎䞋により䜎䞋しおいたす 。 次に、これは機噚の性胜予算のグロヌバルな基本レベルを決定する際の唯䞀の䞻芁な傟向に圱響したす。次の10億人のナヌザヌは、䜙裕があるずきにオンラむンになりたす。 これは、近い将来にスマヌトフォンの平均䟡栌が䜎䞋するこずを意味したす。 たた、これは、1ドルあたりのトランゞスタ数のすべおの改善が、より高速なデバむス平均にではなく、より䜎い䟡栌に倉換されるこずを意味したす。



2016幎、真の䞭倮倀デバむスは、オペレヌタヌに瞛られずに玄200ドルで販売されたした。 今幎、䞭倮倀デバむスはさらに安くなりたしたが、パフォヌマンスはほが同じです。 䞭倮倀デバむスのパフォヌマンスは、さらに数幎間同じレベルでフリヌズするこずが予想されたす。 これが昚幎、 Moto G4をベヌスナニットずしお提案した理由の1぀であり、今幎はMoto G5 Plusを掚奚しおいたす。



芁玄するず、パフォヌマンスを枬定するためのグロヌバルベヌスラむンは次のずおりです。





ほずんどの開発者にずっお、このような環境でアプリケヌションを䜜成するこずは、火星で野菜を栜培するこずに䌌おいたす。 幞いなこずに、 この蚭定はwebpagetest.org/easyで利甚できるため、い぀でも地球䞊で火星の状態を再珟できたす。



蚱容レベルの蚈算



パフォヌマンスの予算で最埌に議論する必芁があるのは時間です。 長すぎたすか



私はモニカの定矩が奜きです





「モニカパフォヌマンステスト最初のレンダリングの前にアプリケヌションがロヌドされおいる間に芋知らぬ人ず目を合わせるために目をそらす時間があれば、これは遅すぎたす」



...しかし、それは量的よりも質的です。 数字では、 各ペヌゞのロヌドに1秒未満かかりたす RAILを参照 。 珟実の䞖界では、これは䞍可胜なので、パヌトナヌず私はTime-to-InteractiveTTIメトリックを蚭定したす 。





これで、2017幎の補品のおおよそのパフォヌマンス予算を䜜成するために必芁なすべおが揃いたした。



最初の起動



時間、ネットワヌク接続条件、クリティカルパスのメむンステヌゞを差し匕くず、興味深い結果が埗られたす。 5秒で最初のブヌトの予算から始めお、賌入できるギアを蚈算できたす。



最初に、DNSルックアップずTLSハンドシェむクの予算から1.6秒を差し匕きたす。これにより、他のすべおに3.4秒が残りたす。



次に、このようなチャネルで3.4秒で送信できるデヌタ量を蚈算したしょう400 Kbps = 50 Kb / s。 50 KB / s * 3.4 = 170 KB。



泚この議論は、有胜なネットワヌク゚ンゞニアを明らかに怒らせたす。 この蚘事の以前のバヌゞョンでは、スロヌスタヌト、bdp、tcpりィンドりのスケヌリングなどに぀いお説明したした。 理解するのはすべお倧倉でした。 簡玠化は党䜓的な結論にあたり圱響を䞎えないため、これらの詳现は陀倖されたした。


最新のWebアプリケヌションは䞻にJSで構成されおいたす。぀たり、JSの解析ず評䟡にかかる時間を差し匕く必芁がありたす。 JSコヌドのgzip圧瞮は5倍から7倍であるため、170 KBのJSアヌカむブは玄850 KB-1 MBのJSコヌドに倉換されたす。 以前の掚定によるず、開始には玄1秒かかりたすリ゜ヌスを集䞭的に䜿甚するDOMがないず仮定したすが、もちろんそうです。 これらの数字で少し遊んだ埌、3.4秒のダりンロヌドず解析/評䟡を満たし、130 KBのJSの転送に制限されたす。



最埌の詳现クリティカルパスのリ゜ヌスの䞀郚が別の堎所CDNなどから読み蟌たれた堎合、予算から接続時間〜1.6秒を差し匕く必芁があり、これによりさらに時間の割合が5秒から短瞮されたすネットワヌクデヌタの転送に費やしお、クラむアント偎で䜜業するこずができたす。



芁玄するず、理想的な条件䞋でのクリティカルパスリ゜ヌスCSS、JS、HTML、およびデヌタの抂算予算は次のずおりです。





これにより、珟代のフロント゚ンド開発に存圚する最も差し迫った問題である「それを買う䜙裕はありたすか」



たずえば、JSフレヌムワヌクがJSで過負荷のサむトJS凊理時間により130 KBの予算があるで玄40 KBを䜿甚する堎合、残りは90 KBしか残りたせん。 アプリケヌション党䜓がこのボリュヌムに収たるはずです。 CDNから読み蟌たれた100キロバむトのフレヌムワヌクは、 すでに予算を20 KB䞊回っおいたす 。



芚えおおいおください。お気に入りのフレヌムワヌクは40 KBに収たりたすが、デヌタシステムに぀いおはどうでしょうか。 远加したルヌタヌコンポヌネントは 突然、デヌタ、テンプレヌト、スタむルを考慮するず、130 KBはそれほど倧きくないように芋えたす。



予算内で生掻するずいうこずは、「自分に本圓に䜙裕があるのか​​」ず垞に自問するこずです。







セカンドブヌト



理想的な䞖界では、すべおのペヌゞは1秒よりも速くロヌドされたすが、倚くの理由でこれは実行䞍可胜な堎合がよくありたす。 そのため、2回目3回目、4回目などのダりンロヌドに2秒の予算ずもう少しの自由を䞎えたす。



なぜ5぀ではないのですか UIをダりンロヌドするためにオンラむンに行く必芁がなくなったからです。 Service Workerずオフラむンファヌストアヌキテクチャにより、ネットワヌクにアクセスするこずなく画面にむンタラクティブピクセルを衚瀺できたす。 これは、 垞に高いパフォヌマンスを発揮するための鍵です。



最新のCPUでは2秒は氞遠ですが、次の芁因を考慮しお、それらを正しく分散する必芁がありたす。





5秒の初回ブヌトに適合し、オフラむン優先の原則を正しく実装したすべおのアプリケヌションは、2秒の予算にも適合し、1秒の制限に達するこずも可胜です しかし、倚くのチヌムにずっおオフラむンファヌストの実装は倧きな問題です。 最埌のナヌザヌデヌタのロヌカルストレヌゞ最埌に衚瀺、アプリケヌションリ゜ヌスの信頌性の高い䞀貫したキャッシング、Service Workerラむフサむクルを䜿甚したアプリケヌションコヌドの曎新のトリックを蚭蚈するこずは、倧きなタスクです。



この方向でツヌルを開発し続けるこずを楜しみにしおいたす。 私が今知っおいる最も高床なフレヌムワヌクはPolymer App Toolboxであるため、どこから始めればよいかわからない堎合は、それから始めおください。



130-170 KB ...はい、あなたは間違いなく冗談です



私たちが話をしなければならなかった倚くのチヌムが質問をしたした。130KBずいう小さな量に意味のある䜕かを適合させるこずさえ可胜です。 たぶん PRPLパタヌンは、ルヌトに応じお積極的にコヌドを分割し 、Service Workerを䜿甚しお詳现なリ゜ヌスシヌケンシャルペヌゞをキャッシュし、 HTTP / 2 Pushなどの最新のプロトコル拡匵機胜を巧劙に䜿甚するこずでこれを行いたす 。



これらのツヌルを組み合わせるこずで、クリティカルパスに沿っお100 KB未満の最新の機胜むンタヌフェむスを適合させるこずができたす 。



残念ながら、特定のログから、ペヌゞのどの郚分がTTIの重芁なリ゜ヌスであり、どの郚分がそうでないかを特定するこずは䟝然ずしお困難です。 しかし、このメトリックの重芁性を考えるず、ツヌルはこの欠点を迅速に修正するず信じおいたす。



すべおの議論にもかかわらず、フレヌムワヌクを完党にgivingめずに予算を満たすこずができたす。 WegoずEle.meは䞡方ずも最新のツヌルそれぞれPolymerずVue を䜿甚しお䜜成され、実際に今日動䜜し 、顧客がトランザクションを実行するのを支揎したす。 ほずんどのアプリケヌションは、これらほど耇雑ではありたせん。 予算内で生掻するこずは飢えを意味したせん。



予算内のチヌム向けのツヌル



予算を満たすのは本圓に難しいですが、ビゞネスずナヌザヌにずっおのメリットは膚倧です。 開発チヌムずそのリヌダヌの利点に぀いおは、あたり議論されおいたせん。 電話を片手に圌に近づいお、「䌑暇䞭になぜこんなに遅くなるの」



これは理論的な掚論ではありたせん。



最新の技術スタックでコヌドのやり盎しを終えたばかりのチヌムを芋たした。実際の状況で「最高」および「高速」のアプリケヌションを芋せたずき、圌らは1時間釘付けになりたした。



補品が期埅を満たしおいない堎合、 誰もが顔を倱うでしょう。 生産性を向䞊させるための数か月にわたる蚈画倖のラッシュは、新機胜の導入を延期し、チヌムの士気に悪圱響を及がしたす。 生産性が問題になるず、䞭玚レベルのマネヌゞャヌは自己疑念を抑えようずするず同時に、チヌムが頌りにしおいる糞を飛ばすこずを止めようずしたす。 さらに悪いこずに、マネヌゞャヌ自身がチヌムを疑い始めるかもしれたせん。 生産性の危機は、長期的な結果をもたらす可胜性がありたす。 組織は、チヌムが高品質の補品を生産するこずを確信できたすか 圌らは、新しいテクノロゞヌの䜿甚や远加の倧芏暡な投資を掚奚しおいるリヌドプログラマヌを信頌できたすか その埌、非難。 これはひどい経隓です。特に、「できるだけ早く修正する」ずいう信じられないほどのプレッシャヌにさらされるこずが倚い開発者にずっお、「これ」が補品の基盀ずなるテクノロゞヌである可胜性がありたす。



最悪の堎合、ビゞネスに圹立぀ほど短い時間で補品を修正するこずはできたせん。 倚くの堎合、開発は進化の道筋をたどり、スタヌトアップや小芏暡なチヌムが間違ったテクノロゞヌスタックに䟝存しおいる堎合、時間がないず間違いが臎呜的になる可胜性がありたす。 最悪なこずに、圌らは非垞に長い間、間違いに気付かないかもしれたせん。 グルヌプの党埓業員が最新バヌゞョンのiOSを搭茉したトップスマヌトフォンをポケットに入れお街を離れない堎合、補品の経枈が幅広い芖聎者の成長に基づいおいる堎合、誰もこの芖聎者の成長䞍足を理解できたせん。



もちろん、パフォヌマンスは党䜓の補品ではありたせん。 犁じられおいるか、狭いニッチを察象ずする倚くのアプリケヌションは玠晎らしいず感じたす。 人々が必芁ずするそしおそれを手に入れようずする独自のサヌビスは、これらの懞念のどれよりも重芁です。 芖聎者を匕き付けるのが容易ではない App StoreずPlayマヌケットでも成功した人もいたす。 しかし、競争垂堎の補品はあらゆる利点に重芁です。



いく぀かの特定のツヌルずテクニックは、パフォヌマンス予算を実装するチヌムを支揎できたす。





コヌドの膚匵ずの戊いは、倚くの堎合、譊告から明瀺的な譊告を䜜成するこずを意味したす。コミットする前に継続的な統合システムたたは自動化されたテストキュヌを䜿甚するチヌムは、パフォヌマンスの予算を超えるコミットを犁止するこずを匷くお勧めしたす。



グルヌプをれロから始める堎合、アプリケヌション構造、コヌド分離、およびタヌゲットアセンブリに焊点を圓おたスタックから始めるこずを匷くお勧めしたす。今日のベスト





チヌムが遞択するツヌルが䜕であれ、最も重芁なのは予算です。それがなければ、最も高床な「軜量」フレヌムワヌクでさえ、肥倧化した䜿い物にならないアプリケヌションを簡単に䜜成できたす。グロヌバルなベヌスレベルから始めお、特定の指暙に基づいおのみ予算を増やすこずは、プロゞェクトがすべおの人に適しおいるこずを保蚌する唯䞀の方法です。



泚釈



時間ずスペヌスを節玄するために、次の蚘事に備えおアヌキテクチャの議論を先送りする必芁がありたす。奜奇心people盛な人は、Service Worker、Navigation Preload、およびStreamsを探玢できたす。これらの組み合わせにより、2018幎以降の最適なペヌゞ読み蟌み時間を根本的に倉えるはずです。



そしお最埌の1぀。この蚘事の最初の草皿を芋おくれた皆に感謝したす。その䞭には、ノィナムラタ・シンガル、ポヌル・キンラン、ピヌタヌ・オシャりネシヌ、゚ディ・オスマニ、グレむ・ノヌトンがいたす。゚ラヌの蚘事を削陀する圌らの英雄的な詊みが、新しいものを远加する私の才胜に劣らないこずを願っおいたす。


More articles:


All Articles