Remix - Build Better Websites
Focused on web standards and modern web app UX, you’re simply going to build better websites Remix is a full stack web framework that lets you focus on the user interface and work back through web standards to deliver a fast, slick, and resilient user experience. People are gonna love using your stuff. export async function loader({ request }) { return getProjects(); } export async function action
Announcing Parcel CSS: A new CSS parser, compiler, and minifier written in Rust!
I'm very excited to announce @parcel/css, a new CSS parser, compiler, and minifier written in Rust! Check it out on GitHub, or try a live demo right in your browser. Parcel CSS has significantly better performance than existing tools, while also improving minification quality. In addition to minification, Parcel CSS handles compiling CSS modules, tree shaking, automatically adding and removing ven
Qwikというフレームワークについて - console.lealog();
GitHub - BuilderIO/qwik: An Open-Source framework designed for best possible time to interactive, by focusing on resumability of server-side-rendering of HTML, and fine-grained lazy-loading of code. 去年から気になってて、調べたいなーと思ってたやつ。 昨今の覇権を握ってる系のJavaScript-firstなフレームワークたちとは違い、HTML-firstを謳うユニークなアプローチをしてるのが一番の特徴。 中の人による一連のシリーズもあって、そこも読んでまとめてみた記事です。 Qwik Series' Articles - DEV Community Qwikの特徴 遅いモバイル環境だとしても、
今Partytownがヤバい。JavaScript Sandboxの未来はどっちだ？
概要 Partytownというプロジェクトが先月発表された。このプロジェクト自体はWebのパフォーマンス向上(3rd Party Scriptによるブロッキングの低減)を主目的としているが、実質ブラウザにおけるJavaScript Sandboxの方向性に一石を投じるものであるとして自分は理解した。本稿ではこちらについて背景とともに解説を試みる。 WebブラウザにおけるJavaScript Sandbox JavaScriptで記述されたWebアプリケーションにおいて、たとえばプラグイン機構を実現したいなど、他Partyが提供あるいはユーザ自身が記述したスクリプトを、ホストとなるアプリケーションに影響を与えることなく実行することを許可したい、というケースはままある。2000年代に跋扈したブログパーツの類はWebコンテンツに対するプラグインの代表例とも言えるが、埋め込み先ページに対しての全権
head内でパフォーマンスの問題がある箇所、Webページのレンダリングを妨げる要因を明らかにするCSS
Webページのレンダリングを妨げる要因、<head>タグ内でレンダリングをブロックしているCSSやJavaScript、サードパーティーのリソースなどを表示して、どこを修正すればよいか教えてくれるCSSのスニペットを紹介します。 ちなみに下記のグリーンは問題なし、レッドはエラーで対応が必要、オレンジは特定のシナリオで問題が発生する、です。 ct.css ct.css -GitHub ct.cssの特徴 ct.cssのデモ ct.cssの使い方 ct.cssの特徴 <head>内にあるタグは、ページのレンダリングを妨げる要因となる最大の箇所で、正しい形式であることは非常に重要です。ct.cssは、Webページの<head>タグ内に潜在するパフォーマンス上の問題を明らかにするCSSのスニペットです。 ct.css ct.cssの使用にあたっての制限事項は、下記の通りです。 一致しないmedia
Perfume.js - Page speed monitoring
Perfume.js Page Speed is a feature, and to deliver it we need to understand the many factors and fundamental limitations that are at play. If we can measure it, we can improve it. Star Follow @zizzamia Why Perfume.js? Perfume is a tiny, web performance monitoring library that reports field data back to your favorite analytics tool. ⏰ Supports latest Performance APIs for precise metrics 🚀 Device d
GitHub - grafana/k6: A modern load testing tool, using Go and JavaScript - https://k6.io
Modern load testing for developers and testers in the DevOps era. Download · Documentation · Community Forum · Public Roadmap k6 is a modern load-testing tool, built on our years of experience in the performance and testing industries. It's built to be powerful, extensible, and full-featured. The key design goal is to provide the best developer experience. Its core features are: Configurable load
ISR化でIESHILの建物詳細ページの読み込み速度を10倍に改善した話 - LIVESENSE ENGINEER BLOG
初めに こんにちは、IESHILでエンジニアをしているgccjです。 IESHILはマンション査定価格がいますぐわかるサービスです。 2021年4月6日にその中でも一番アクセスされている建物詳細ページをISR（Incremental Static Regeneration）化しました。 それについて、目次の順番でご紹介していきたいと思います。 目次 前提--SST, CSR, SSR, SSGの説明 既存のシステム構成 既存のシステム構成における課題 建物詳細ページをISR化した理由 建物詳細ページをISR化した結果 建物詳細ページをISR化した後のシステム構成 最後に 前提--SST, CSR, SSR, SSGの説明 まず、「そもそもISRって何？」という説明はこの後の ISRをした理由で触れる予定です。 一方、それを理解するために、 Server-Side Templating(以下
フロントエンドのパフォーマンスチューニングを俯瞰する - 30歳からのプログラミング
去年からフロントエンドのパフォーマンスについて断続的に学んでいるが、自分の頭のなかにある知識はどれも断片的で、まとまりを欠いているような感覚があった。 知識と知識がつながっておらず、各施策が何のために行われるのかも、必ずしも自明ではなかった。何となく「パフォーマンスに効果がある」と言ってしまうが、それが何を指しているのかは実は曖昧だった。 このような状態では新しい知識を得ていくのが難しいというか、効率的に行えないように思えた。議論の背景が分からないし、文脈や問題意識を上手く掴めないから。何の話をしているのかよく分からない、という状態になりがち。書かれてあることの意味は分かっても論旨を掴めているわけではないから、自分のなかに定着しない。 そこで、現時点で自分が知っていることを整理して、自分なりに分類しておくことにした。 当たり前だが、どのテクニックがどの程度有効なのかは、状況によって違う。
Real-world CSS vs. CSS-in-JS performance comparison
CSS-in-JS has taken a solid place in front-end tooling, and it seems this trend will continue in the near future. Especially in the React world. For example, out of 11492 people who participate in State of CSS survey in 2020 only 14.3% didn’t hear of Styled Components (a dominant CSS-in-JS library). And more than 40% of participants have used the library. I wanted to see an in-depth performance co
「Cloudflare Pages」が正式版に。JAMスタックによる高速なWebサイトを構築、CDNに展開へ
Cloudflareは、JAMスタックを用いてWebサイトを構築する新サービス「Cloudflare Pages」が正式版として提供開始されたことを発表しました。 JAMスタックによるWebサイトの構築とは JAMスタックとは、JavaScript、API、Markup Language（HTML）を主な構成要素としてWebサイトを構築する手法を指します。 WordPressに代表される多くのCMSでは、ユーザーからのリクエストに反応して動的にHTMLが生成されることで、動的なWebサイトを実現しています。この場合、HTMLの生成に一定の時間がかかるため高速なWebサイトの構築が容易ではないこと、サーバへの負荷によりスケーラブルなWebサイトの構築も容易でないことなどが課題です。 JAMスタックでは、HTMLの生成はWebサイトの生成時に行うことで、基本的には静的なWebサイトと同様の高速
useCallbackはとにかく使え！ 特にカスタムフックでは - uhyo/blog
Reactには、パフォーマンス最適化のためのAPIがいくつかあります。具体的にはReact.memo、useMemo、そしてuseCallbackです。 React.memoで囲まれた関数コンポーネントは、propsが以前と変わっていない場合に再レンダリングが抑制されます。 また、useMemoやuseCallbackは、関数コンポーネント内での値の再計算を抑制する効果を持ちます。 これらは最適化のためのツールなので、「過度な最適化」を避けるように啓蒙する言説がよく見られます。 すなわち、ちゃんと本当に最適化のために必要なところにだけこれらを使おうということです。 特に、React.memoはpropsが以前と変わっているかどうかを判定するためのオーバーヘッドがあるし、useMemoやuseCallbackもフック呼び出しのオーバーヘッドがあります。 意味がないところでReact.memo
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
JavaScript 長いループ 分割 - hitode909の日記
ブラウザで長いループや、重い処理をともなうループを回したいとき、同期的にJavaScriptを実行するとメインスレッドがブロックしてしまうので、ちょっとずつ細切れに分割して実行したい、ということがある。 昨日久しぶりに書いたら新たなパターンと出会ったので、これまでにどう書いてて今回どうなったかメモ。 setTimeoutする 以前(10年前とか)はこんなのをよく書いていた。 itemsがでかいArrayで、console.logがすごく重い処理だとして読んでください。 function iterateHeavyTask(items) { const startAt = new Date(); while (items.length > 0 && new Date().getTime() - startAt < 10) { console.log(items.shift()); } if (
jestのテストが遅い場合に確認すべきこと - ishikawa_pro's memorandum
こんにちは。 急に寒くなりましたね。 僕は最近iPad Air4 を予約しました。 今日は、javascriptのテストフレームワークのjestについてです。 業務では去年くらいから新規サーバーアプリケーションはjavascriptではなくTypeScriptを使っています。 それに合わせてテストフレームワークもmochaからjestへ移行しました。 jestjs.io jestの特徴の１つは、一意なグローバル状態を持つことを保証しつつ、複数のテストを別プロセスで並列に実行してくれるため、安全に高速なテストをすることが可能なことです。 しかし、僕が前にいたチームでjestのテストにかかる時間がやたら長いことが話題になってました。 今日は、この高速なはずのjestがやたら遅い問題が社内で話題になっていたので調査してまとめてみたので、もしjestが遅くて困っている方は参考にしてみてください。
node.js のメトリクスの計測、ベンチマークの改善、Docker イメージの絞り方を勉強した
フロントエンドのパフォーマンス計測は得意なのだが、サーバーサイド node.js のメトリクスの取り方はあまり知らなくて、いつも勘でやりがちだった。最近は業務でこの周辺で困ることが増えたので、勉強しなおした。 また、最近使ってみたかった cloudflare workers の制限で、メモリ 128MB、CPU 時間 50ms という制約があり、このためにも Node.js の CPU のメトリクスを計測できるようになっておく必要があった。 という目的を踏まえて、今回は OS やデータベースの最適化は扱わず、ネットワークとアプリケーション層だけに絞って学習した。あと仕事の Docker イメージのサイズにも悩んでたので、ここも。 (あと ISUCON 参加者が楽しそうだったのもある。 ISUCON のチューニング対象にフロントエンドは含まれないので…) 計測対象 今回実験したリポジトリはこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - QwikDev/qwik: Instant-loading web apps, without effort
GitHub - GoogleChrome/web-vitals: Essential metrics for a healthy site.
Web Speed Hackathon Online 出題のねらいと解説
GitHub - sumup-oss/performance-observer: Generic interface for PerformanceObserver API.
