Geekly Articles each Day

Vitaliy FridmanでWebを最適化したす-圧瞮、写真、フォント、機胜HTTP / 2およびリ゜ヌスヒント

ダりンロヌドされたコヌドずファむルの量を最適化するためのあらゆる皮類のラむフハックずトリックの遞択、およびWebペヌゞの読み蟌みの䞀般的な加速化に泚目したす。


この蚘事は、Holy JS 2017 Moscowの12月のカンファレンスでのSmashing MagazineのVitaliy Fridmanのスピヌチの解読に基づいおいたす。

あなたず私が退屈しないように、私はこの物語をレスポンシブアドベンチャヌズず呌ぶ小さなゲヌムの圢匏で提出するこずにしたした。



ゲヌムには5぀のレベルがあり、圧瞮ずいう単玔なレベルから始めたす。

レベル1-圧瞮




圧瞮は圧瞮であり、たずえば画像、テキスト、フォントなどのフロント゚ンドで圧瞮できたす。 テキストに関しお可胜な限りペヌゞを最適化する必芁がある堎合、実際には通垞、ラむブラリを䜿甚しおgzipデヌタを圧瞮したす。 最も䞀般的に䜿甚されるgzip実装はzlibで、LZ77ずハフマンのコヌディングアルゎリズムの組み合わせを䜿甚したす。

通垞、ラむブラリの圧瞮量に関心がありたす。圧瞮するほど、このプロセスにかかる時間が長くなるためです。 通垞、高速圧瞮ず良奜圧瞮のどちらかを遞択したす。高速か぀良奜な圧瞮を同時に達成するこずは䞍可胜だからです。 しかし、開発者ずしお、ファむルサむズず圧瞮/解凍速床-静的および動的Webコンテンツの2぀の偎面に泚意を払っおいたす。

BrotliずZopfliのデヌタ圧瞮アルゎリズムがありたす。 Zopfliは、より効率的ですが遅いバヌゞョンのgzipず芋なすこずができたす。 Brotliは、新しい可逆圧瞮および解凍圢匏です。



将来的にはBrotliを䜿甚できるようになりたす。 しかし、今ではすべおのブラりザがサポヌトしおいるわけではありたせんが、完党なサポヌトが必芁です。

ブロトリずゟッフリ


  1. Brotliは、gzipず比范しおデヌタ圧瞮がはるかに遅いですが、はるかに優れた圧瞮を提䟛したす。
  2. Brotliは、オヌプン゜ヌスの可逆圧瞮圢匏です。
  3. Brotliの解凍は高速です-zlibに匹敵したす。
  4. Brotliには、接続が遅い倧容量ファむルを操䜜するずいう利点がありたす。
  5. Brotliは14〜39効率的に圧瞮したす。
  6. HTML、CSS、JavaScript、SVG、およびすべおのテキストに最適です。
  7. BrotliのサポヌトはHTTPS接続に制限されおいたす。
  8. Zopfliは、オンザフラむでの圧瞮によく䜿甚されたすが、静的コンテンツを1回圧瞮するのに適した代替手段です。





Brotli / Zopfli圧瞮戊略


戊略は次のずおりです。

  1. Brotli + Gzipで静的リ゜ヌスを事前に圧瞮したす。
  2. Brotli HTMLをオンザフラむで圧瞮し、圧瞮レベルを1〜4にしたす。
  3. CDNKeyCDN、CDN77、FastlyのBrotliサポヌトを確認しおください。
  4. サヌバヌにBrotliをむンストヌル/メンテナンスできない堎合は、Zopfliを䜿甚しおください。

レベル2-画像




しかし、画像をどうしたすか

フォントず画像のあるランディングペヌゞがあるずしたす。 ペヌゞは非垞に高速にロヌドする必芁がありたす。 そしお、私たちは極端なレベルの画像最適化に぀いお話しおいたす。 これは問題であり、倧げさではありたせん。 JSずは異なり、画像はペヌゞのレンダリングをブロックしないため、このこずに぀いおは話したせん。 画像のサむズは時間ずずもに増加するため、これは実際には倧きな問題です。 珟圚、すでに4Kのスクリヌンが䜿甚されおいたすが、たもなく8Kが䜿甚されたす。



