Maybe you don't need Rust and WASM to speed up your JS
Few weeks ago I noticed a blog post “Oxidizing Source Maps with Rust and WebAssembly” making rounds on Twitter - talking about performance benefits of replacing plain JavaScript in the core of source-map library with a Rust version compiled to WebAssembly. This post piqued my interest, not because I am a huge on either Rust or WASM, but rather because I am always curious about language features an
Navigation Timing APIの仕様 - Qiita
利用可能なブラウザ Google Chrome Ver18〜 Firefox 7〜 Android OS Ver4〜 概要 Webサイトの制作では、ページデータの読み込み時間が問題になることがあります。ページが表示されるまでに時間がかかると、ユーザーのストレスが増加し、場合によってはユーザーが離れてしまう場合もあります。すばやく表示されるWebサイトであれば、ユーザーも使いやすいはずです。また、Googleはページの表示速度を検索結果の順位算出に使っていると明らかにしています（Googleの発表）。 ページの読み込み速度はJavaScriptで計測できます。ところが、JavaScriptではHTMLファイルが読み込まれHTMLの解釈が始まった段階からしか計測できず、どの処理に時間がかかっているのか、詳細な処理時間を把握できません。 そこで登場したのが、「Navigation Timing
Webアプリで起きるクライアントサイドの性能劣化パターンとその改善チューニング
本連載は、パフォーマンスを主な対象としてシステム開発・運用の改善や設計を行うNTTデータのコンサルタントチーム「まかせいのう」のメンバーが、業務での体験やそこから得た知見を共有する『週刊まかせいのう』の記事を編集し転載するものです。今回は、クライアントサイド（Webブラウザ）の処理性能を劣化させるパターンと、それを改善し性能を向上させるチューニング方法を紹介します。 遅延原因がクライアント側にある場合の2つのパターン いわゆる「性能が出ない」「画面がもっさりして処理が遅い」という性能問題が発生した場合、必ずどこかに遅延を発生させているコンポーネント、いわゆる「ボトルネック」が存在します。それはWebサーバであったり、DBサーバであったり、はたまたネットワークやストレージであったりします。 一般的に、こうした遅延箇所の多くはサーバサイドに集中しています。サーバサイドでは、多くのユーザリクエス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
