責任あるJavaScript開発パート1

この数値は、JavaScriptコードの増加がWebプロジェクトのパフォーマンスに悪影響を与えることを示しています。 これがさらに続く場合、すぐに中間ページをロードするときに、少なくとも400 KbのJSコードが転送されます。 そして、これは転送されたデータの量です。 他のテキストリソースと同様に、JavaScriptコードはほとんどの場合、圧縮形式で送信されます。 サーバーからクライアントにコードを転送するときに通常行われるのは、おそらく圧縮だけです。







残念ながら、特定のリソースの転送時間を短縮することは「パフォーマンス」と呼ばれるものに大きく貢献しますが、圧縮は、スクリプトが完全にロードされた後のスクリプトの解析と処理にかかる時間には影響しません。



サーバーが400 KBの圧縮JSコードをクライアントに送信する場合、受信したデータを解凍した後にブラウザーが処理する必要がある実際のコード量はメガバイト領域になります。 さまざまなデバイスがこの種の作業をどの程度うまく処理できるかは、デバイス自体に依存します。 これについては多くのことが書かれていますが、その時間のために非常に普通であるコードの量を解析するために必要な時間は、デバイスによって大きく異なると自信を持って言うことができます。



たとえば、 この単純なプロジェクトをご覧ください。 ページの読み込み中に、約23 Kbの非圧縮JSコードがクライアントに転送されます。 2017年半ばにリリースされたMacBook Proで動作するChromeは、このかなり少量のコードを約25ミリ秒で処理します。 ただし、 Nokia 2 Androidスマートフォンでは、同様の数値が190ミリ秒に拡大します。 これは非常に小さいと言っているわけではありませんが、いずれにしても、ページは十分にすばやくインタラクティブになります。



さて、重要な質問です。 シンプルなNokia 2スマートフォンは、平均的な現代のページをどのように管理していますか？ 実際、ひどいです。 JavaScriptコードがロードされたページでの作業は、かなりの期間が経過した後にのみ可能になるため、高速インターネット接続であってもWebページを閲覧すると、ユーザーは忍耐を必要とします。









処理がメインスレッドをブロックする大量のJSコードを含むページを表示したときのNokia 2のパフォーマンスの概要



Webページの閲覧に使用するデバイスとデータが送信されるネットワークは近年大幅に改善されましたが、これらの改善はすべて、ページに含まれる大量のJSコードによって「食い尽くされる」ことが示されています。 JavaScriptを責任を持って使用する必要があります。 責任は、私たちが作成しているものとその方法を理解することから始まります。

「サイト」と「アプリケーション」のイデオロギーの比較

奇妙なことは、私たちが何かを呼ぶために使用する不正確な用語で起こりますが、その意味は直感的なレベルでは誰でも理解できます。 ミツバチとスズメバチの違いは非常に重要ですが、「ハチ」という言葉の意味を「ハチ」やハチと呼んでいます。 このような違いを考慮すると、「ハチ」と「ハチ」の行動が異なるという事実につながる可能性があります。 たとえば、私たちはスズメバチの巣を破壊しますが、ハチについて話している場合、昆虫ははるかに有用で脆弱です。間違った場所にある巣はおそらく破壊せず、どこかに移すことに決めます。



「ウェブサイト」および「ウェブアプリケーション」という用語の使用方法にも同様の自由が見られます。 これらの概念の違いは、実際のハチとミツバチの違いほど明白ではありませんが、これらの概念を組み合わせると、非常に不快な結果につながる可能性があります。 特定のプロジェクトが「単なるWebサイト」であるか「本格的なWebアプリケーション」であるかに応じて、何かを許可するとトラブルが始まります。 会社の情報サイトを作成する場合、DOMの変更を管理したり、クライアントにルーティングを実装したりするための強力なフレームワークに依存することはほとんどないでしょう。 少なくとも、そう願っています。 特定の問題を解決するのにあまり適していないツールを使用すると、サイトを使用する人々に害を与えるだけでなく、おそらく開発プロセスに悪影響を与える可能性があります。



Webアプリケーションを開発するとき、すべてが異なって見えます。 パッケージをインストールします。これには、プロジェクトに数千ではないにしても数百もの依存関係が追加されます。 さらに、私たちはそれらのいくつかの安全性についてさえ確信がありません。 バンドラーの複雑な構成を記述します。 このようなユビキタスなクレイジーな開発環境で作業する場合、収集されたものが高速であり、プロジェクトが機能するはずの場所で機能するようにするために、知識と注意が必要です。 疑わしい場合は、プロジェクトのルートディレクトリでnpm ls --prodコマンドを実行し、このコマンドが表示するすべてを使用する目的に名前を付けられるかどうかを確認します。 たとえそれができたとしても、これはサードパーティのスクリプトには適用されません。 このようなスクリプトもいくつかプロジェクトで使用されていると確信しています。