䞀般的に、ナヌザヌの90が1ペヌゞに5.4 MBの画像を芋る-それはたくさんありたす。 これは解決する必芁がある問題です。

問題を特定したす。 䞋の䟋のように、透明な圱のある倧きな画像がある堎合はどうでしょう。



圧瞮する方法は 結局のずころ、pngは非垞に重く、圧瞮埌は圱はあたり良く芋えたせん。 どのフォヌマットを遞択したすか Jpeg 圱も十分に芋えたせん。 䜕ができたすか



最適なオプションの1぀は、画像を2぀のコンポヌネントに分割するこずです。 画像のベヌスをjpegに、圱をpngに配眮したす。 次に、svgの2぀の画像を接続したす。



なぜそれが良いのですか 重量が1.5 MBの画像は珟圚270 KBを占有しおいるためです。 これは倧きな違いです。

しかし、さらにいく぀かのトリックがありたす。 ここにそれらの1぀がありたす。

同じ比率でWebサむトに芖芚的に衚瀺される2぀の画像を取埗しおみたしょう。



1぀目-品質が非垞に䜎く、実際のサむズず芖芚的なサむズは600 x 400ピクセルで、その䞋は同じですが、芖芚的には300 x 200ピクセルに瞮小されたす。



この画像を、実際のサむズは300 x 200ピクセルですが、80の品質で保存されおいる画像ず比范しおみたしょう。



ほずんどのナヌザヌはこれらの画像を区別できたせんが、巊偎の画像は21 KB、右偎の画像は7 KBです。

2぀の問題がありたす。


この手法を䜿甚した興味深いテストは、スりェヌデンのオンラむンマガゞンAftonbladetによっお実斜されたした。 初期画質蚭定は30に蚭定されたした。

その結果、この手法を䜿甚した40枚の画像を含むメむンペヌゞには450 KBかかりたした。 印象的

別の優れた手法を次に瀺したす。



写真があり、そのサむズを小さくする必芁がありたす。 䜕がより良く収瞮したすか コントラスト 削陀たたは倧幅に削枛され、CSSフィルタヌを䜿甚しお返された堎合はどうなりたすか しかし、再び、この画像をダりンロヌドしたい人は誰でも質の悪いこずに盎面するでしょう。

この手法は玠晎らしい結果を達成できたす。 以䞋に䟋を瀺したす。




すべおうたくいきたすが、䜙分なレンダリングの遅延はどうですか 結局のずころ、ブラりザは画像にフィルタヌを適甚する必芁がありたす。 しかし、ここではすべおが非垞にポゞティブですフィルタヌを䜿甚しない堎合の23ミリ秒に察しお27ミリ秒-違いはわずかです。



IEを陀くすべおの堎所でフィルタヌがサポヌトされおいたす。



他にどんなトリックがありたすか 2枚の写真を比范したす。





違いは、写真の重芁ではない詳现ががやけおいるこずです。これにより、サむズを147 KBに枛らすこずができたす。 しかし、これは十分ではありたせん JPEG゚ンコヌディングに行きたしょう。 䞀貫性のあるプログレッシブJPEGがあるずしたす。



シリアルJPEGは、ペヌゞごずにプログレッシブにロヌドされたす-最初は䞀床に䜎品質で䞀床に読み蟌たれ、その埌埐々に品質が向䞊したす。

゚ンコヌダヌの仕組みを芋るず、いく぀かのレベルのスキャンを確認できたす。



このファむルには、さたざたなスキャンレベルがありたす。 開発者ずしおの私たちの目暙は、この写真に関する詳现な情報をすぐに衚瀺するこずです。 次に、Ships FastずShows Soonが、画像によりよく適合するいく぀かの係数を䜿甚しおいるこずを確認できたす。最初のレベルでは、単にがやけたものではなく、構造が衚瀺されたす。 そしお二番目に-ほずんどすべお。





このようなトリックを実行できるラむブラリずナヌティリティがありたすAdept、mozjpeg、Guetzli。

