WasmでJavaScriptを動かす意義 - id:anatooのブログ
ある時Twitterのタイムラインを見ていたら、「JavaScriptをWasm化して動かす意味がわからない」というような意見を見かけました。JavaScriptはブラウザに搭載されているV8のようなJavaScriptエンジンによって高速に動作するので、わざわざWasm化してもパフォーマンスは劣化するのになぜなのか?という話なんですが、これは「Wasm化=パフォーマンスのため」という考えだと意義がわからないのでこの記事ではそれについて解説します。 JavaScriptをWasm化して動かすツールやライブラリとしては、Shopifyが開発しているJavyやquickjs-emscriptenなどがあります。JavaScriptをWasm化して動かすためには、ある特定のJavaScriptエンジンをWasm向けにビルドして動かす必要がありますが、そのような用途ではQuickJSというJava
stale-while-revalidate対応のCDNでISRのような挙動を実現する
先日、Next.jsのISR（Incremental Static Regeneration）について書きました。 ISRは非常に強力な機能なのですが、セルフホスティングでNext.jsを動かす場合には色々と使うのが難しかったりします。この記事ではその理由とCDNを使ってISRと似たような挙動を実現する方法を紹介します。 Next.jsのISRをVercel以外で動かすのは難しい Vercelは自社でメンテナンスしているNext.jsを簡単にデプロイできることを大きな強みとしています。Vercelにデプロイする場合、ソースコード上で決められた書き方さえすれば、Vercel側の追加設定なしでISRを利用できます。 しかし、Vercel以外のプラットフォームにデプロイするとなると途端に話がややこしくなります。 Next.jsのISRはキャッシュしたHTMLをファイルシステムに書き込む仕様になっ
2022年におけるフロントエンド開発のベースライン
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog TL;DR:2022にフロントエンド開発で最も考慮すべきユーザー環境は、パフォーマンスでは低スペックのAndroid端末、標準仕様では2年前のSafari、そしてネットワークでは４Gです。それに対してはJSへの過剰依存などが原因で主にパフォーマンスの面でのウェブ全体の対応がよくありません。 こんにちは！LINEフロントエンド開発室のダバロス アランです。この記事のタイトルを見て「釣りタイトルですね〜」と考えている方がいると思いますが今回に限ってはそれを大目に見てください。それはなぜかと言いますと、2021年から2022年にかけて私たちフロントエンドエンジニアが全体的に考え方を改める必要が出るほど大きな変化がありました。 その変
Web Speed Hackathon 2021 miniでほぼ満点を出しました
gzip圧縮だとあまり圧縮できていなく、スライディングウィンドウが小さいせいかなと思ったのですが、実際に大きさがかなり違うみたいなので、それが原因としてありえそうです。 Gzip uses a fixed size, 32KB window, and Brotli can use any window size from 1KB to 16MB, in powers of 2 (minus 16 bytes). This means that the Brotli window can be up to 512 times larger window than the deflate window. Results of experimenting with Brotli for dynamic web content - The Cloudflare Blog AudioContextの
【LINE証券 Frontend】requestIdleCallbackを活用して初期レンダリング時間を約14%削減した話
こんにちは。フィナンシャル開発センターの鈴木です。LINE証券のフロントエンドを担当しています。この記事は【LINE証券 FrontEnd】シリーズの4番目の記事です。 最近のWeb Vitalsの隆盛を受けて、LINE証券のフロントエンドでもパフォーマンスの改善に取り組み始めました。およそ2週間ほど改善に取り組んだ結果として、開発環境での計測ではLighthouseのperformanceスコアが従来より30点ほど上昇しました。 パフォーマンス改善のためにさまざまな施策を行いましたが、この記事ではその中でも興味深かったものとして、requestIdleCallbackを活用してLazy Loadingされるコンポーネントの読み込みを遅延し、その結果初期レンダリングにかかる時間を約14%削減できた事例をご紹介します。 環境 以前の記事でご紹介したとおり、LINE証券のフロントエンドはTyp
Next.jsのFont Optimizations（Webフォントの最適化）を試してみる
追記) v10.2からデフォルトでGoogle Fontsの最適化が行われるように Next.js v10.2から自動でWebフォントの最適化が行われるようになりました。v10.2時点ではGoogle Fontsにのみ対応しているとのことです。特に設定は不要で、いつも通りGoogle Fontsを読み込めばOKです。 ↓ 詳細 これより下の解説は古い内容になります。実装の参考にしないようお願いします。 以前、Next.jsのリポジトリを眺めていたときにFont Optimizationsというプルリクエストを見つけました。 2020年12月時点ではExperimantalな機能のようですが、v10.0.4で既に使えるようになっていたので試してみました。 :::message alertz Next.js v10.0.4でのドキュメントに則っていない記録になります。 ::: Font Opt
Node.js徹底攻略 ─ ヤフーのノウハウに学ぶ、パフォーマンス劣化やコールバック地獄との戦い方｜ハイクラス転職・求人情報サイト AMBI（アンビ）
Node.js徹底攻略 ─ ヤフーのノウハウに学ぶ、パフォーマンス劣化やコールバック地獄との戦い方 Node.jsをうまく活用できている企業は、どのような方法でベストプラクティスを習得してきたのでしょうか。ヤフー株式会社でNode.jsの社内普及に務めてきた言語サポートチームに、同社の実施を紹介してもらいました。 Node.jsは「イベントループモデルで、ノンブロッキングI/Oを使用している」「問題発生時にHTTP/TCPやPOSIX APIなど低レイヤーの知識を求められる」といった特徴を持つ言語です。開発者が習得すべき技術領域が広いため、Node.jsらしい書き方の学習難易度は高いと言えます。 それでは、Node.jsをうまく活用できている企業は、どのような方法でNode.jsのベストプラクティスを習得してきたのでしょうか。ヤフー株式会社でNode.jsの社内普及に務めてきた言語サポート
Webパフォーマンス虎の巻
Webパフォーマンス向上施策のために、今更ながら超速本1を読んだので、今までの自分の知見と合わせてまとめてみます。 なるべく柔らかく、改善施策ってまず何をどうすればいいの？という疑問を持った人に向けて書いています。 ▪️格言 そもそもWebは速い。遅くしているのは我々です。大抵は技術の問題ではなくて、人の問題。 引用元： テクニックではなく、今、本気で取り組むべきWebパフォーマンス （html5jパフォーマンス部 部長 竹洞さん） 心得 パフォーマンス向上に対する施策は大別すると以下の２通り 軽量化 （単純にやりとりするデータ容量を小さくすること） 圧縮 削除 最適化 （その時に最も適している実装・実行をとること） 経路・順番の変更 非同期 もっとも遅くしている原因を探して、それを対策するのが原則。「対効果」が絶対的正義である。手段から入るのは愚策。まず先に原因を知ることが重要。 ▪️1
React製のSPAのパフォーマンスチューニング実例
カギは社内事例にあり！？システム効率化を超えて運用ミスを激減させた件 2024.09.02 コーポレート 業務改善 業務設計 社内ICT
日経電子版を支える広告技術 — HACK The Nikkei
本稿では、現在の日経電子版モバイル Web（以下、日経電子版）における広告掲示の技術について解説する。 広告とサイトパフォーマンスの関係 dev.to に代表されるような「高速」と言われる Web サイトは、CDN や ServiceWorker などを駆使して表示に関して適切なチューニングを行っており、日経電子版もほぼ同じ思想の元チューニングを行っているが、一点大きな違いを挙げるとするならば、広告表示の有無が挙げられる。 現在の日経電子版では 7 タイプの広告を表示しており、うち 4 タイプは外部 DSP からの配信を行っている。 その他にも様々なサイトトラッキングのサードパーティスクリプトを導入しているが、ご存知の通りこれらはメインとして打ち出したいコンテンツとはほぼ関連性はなく、パフォーマンス観点から見れば劣化させる要因でしかない。広告が無ければもっと速く表示できるのに…と思ったこと
dev.toがなぜinsanely fastを実現出来ているか - Qiita
INSANELY FAST Qiitaを読んでる人なら https://dev.to をほとんどの人が見たはず。見てない人は見てきてください、速すぎて驚くはず。またmizchiさんがdev.toに書いた なぜ dev.to がこんなにも速く、こんなにも自分にとって感動的なのか - dev.to を見た人も多いと思う。個人的にHeroku, Railsを採用してここまで爆速なサイトを構築出来ていることは今までの常識を覆す衝撃な出来事だった。こんな新しい発見をもたらしてくれたdev.toには本当に感謝してる。自分もこんなサイト作ってみたいなと思ってdev.toのことを色々調べてて少し知見がたまったので共有してみます。 この記事はOkinawa.rb Advent Calendar 2017 7日目の記事です。 Twitterやってるのでよかったらフォローしてください🙋♀️ @saboyut
JavaScriptでのDOM操作は重いのかという話とForced Synchronous Layoutについて - id:anatooのブログ
2015年にもなるのにJavaScriptでのDOM操作のパフォーマンスについて書く。ウェブページにインタラクションを持たせたい時に、JavaScriptでDOM操作を行うことがよくある。このDOM操作のパフォーマンスについて、よく聞く意見を大別すると次の2つがある。 JavaScriptによるDOM操作は重たい レンダリングが重いだけで、DOM操作そのものはそれほど重たくない JavaScriptでオブジェクトのプロパティを操作したりする単体の処理は通常1ミリ秒もかからないが、DOM操作をするとレンダリングが完了するまでに数十ミリ秒程度かかったりする場合がある。1番目のDOM操作が重たいと言っている人は経験則的にそう言っていることが多い。 レンダリングの仕組みを知っている人は2番目の意見を言うが、重箱の隅をつつくような話をするとこれも必ずしも正しいわけではない。DOM操作するコードによっ
爆速モバイルWeb、AMPの仕組み抄訳 - ku-sukeのブログ
鈴木さんの記事を読みましてAMPの仕組みについて読んでみました。以下抜粋して日本語メモを。 モバイルウェブが爆速に！ GoogleがAMP (Accelerated Mobile Pages) を立ち上げ | 海外SEO情報ブログ 追記：ざっくり言うと、主にニュースとか静的コンテンツを想定し、HTML+CSSでJSは原則禁止、広告とかで使いたい場合iframeを用意するのでその中だけ。iframeや画像は事前にサイズを固定し変更不可にすることでlazyloadしてもレンダリング時にガタガタしないよね。というAMP HTMLフレームワークを策定したお話です。 原文：https://www.ampproject.org/how-it-works/ モバイルのための仕組み （※見出しは筆者による） Web performance is not unexplored territory for t
Webフロントエンド表示速度、最速化手法まとめ - Qiita
やりすぎても無駄になることがあるので、必要十分なバランスを見極めて実施する。主に社内のプログラマ向けのまとめ資料。他にもあれば追記していく予定。 ページの状態を調べる まず対象のページが、どういった状態なのかを調べる。 Google PageSpeed Insights これを100点満点にする必要はないが、赤くなっている項目に関しては、なるべく対応したほうが良い。モバイルサイトにも対応しているので便利。 https://developers.google.com/speed/pagespeed/insights/?hl=ja pingdom 実際にページにアクセスしてスピードを計測できる。海外サーバなので、けっこう遅い…。最適化前と最適化後で比較するのに使うといい。 http://tools.pingdom.com/fpt/ Chromeデベロッパーツール コンテンツの読み込み順序／速度
文字列の結合方法による速度差 - Qiita
文字列の結合のさせ方によって速度が結構違う 多分これ常識なのかもしれませんが、測ってみてはじめてその速度差がわかったのでメモっときます。 下記コードにて計測 var cnt = 100000; var moji = ''; console.time("Case1"); for (var i = cnt - 1; i >= 0; i--) { moji = ''; moji += 'もじもじ'; moji += 'もじもじ'; moji += 'もじもじ'; moji += 'もじもじ'; moji += 'もじもじ'; }; console.timeEnd("Case1"); console.time("Case2"); for (var i = cnt - 1; i >= 0; i--) { moji = ''+ 'もじもじ'+ 'もじもじ'+ 'もじもじ'+ 'もじもじ'+ 'もじもじ
JavaScriptがページの読み込み時間を遅くする理由トップ10 | ゆっくりと…
CSS Sprites 化や画像サイズの最適化、Data URI 化、CSS/JavaScript ファイルの圧縮・結合・読み込み順番の整理やキャッシュ制御など、本サイトでは主に HTTP リクエストの数、データ量およびそれらの順番に関して色々なテクニックを試してきましたが、さらに深く掘り下げるには JavaScript の実行がページの読み込み時間に与える影響を知っておく必要があると思います。 「ウェッブサイトの表示速度を測定するフリーツール集」 でも紹介しましたが、dynaTrace AJAX Edition という優れたツールをフリーで公開している dynaTrace software のブログでこの問題を扱った記事がありましたので共有します。JavaScript 高速化 Tips は （例えば 「JavaScriptを高速化する6つのテクニック」 など） 多々あるかと思いますが、ペ
JavaScript Garden
JavaScript Garden はJavaScriptというプログラム言語の一番奇妙な部分についてのドキュメント集です。 このドキュメントはJavaScriptという言語に慣れていないプログラマーがこの言語について深く知ろうとする際に遭遇する、良くある間違い・小さなバグ・パフォーマンスの問題・悪い習慣などを避ける為のアドバイスを与えます。 JavaScript GardenはJavaScriptを教える事を目的にしていません。このガイドの項目を理解する為には、この言語に対する前提知識がある事を推奨します。この言語の基礎部分についてはMozilla Developer Networkのガイド がオススメです。 著者 このガイドは愛すべきStack Overflowの2人のユーザーIvo Wetzel (執筆)とZhang Yi Jiang (デザイン)によって作られました。 貢献者 貢献
Chrome DevToolsを使ってJavaScriptのメモリリークを検出し、解消する - 人生dat落ち
JavaScriptを書いていたらブラウザがくっそ重くなる症状に出くわした。あぁ、噂のメモリリークですわ。 先人の知恵に頼るマン。それっぽい記事が見つかる。 javascriptのメモリリーク対策(随時更新) - Qiita Shibu’s Diary: JavaScriptのメモリリークを10倍速で発見する Taming The Unicorn: Easing JavaScript Memory Profiling In Chrome DevTools Writing Fast, Memory-Efficient JavaScript - Smashing Magazine angularjs - How to catch memory leaks in an Angular application? - Stack Overflow 上の記事はProfiles + Take Heap
ユーザーの体感速度を高めるためのJavaScriptチューニング（後編）
連載「Webサイト・アプリ高速化テクニック徹底解説」の第3回は、前回の「ユーザーの体感速度を高めるためのJavaScriptチューニング（前編）」の続きです。この後編では、「ユーザーの操作を阻害しない」方法についてJavaScriptのシングルスレッドやイベントループを交えて解説し、HTML5のWeb Workersについても紹介していきます。 前回は、ユーザーの体感速度を向上させるための方法として、3つのうち「ページを素早く表示する」と「ユーザーに素早くインタラクションを返す」を解説しました。今回は、最後の「ユーザーの操作を阻害しない」について詳しく解説していきます。 ユーザーの操作を阻害しない JavaScriptによる処理が重くなると、いつまでも画面が更新されなかったり、ユーザーの操作が止まってしまったりということがあります。止まっている時間が長すぎると、ブラウザから応答がないという
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTML5アプリにおけるパフォーマンスの基礎知識