WebサイトとWebアプリケーションの両方が同じ「生態学的ニッチ」を占めることを忘れています。 両方とも、さまざまなネットワークとデバイスで構成される環境の同じ影響下にあります。 「アプリケーション」を開発しているものと呼ぶことにした場合、このような制限はなくなりません。また、「サイト」を「アプリケーション」と呼ぶ場合、ユーザーのデバイスが魔法のように速くなることはありません。



私たちが作成したものを誰が使用するかを見つけるのは私たちの責任であり、異なるユーザーがインターネットに接続する条件は私たちが依存している条件とは異なる可能性があるという事実を考慮する必要があります。 何かを作成するとき、私たちはそれを作成するための目標を知る必要があり、その後でのみ、この目標を達成するのに役立つものを開発する必要があります-開発がそれほどエキサイティングな仕事ではないと判明した場合でも。



これは、JavaScriptへの依存を再評価する必要があることを意味し、特にHTMLとCSSを損なうJavaScriptの使用が、Webプロジェクトのパフォーマンスとアクセシビリティを損なう不合理なパターンの使用につながる可能性があることを意味します。

フレームワークに不合理なパターンを課させないでください

フレームワーク固有のチームと協力して生産性を向上させたときに、コードベースで奇妙なことが発見されました。 これらの発見の多くには共通点が1つあります。それは、それらの記述方法がサイトの可用性とパフォーマンスの問題につながることが多いということです。 たとえば、次のReactコンポーネントを考えます。