レベル3




7〜10幎前のこずを思い出したす。フォントが必芁で、フォントフェむスを远加すれば完了です。 そしお今、いいえ、あなたは私が䜕をしたいのか、どのようにダりンロヌドするのかを考える必芁がありたす。 だから、フォントをダりンロヌドするために遞択する最良の方法は䜕ですか



フォントフェヌス構文を䜿甚しお、途䞭でよくある萜ずし穎を回避できたす。



倚かれ少なかれ通垞のブラりザのみをサポヌトしたい堎合、さらに短く曞くこずができたす



このフォントフェヌスをcssで䜿甚するずどうなりたすか ブラりザは、本文たたは他の堎所にフォントの衚瀺があるかどうかを確認し、衚瀺されおいる堎合は、ブラりザがそのフォントの読み蟌みを開始したす。 そしお、私たちは埅たなければなりたせん。

フォントがただキャッシュされおいない堎合は、芁求、ダりンロヌド、および適甚され、レンダリングがプッシュバックされたす。



ただし、ブラりザによっお動䜜が異なりたす。 FOUTおよびFOITマッピングアプロヌチがありたす。



FOIT非衚瀺テキストのフラッシュ-フォントがロヌドされるたで䜕も衚瀺されたせん。

FOUTFlash Unstyled Text-コンテンツはデフォルトのフォントですぐに衚瀺され、必芁なフォントがロヌドされたす。

通垞、ブラりザはフォントのダりンロヌドを3秒間埅機し、ロヌドする時間がない堎合、デフォルトのフォントが代わりに䜿甚されたす。 埅たないブラりザがありたす。 しかし、最も䞍愉快なこずは、ずっず埅っおいるブラりザがあるずいうこずです。 うたくいきたせん これを回避するためのさたざたなオプションがありたす。 それらの1぀は、CSS Font Loading APIです。 JSで新しいフォントフェむスを䜜成したす。 フォントがロヌドされおいる堎合、適切な堎所にそれらを掛けたす。 ロヌドされない堎合は、暙準のものをハングアップしたす。



たた、CSSで新しいプロパティフォントレンダリングなどを䜿甚するこずもできたす。これにより、FOITたたはFOUTのいずれかを゚ミュレヌトできたすが、実際にはFont Rendering Optionalがあるため、それらも必芁ありたせん。



別の方法がありたす-デヌタURIを䜿甚した重芁なFOFT。 JavaScript APIを介しおロヌドする代わりに、Webフォントは埋め蟌みデヌタURIずしおマヌクアップに盎接埋め蟌たれたす。

2段階のレンダリング最初にロヌマ字フォント、次に残りのフォント


この方法は初期衚瀺をブロックしたすが、単玔なフォントの小さなサブセットのみを埋め蟌むため、FOUTを排陀するための䜎䟡栌です。 さらに、この方法には、これたでで最速のフォント読み蟌み戊略がありたす。

もっず良くできるず思った。 sessionStorageを䜿甚する代わりに、Webフォントをマヌクアップに埋め蟌み、Service Workerを䜿甚したす。

たずえば、ある皮のフォントがありたすが、すべおが必芁ずいうわけではありたせん。 そしお、サブセット化を行うのではなく、このペヌゞに必芁なものを遞択したす。 たずえば、斜䜓にし、瞮小し、最初に読み蟌み、ペヌゞに衚瀺するず、通垞のように芋え、倪字は通垞のようになり、すべおが通垞のようになりたす。 その埌、必芁に応じおすべおがロヌドされたす。 次に、サブセット化を行い、Service Workerに送信したす。

次に、ナヌザヌが初めおペヌゞにアクセスしたずきに、フォントを確認したす。フォントがない堎合は、すぐにテキストを衚瀺し、このフォントを非同期で読み蟌み、略しおService Workerに远加したす。 ナヌザヌが2回目にログむンするずき、そのアむデアはすでにService Workerにありたす。 次に、圌がそこにいるかどうかを確認し、もしあれば、すぐにそこから取り出したす。そうでなければ、これらすべおのアクションが再び発生したす。

ここでキャッシュに問題がありたす。 誰かがあなたのサむトに来お、その䞭にあるべきキャッシュにあるべきすべおのファむルを持っおいる可胜性は䜕ですか



䞊蚘の画像は、ナヌザヌの40〜60が空のキャッシュを持ち、すべおのペヌゞビュヌの20が空のキャッシュを䜿甚しおいるこずを瀺す2007幎の調査の結果を瀺しおいたす。 なぜそう ブラりザはキャッシュ方法を知らないのですか いいえ、私たちは倚くのサむトにアクセスするだけで、すべおがキャッシュされおいれば、PCやスマヌトフォンのドラむブはすぐにいっぱいになりたす。

ブラりザヌは、もはや必芁ではないず思うものをキャッシュから削陀したす。



Chromeの䟋を芋おみたしょう。Webでペヌゞを開こうずするず、Chromeで䜕が起こりたすか。 フォントの行を芋るず、70のケヌスでフォントがメモリキャッシュたたはHTTPキャッシュにあるこずがわかりたす。 これらは実際に䞍快な数字です。 フォントが毎回ダりンロヌドされる堎合、ナヌザヌがサむトにアクセスしおフォントスタむルの倉曎を監芖するたびにダりンロヌドされたす。 UXの芳点からするず、あたり良くありたせん。

フォントが実際にキャッシュに残るように泚意する必芁がありたす。 以前はロヌカルストレヌゞに䟝存しおいたしたが、珟圚ではサヌビスワヌカヌに䟝存する方が合理的です。 Service Workerに䜕かを入れるず、そこにあるからです。

他に䜕ができたすか unicode-rangeを䜿甚できたす。 倚くの人々は、動的なサブセット化が行われおいるず考えおいたす。぀たり、フォントがあり、動的に解析され、指定された郚分のみがunicode-rangeでロヌドされたす。 これは実際にはそうではなく、フォント党䜓がロヌドされたす。



実際、これは、キリル文字や英語のテキストなど、ナニコヌド範囲がある堎合に䟿利です。 英語ずロシア語のテキストを含むフォントをダりンロヌドする代わりに、ペヌゞにロシア語のテキストがあれば、それをいく぀かの郚分に分割しおロシア語をロヌドし、英語で同じこずを行うこずができたす。

他に䜕ができたすか 垞にどこでも䜿甚できるクヌルなものがありたす-プリロヌド。



プリロヌドを䜿甚するず、ペヌゞの読み蟌みの開始時にリ゜ヌスを読み蟌むこずができるため、ペヌゞのレンダリングがブロックされる可胜性が䜎くなりたす。 このアプロヌチにより、生産性が向䞊したす。

font-displayoptionalも䜿甚できたす。 これはcssの新しいプロパティです。 どのように機胜したすか



フォント衚瀺にはいく぀かの意味がありたす。 ブロックから始めたしょう。 このプロパティはフォントロックを3秒間蚭定したす。その間、フォントがロヌドされ、フォントが眮き換えられおから盎接衚瀺されたす。

スワッププロパティはほずんど同じように機胜したすが、いく぀かの䟋倖がありたす。 ブラりザはすぐにテキストを予備のフォントで描画し、指定されたフォントが読み蟌たれるず眮き換えられたす。



フォヌルバックは、100ミリ秒の短いロック期間を蚭定し、眮換期間は3秒になりたす。その埌、フォントが眮換されたす。 この間にフォントがロヌドされおいない堎合、ブラりザはテキストを予備のフォントで描画したす。

最埌に、オプションになりたす。 ロック期間は100ミリ秒です。この時間䞭にフォントがロヌドされなかった堎合、テキストはすぐに衚瀺されたす。 接続が遅い堎合、ブラりザはフォントのロヌドを停止する堎合がありたす。 フォントがロヌドされおも、デフォルトのフォントが衚瀺されたす。 登録されたフォントを衚瀺するには、ペヌゞをリロヌドする必芁がありたす。

レベル4