import React, { Component } from "react"; import { validateEmail } from "helpers/validation"; class SignupForm extends Component {  constructor (props) {    this.handleSubmit = this.handleSubmit.bind(this);    this.updateEmail = this.updateEmail.bind(this);    this.state.email = "";  }  updateEmail (event) {    this.setState({      email: event.target.value    });  }  handleSubmit () {    //      -      if (validateEmail(this.state.email)) {      // ...    }  }  render () {    return (      <div>        <span class="email-label">Enter your email:</span>        <input type="text" id="email" onChange={this.updateEmail} />        <button onClick={this.handleSubmit}>Sign Up</button>      </div>    );  } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、プロジェクトのアクセシビリティに関するいくつかの注目すべき問題を見つけることができます。

1. <form>
   
   
   
   要素を使用しない<form>
   
   
   
   は、もはやフォームではありません。 実際、親<div>
   
   
   
   要素のrole = "form"を指定するだけでこれを修正できますが、フォームを作成し、表示されるものがフォームのように見える場合は、 <form>
   
   
   
   要素を使用して、それに応じて設定します属性action
   
   
   
   およびmethod
   
   
   
   。 action
   
   
   
   属性はここで重要な役割を果たします。これは、JavaScriptが使用できない場合でも（当然、コンポーネントがサーバーでレンダリングされた場合でも）フォームが少なくとも何かを実行できるようにするためです。
2. <span>
   
   
   
   、 <label>
   
   
   
   代わりで<span>
   
   
   
   ません。これは、 <span>
   
   
   
   はないプロジェクトの可用性に関する機能を提供します。
3. type="submit"
   
   
   
   属性のない<button>
   
   
   
   要素は単なるボタンであり、これをクリックすると、それにバインドされたイベントハンドラが呼び出されます。 フォームを送信する前にデータを処理する場合は、ボタンにtype="submit"
   
   
   
   属性を割り当て、 onClick
   
   
   
   イベントハンドラーからonSubmit
   
   
   
   フォームイベントハンドラーにコードを移動する必要があります。
4. ところで、JavaScriptを使用して電子メールアドレスを検証するのに対し、HTML5では、ほとんどすべてのブラウザー（IE10まで）で入力データのチェックをサポートするコントロールを自由に使用できます。 ここでは、ブラウザにすでにある機能を利用して、適切な要素タイプと必須属性を適用する機会を逃しています。 ただし、このような構造を使用する場合は、スクリーンリーダーとの通常の対話を設定するには多少の労力が必要になることに注意してください。

上記を考慮して、コンポーネントコードをリファクタリングします。

 import React, { Component } from "react"; class SignupForm extends Component { constructor (props) {   this.handleSubmit = this.handleSubmit.bind(this); } handleSubmit (event) {   //    ,         XHR   // (      ,     ,     JS).   event.preventDefault();   //  … } render () {   return (     <form method="POST" action="/signup" onSubmit={this.handleSubmit}>       <label for="email" class="email-label">Enter your email:</label>       <input type="email" id="email" required />       <button type="submit">Sign Up</button>     </form>   ); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

現在、このコンポーネントがレンダリングされるという事実は、よりアクセスしやすいだけでなく、以前と同じ機能を実装するために使用されるJSコードが少なくなっていることがわかりました。 JavaScriptで文字通りdrれている世界では、数行のコードを削除することは前向きなものと見なされるべきです。 ブラウザは多くの機会を与えてくれるので、できるだけ頻繁にこれらの機会を利用するよう努力する必要があります。



ここでは、特定のフレームワークを使用する場合にのみページのアクセシビリティに関する問題が発生するとは言いたくありません。 つまり、開発者はJavaScriptに頼りすぎて、多くの重要なHTMLおよびCSS機能を単純に見逃してしまいます。 知識のこれらのギャップはしばしばエラーにつながり、さらに、これらのエラーを疑うことさえありません。 フレームワークは、開発者の生産性を向上させる便利なツールになりますが、開発で使用される補助ツールに関係なく、基本的なWebテクノロジーの機能を常に研究することは、便利で使いやすい製品を作成する上で非常に重要です。

Webプラットフォームの力に頼って、プロジェクトに明るい未来を与えましょう

フレームワークについて話しているので、Webプラットフォーム自体も巨大なフレームワークであることに注意してください。 前のセクションで示したように、マークアップを使用する確立されたパターンとブラウザーの機能に依存できる場合、より良い立場にあります。 これらの標準機能の代替手段は、それらを再度発明することです。 言うまでもなく、このような「発明」にはかなりの困難が伴います。 しかし、そのような問題がそれぞれ独自の方法で、インストールするすべてのJavaScriptパッケージの作成者によって解決されるとしたらどうでしょうか。

▍シングルページアプリケーション

簡単に購入できる開発者の弱点の1つは、このモデルが適さないプロジェクトでも、シングルページアプリケーション（SPA）モデルを使用することです。 もちろん、このようなプロジェクトは、クライアントによって実行されるルーティングのために、ユーザーにより生産的であると認識されるという事実の恩恵を受けます。 しかし、SPAモデルを使用することの欠点は何ですか？ ブラウザの組み込みページナビゲーション機能は、同期モデルに基づいていますが、プロジェクトに多くの利点をもたらします。 それらの1つは、訪問の歴史の管理が複雑な仕様の実装を通して実行されるということです。 JavaScriptを持たないユーザーは、JavaScript を無効にしたかどうかに関係なく 、プロジェクトを操作する機能を失うことはありません。 JavaScriptをオフにしたブラウザーで1ページのアプリケーションを使用可能にするには、サーバーのレンダリングにかなりの注意を払う必要があることが突然判明しました。









低速通信チャネルで実験アプリケーションをロードするためのさまざまなオプションの比較。 左側のアプリケーションのレンダリングは、JavaScriptに完全に依存しています。 右側のアプリケーションはサーバー上でレンダリングされますが、クライアント上でhydrate（）メソッドを使用して、サーバー上で既に作成されたマークアップにコンポーネントを接続します



ここでは、クライアントでレンダリングされるアプリケーションが数秒間ユーザーに空白の画面を表示し、完成したインターフェイスを表示することがわかります。



サーバーでレンダリングされ、クライアントで動作可能にレンダリングされたアプリケーションは、メインのインターフェース要素をすばやく表示しますが、クライアントで完全にレンダリングされるアプリケーションとほぼ同じ時間後に使用できます。



クライアントにあるルーターが、ユーザーが表示しているページの変更をユーザーに通知できない場合も、アプリケーションの可用性が低下します。 これにより、ユーザーは支援技術に頼ってページ上の正確な変更を見つけることができ、その結果、サイトでのユーザーの作業ははるかに複雑になります。



さらに、システムの過剰な負荷である古い敵にすぐに出会うことができます。 一部のクライアントルーターは非常に小さいです。 ただし、 Reactでプロジェクトを作成し、互換性のあるルーターを使用し、場合によってはアプリケーションの状態を管理するライブラリを使用する場合、一定量のサービスコードが含まれることに同意する必要があります。 つまり、この場合、約135 Kbのコードです。 作成するプロジェクトを慎重に分析し、クライアントルーティングがシステムの追加負荷に見合うかどうかを分析します。 通常、クライアントルーティングシステムを拒否する方が良いことがあります。



ユーザーの気持ちを心配している場合、サイトを高速に見せたい場合は、 rel = prefetch link属性を使用できます。これにより、同じソースからのドキュメントのプリロードを整理できます。 この属性を使用すると、ユーザーが認識するプロジェクトのパフォーマンスの向上に大きな影響を与えます。これらのリンクをクリックすると、この属性の使用にリンクされたページがキャッシュから即座にロードされるためです。 さらに、データのプリロードの優先度が低いため、帯域幅をめぐって重要なリソースと競合することはほとんどありません。









/を記述することによって参照されるHTMLコードは、サイトのメインページにアクセスしたときにプリロードされます。 ユーザーが対応するリンクをクリックすると、HTMLコードがブラウザーキャッシュから即座にロードされます。



ページのプリロードで発生する可能性があり、注意する必要がある主な問題は、そのようなロードが時間とリソースの無駄になる可能性があることです。 それを解決するには、たとえば、Googleの小さなQuicklinkスクリプトを使用して、この問題を軽減できます。 現在のクライアントが低速接続を使用しているかどうか、 データ保存モードが有効になっているかどうかをチェックし、デフォルトでは、ページソース以外のソースからの素材のプリロードを回避できます。



何度もアクセスするユーザーの目にはサイトの見た目を速くするために、 Service Workerを使用できます。 サービスワーカーの機能の一部に精通している場合は、プロジェクトでクライアントルーティングシステムを使用するかどうかに関係なく使用できます。 サービスワーカーを使用してルートキャッシングを実行すると、一部のリンクの素材をプリロードする場合に通常見られるのと同じ利点が多数得られますが、リクエストと回答を処理する機会ははるかに多くあります。 サイトを「アプリケーション」として認識するかどうかにかかわらず、サービスワーカーを装備することは、おそらく最も重要なJavaScriptの使用例の1つです。

▍JavaScriptはレイアウト用に設計されていません

ページレイアウトに関連する問題を解決するために設計されたJSパッケージをインストールする場合は、このパッケージで何を達成しようとしているのかを慎重に確認する必要があります。 CSSは、ページレイアウトを構築するために特別に作成されたもので、効果的に使用するために抽象化は必要ありません。 JavaScriptを使用して解決しようとする要素の配置、要素の配置 、サイズの調整（ テキストの管理など）、 JavaScriptを使用したレイアウトの完全な作成など、レイアウトを構築するタスクのほとんどは、CSSを使用して解決できるようになりました。 FlexboxやGridなどのレイアウトを作成するための最新のツールはブラウザで十分にサポートされているため、レイアウトを操作するためのフレームワークに基づいてプロジェクトを開発する必要はありません。 ところで、CSSはフレームワークでもあります。 私たちが自由にプロパティリクエストなどの機会がある場合、レイアウトの新しい改善手段をサポートするためのレイアウトの進歩的な改善は、結局のところそれほど難しくありません 。

 /*   , ,   ,        CSS Grid. */ /*  @supports  ,     CSS Grid,     . */ @supports (display: grid) { /*      */ @media (min-width: 40em) {   /*       CSS Grid */ } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

JavaScriptを使用してページレイアウトを作成し、その外観をカスタマイズする問題を解決することは、ニュースではありません。 これは、すべてのサイトが当時のより高度なブラウザーと同じようにIE6のように見えるべきだと言って、2009年に私たちが自己欺liveの雰囲気に住んでいたことです。 今日、2019年に、すべてのブラウザーで同じように見えるようにサイトを開発し続ける場合、これは目標を再考する必要があることを意味します。 サポートが必要なブラウザは常に存在し、最新のブラウザと同じ機能を備えていません。 すべてのプラットフォームでのプロジェクトの完全な外部類似性は、エネルギーの浪費であるだけでなく、 進歩的な改善のアイデアの主要な敵でもあります。

結論：JavaScriptキラーになるつもりはありません

誤解しないでください、私はJavaScriptの敵に属していません。 この言語のおかげで、私はキャリアを築き上げました。そして、率直に言って、JavaScriptは10年以上にわたって私に多くの喜びをもたらしています。 長期的な関係の場合と同様に、JavaScriptを使用する時間が長くなればなるほど、JavaScriptをよりよく知ることができます。 これは、多くの機能を備えた成熟した言語であり、毎年改善されています。



ただし、JavaScriptの関係に何か問題があるように思える場合があります。 私は彼を批判します。 または、より正確には、JavaScriptを主に他のことを見ることなく使用されるメインのサイト構築ツールと見なす現在の傾向を批判します。 紛らわしいクリスマスガーランドのように見える別のバンドルを分析すると、ウェブがJavaScriptに夢中になっていることが明らかになりました。 状況がこれを必要としない場合であっても、ほとんどすべての理由でこの言語に頼ります。 時々、私はJSに対するこの態度の結果がどれほど深刻であるかについて考えます。



私はJavaScriptとWeb開発について書き続け、Webテクノロジーを合理的に使用する方法を探し続けるつもりです。 うまくいけば、私たちは現代のウェブをより良くすることを願っています。



親愛なる読者！ 最新のウェブは本当にJavaScriptコードでオーバーロードされていると思いますか？