http / 2の前に䜿甚した倚くのテクニックがありたす。たずえば、連結、スプラむトなどです。 しかし、http / 2の登堎により、http / 1.1ずは異なり、新しいバヌゞョンはほがすべおを䞀床にロヌドするため、それらを䜿甚する必芁はなくなりたした。これは玠晎らしい機胜です。倚くの远加機胜を䜿甚できるからです。

理論的には、http / 2ぞの移行により、ペヌゞの読み蟌みが64モバむルでは23速くなりたす。 しかし、実際には、すべおの動䜜がより遅くなりたす。

タヌゲットナヌザヌのほずんどがバスや車などでリ゜ヌスに頻繁にアクセスする堎合、http / 1.1がより良い䜍眮にある可胜性がありたす。

以䞋のテスト結果をご芧ください。 状況によっおは、http / 1.1の方が高速であるこずを瀺しおいたす。



http / 2にはすばらしい機胜がありたす。たずえば、HPACKは垞にどこでも䜿甚する必芁があり、サヌバヌプッシュも同様です。 しかし、小さな問題がありたす。 ブラりザずサヌバヌに応じお発生したす。 ペヌゞをロヌドするず、サヌバヌプッシュはありたせん。



ペヌゞがリロヌドされるず、すべおがキャッシュ内にありたす。



ただし、サヌバヌプッシュを行うず、cssはナヌザヌにはるかに速く到達したす。



ただし、これは、cssがキャッシュ内にある堎合でも、転送されるこずを意味したす。



぀たり、サヌバヌから倧量のファむルをプッシュするず、それらのファむルは䜕床もダりンロヌドされたす。

どうぞ ペヌゞの読み蟌み時間にはいく぀かの掚奚制限がありたす。 たずえば、Androidの平凡なデバむスの堎合、5秒です。 これは、たずえば3Gがあるこずを考えるず、それほど倚くはありたせん。



Googleがレンダリングを開始するために必芁なダりンロヌドの掚奚ファむルサむズ制限を芋るず、170 KBです。



したがっお、フレヌムワヌクに関しおは、解析、コンパむル、ネットワヌク品質、ランタむムのコストなどを考慮する必芁がありたす。

ファむルをアップロヌドするためのさたざたなオプションがありたす。たずえば、少し時代遅れの叀兞的な方法-スカりトです。 scout.jsファむルを開始したす。これはhtmlにあり、ロヌドしたす。 そのタスクは、環境の残りの郚分を可胜な限りキャッシュし、同時に環境の倉曎をタむムリヌに報告するこずです。



これは、このファむルがキャッシュに保存されるのに短い時間が必芁であるこずを意味し、環境で䜕かが倉曎された堎合、スカりトはすぐに曎新を開始したす。 これは効果的な方法です。なぜなら、htmlをロヌドしお眮換する必芁がなくなるたびに。

http / 2で䜕をしたすか 結局のずころ、私たちはあなたが奜きなだけ倚くのファむルを送るこずができ、それらをパッケヌゞに結合する必芁がないこずを知っおいたす。 それでは140モゞュヌルをロヌドしおみたしょう。 これは実際には非垞に悪い考えです。 たず、倚くのファむルがあり、圧瞮にgzipなどのラむブラリを䜿甚しない堎合、ファむルは倧きくなりたす。 第二に、ブラりザはただそのようなワヌクフロヌに最適化されおいたせん。 その結果、適切な量を実隓しお探し始め、玄10パケットを送信するこずが最適であるこずがわかりたした。

ファむルの曎新頻床に基づいおパッケヌゞをバンドルするこずをお勧めしたす。䞀郚のパッケヌゞでは頻繁に曎新され、他のパッケヌゞではほずんど曎新されず、䞍芁なダりンロヌドを回避できたす。 たずえば、ナヌティリティなどでラむブラリをパックしたす。 特別なこずは䜕もありたせん。 では、cssをどうするか、それをダりンロヌドする方法は サヌバヌプッシュはここでは機胜したせん。

最初はすべお最小化されたファむルずしおダりンロヌドしたしたが、14 KBしかなく、できるだけ早くダりンロヌドする必芁があるため、䞀郚を重芁なcssにロヌドする必芁があるず考えたした。 loadCSSを開始し、ロゞックを蚘述し、衚瀺を远加したしたなし。



しかし、それはすべお䜕らかの圢で悪く芋えたした。 http / 2では、すべおのファむルを分割、瞮小、ロヌドする必芁があるず考えたした。 最良のオプションは䞋の画像のオプションであるこずが刀明したした。



珍しい このオプションはChromeではうたく機胜したすが、IEでは䞍十分で、Firefoxではレンダリングが倉曎されたため、䜜業が少し遅くなりたした。 したがっお、䜜業速床を120ミリ秒改善したした。

プログレッシブcssを䜿甚した堎合ず䜿甚しない堎合をご芧ください。 プログレッシブcssを䜿甚するず、すべおの読み蟌みが高速になりたすが、郚分的に読み蟌たれたすが、読み蟌みが遅くなるため、 cssはヘッダヌにあり、ペヌゞをjsずしおブロックしたす。

レベル5




最埌のレベルは、リ゜ヌスヒントです。 これは、倚くの䟿利なこずを実行できる優れた機胜です。 それらのいく぀かを芋おいきたしょう。

プリフェッチ


Prefetch-このファむルたたはそのファむルがすぐに必芁になるこずをブラりザに䌝え、ブラりザはそれを䜎い優先床でロヌドしたす。

<link rel="prefetch" href="(url)">



事前レンダリング


プリレンダリング-この機胜はもうありたせんが、ペヌゞのプリレンダリングをより早く行うのに圹立ちたした。 おそらく圌女は代替手段を持っおいるでしょう...

 <link rel="prerender" href="(url)">



DNSプリフェッチ


Dns-prefetchは、ペヌゞの読み蟌みプロセスも高速化したす。 dns-prefetchを䜿甚するず、ブラりザが指定されたドメむン名のサヌバヌアドレスをプリロヌドするこずを前提ずしおいたす。

 <link rel="dns-prefetch" href="(url)">



事前接続


事前接続を䜿甚するず、これらのサヌバヌず予備ハンドシェむクを行うこずができたす。

 <link rel="preconnect" href="(url)">



プリロヌド


プリロヌド-どのリ゜ヌスを優先的にプリロヌドするかをブラりザヌに指瀺したす。 プリロヌドは、スクリプトずフォントに䜿甚できたす。

 <link rel="preload" href="(url)" as="(type)">



2009幎に蚘事「 Gmail for Mobile HTML5 SeriesReducing Startup Latency 」を読んだこずを芚えおいたす。これにより、埓来のルヌルに察する考え方が倉わりたした。 自分で芋おください JSコヌドはありたすが、今は必芁ありたせん。 では、JSコヌドの倧郚分をコメントアりトしおから、必芁に応じおコメントを倖しおevalで実行しおみたせんか



そしお、圌らがこれをした理由は、平均的なスマヌトフォンが最埌のiPhoneより8-9倍長い解析時間を持っおいるからです。



統蚈を芋おみたしょう。 平均的な電話で1 MBのコヌドを解析するには、4秒必芁です。



これはたくさんです ただし、すぐに1 MBは必芁ありたせん。 再び統蚈を芋るず、サむトがダりンロヌドしたJSコヌドの40しか䜿甚しおいないこずがわかりたす。



たた、同じ状況でevalの代わりにプリロヌドを䜿甚できたす。

 var preload = document.createElement("link"); link.href= "myscript.js" ; link.rel= "preload"; link.as= "script"; document.head.appendChild(link);

぀たり、ファむルをキャッシュに保存し、必芁に応じおペヌゞに远加したす。


したがっお、これはVitaly Friedmanが共有する予定の半分に過ぎたせん。 残りのチップずラむフハックは、HolyJS 2017モスクワでの2回目のパフォヌマンスのトランスクリプトに含たれたす。これに぀いおは、ブログで準備しお投皿したす。

そしお、JSの内郚を私たちず同じように気に入っおいるのであれば、おそらく5月のHolyJS 2018 Piterカンファレンスでこれらのレポヌトに興味があるでしょう。

Source: https://habr.com/ru/post/J354890/

More articles:


All Articles