Git 2.38がリリースされました。 このバージョンから大規模Gitリポジトリの操作を高速化するscalarが同梱されるようになりました。 今回はこのscalarによって、どれぐらいGitの操作が高速化されるのかを簡単に検証します。 結論から言うとgit statusが約43秒かかっていたのが約1秒で操作できるようになります。 Install Git 2.38 Git 2.38からscalarが同梱されましたので、各自の環境にあわせてInstallなりVersionUpなりをしてください。 $ git --version git version 2.38.0 Before 大規模Gitリポジトリとしてchromiumを利用しました。 普通にgit cloneしてきて、git statusを実施すると約37秒かかります。 ❯ time git status On branch main Y

前提 本記事は保守性の高いReact hooksコードの指針を記述します。指針はtipsに近いものから原則に近いものまで雑多に含まれます。総じてReact hooksの標準的なAPIを上手く扱う方法が多めです。 これらは保守性の低いコードを反面教師とした私的な経験則に基づきます。（思い出し次第随時追加していきます） ご留意ください。 解消したい痛み 再現が困難な不具合の発生 容易に無限ループが発生しうる 不具合発生箇所の特定が手間 分岐が多くコードリーディングに手間がかかる 解消する手法 useEffectは１ページに１つ useEffectにdeps自動補完除外コメントを入れる stateはプリミティブにする propsにフラグがある場合はコンポーネントを分ける useEffectは１ページに１つ 悪例: ユーザーイベントの処理 const [foo, setFoo] = useStat

今回は最近取り組んでいる、 JavaScript が読み込まれる前であっても「ちゃんと」 Web Application が動作するように作る話をします。 Server Side Rendering における注意点と対策 BFFを使ってServer Side Rendering をすることに数年前から取り組んでいます。 まずはSSRをやる上での注意点と対策について紹介します。 SSRをすることはSEOのためだと思われがちですが、個人的にはSEOのためにしているわけではなく、 First View を向上するため（特に First Meaningful Paint を向上するため）にやっています。 First View SEOとSSRに関しては Google が最近出したこの記事の SEO Considerations 節が詳しいです。ここでは説明しません。 SSRをしない、Client S

next.jsのISRを使おうとして「なんか全然うまく行かない」ってなってたのがやっと理解出来たのでメモ 問題編 とりあえず見様見真似でISRはrevalidateとfallbackつければ良いんだな？とやってみたところ、どうもpropsが空Objectになってしまうようで悩んでいた。 例えば下記のような場合、エラーが起きる // pages/greeting/[name].js const Page = (props) => { // ↓ここでエラー return <div>Hello {props.name.toUpperCase()}</div> } export const getStaticProps = async (req) => { return { props: { name: req.params.name }, revalidate: 100 } } export c

Preload web fonts 前回、といっても2年前だが、display=swapとはなにかで、Google Fontsを読み込むときはURLパラメータに display=swap をつけるといいよと言った。というわけで、それ以降、『目標をセンターに入れて、display=swap…』と盲目的に考えるようになってた。 おさらいとして display=swap では、まず代替フォントを表示し、Webフォントをダウンロードしたら、随時スワップするという挙動になる。この場合、代替フォントからWebフォントへ切り替わる FOUT (flash of unstyled text) が起こってしまう。こんな感じ↓ 出典：font-face descriptor playground まぁ何も表示されないよりかは良いかと思うわけだが、時は流れ、最近ではWebの指標として、Web Vitalsという

ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。Yahoo!ニュースを担当しているエンジニアの喜楽です。 2020年5月、GoogleよりWebでのユーザー体験を指標化したCore Web Vitalsが発表されました。本記事では、Yahoo!ニュースにおけるCore Web Vitals指標改善の取り組みとその効果についてご紹介します。 Core Web Vitalsとは Webページを閲覧しているときに、コンテンツの表示が遅かったり、スクロールやクリックなどの反応が悪い、レイアウトが読込中に変更され、クリックしたい要素の位置がずれてしまうなどといった経験はないでしょうか。これらはユーザー体験を低下させる一因となります。Core Web Vitalsは上記のような

最近Next.jsがめでたくv10がリリースされたこともあってNext.jsの名前を聞く機会は増えていると思います。 Next.jsの特徴で調べると「SSG+SSRが出来るフルスタックなフレームワーク」として出てきますが、そのことによってGatsby.jsは打倒されるのではないかという疑問をよく目にするようになっていると思います。 私個人の意見として、現状Next.jsがGatsby.jsを完全に置き換えられるかという問いに対してノーと言えます。 その理由は、各フレームワークがSSGを実現するその仕組みについてを知り強み弱みを理解することで納得できるものとなるでしょう。 各フレームワークによるSSGの実行プロセス 例えば、あなたがブログサービスを作りたいとして以下の要件を決めた場合、Next.jsとGatsby.jsでSSG面に関して実装の差を見比べましょう。 - url形式は /blog

React hooks にはメモ化のための useCallback と useMemo という関数があります。 hooks を使い始めて、この二つの関数を知った私はこう思いました。 「え？無条件でパフォーマンス上がるんなら全部これで書くべきやん！」 と。 というわけで、しばらくそのスタンスで書いてきたのですが、果たしてこの「無条件でパフォーマンスが上がる」という前提は本当に正しいのか、というかそもそも"パフォーマンス上がる"とは具体的に何をしてくれるのかを理解せずに使っていたので、ここで「全て useCallback/useMemo で書く」という方針が正しいのか、それとも他の方針が存在するかを考えてみました。 大きく次の3つの観点で考えます。 パフォーマンス 可読性 バグの発生しやすさ 1.パフォーマンス 「そもそも useCallback/useMemo はパフォーマンス向上の用途なの

Web Platform Dive into the web platform, at your pace.

TOP > PageSpeed Insightsのスコア大変動か？ Lighthouse 6 で変わる採点ルールを先取りチェック！ PageSpeed Insightsのスコア大変動か？ Lighthouse 6 で変わる採点ルールを先取りチェック！ Core Web Vitals Lighthouse PageSpeed Insights SEO 2020年3月現在、PageSpeed Insightsの内部ではLighthouse 5.6が使われていますが、Lighthouseの次期バージョン6で採点ロジックが変わる予定があります。 ※ 本記事は Lighthouse 6.0-beta.0 に基づいて執筆しています。将来的なリリースとは異なる可能性があります。 Lighthouse performance scoring あれ、なんか変じゃない？ と思った方は鋭い！ Lighthous

近年の Node.js は API のサーバとしてはもちろん、Nuxt.js や Next.js といった SSR や BFF などフロントエンドのためのバックエンド言語としての人気が高まっています。 フロントエンドエンジニアがコンテキストスイッチ少なくバックエンドの整備ができることは非常に大きな利点です。 ですが、フロントエンド（ブラウザ側）とバックエンド（サーバ側）ではパフォーマンスチューニングで見るべき点が大きく違います。 しかし Node.js アプリケーションのパフォーマンスイシューの見つけ方などがまとまっている資料は少ないです。 そこで、本記事ではフロントエンドエンジニアが Node.js でパフォーマンスイシューを見つけ、改善するため自分が普段パフォーマンスチューニングを依頼されているときにみている基礎的なポイトをまとめていきます。 1. 計測ステップlink Node.js

ターゲット 巨大なSPAを作ってしまった人へ 巨大なSPAを作らないように気をつけたい人へ 今回はJSだけにフォーカスするが、もっというと、 超速本 を読んでください。 注意：本資料は、webpack チャンクの挙動を概念的に説明することを重視しているので、 webpack の詳細な設定や、出力ファイル名などは実際の処理と一致しない。適宜自分の手元にある設定とすり合わせるように。 昨今のJSビルド問題と、その解決のためのゴール設定 巨大なJS(+最近は in JS された各種SVGやCSS)はダウンロードだけではなく、UIスレッドのCPUをブロックする。 これはとくにCPUが貧弱な端末で体験が悪化する。そしてビルド時間で開発者体験を阻害する。 できれば webpack 推奨の 144kb 以内にしたい…が現実的に難しいので、 せめて 350kb ぐらいに抑えたい。 SPAなら (ローディン

はじめまして！HRBrainでフロントエンドエンジニアをしている鈴木(@suzuesa)です さて、早いものでHooksがリリースされて2ヶ月が経とうとしています みなさんHooksを使いこなせてますか？私はまだまだ使いこなせません… 今回はその新しいHooksの機能をパフォーマンスチューニングの話と絡めてご紹介したいと思います 前提 これまでのチューニング方法 ClassComponent FunctionComponent Hooks以降のチューニング useMemo memo() + useCallback() 実践 前提 パフォーマンスチューニングと言っても、どうしてReactが遅くなるのか、何処を改善すれば速くなるのかを知っておく必要があります qiita.com 上の記事にすごい詳しく書いてあるので、そちらを見てからこの記事を読むともっと理解度が深まるかもしれません 簡潔に言え

はじめに 『レンダリングの仕組みなんて知らなくても、ブラウザが勝手にやってくれるじゃん！』 当時駆け出しのエンジニアだった私はそう思っていました。 実際、当時の私はレンダリングの『レ』の字も知りませんでしたが、特に業務上で問題はありませんでした。 しかし、その時は突然訪れました。 クライアントの要望でアニメーションを多彩に取り入れた案件を実装した際に、テスト段階で一部ブラウザ（S○f○ri、E○ge）でアニメーションがひどい状況になっていることが発覚しました。 (開発中はChromeで確認を行っており、Chromeでは特に問題はなかったので発覚が遅れました。) それからは、狂ったようにパフォーマンスの改善方法をググり、修正する日々が続きました。（最終的には、なんとかマルチブラウザでの動作も担保し、納品まで完了しました。） その案件が落ち着いた後、改めて自分の調べたことを振り返ると、局所的な

表題のような問題があり，その調査したという記録です．なお，結論を一言で言うと--initを使え，ということになります． そもそもDockerコンテナを起動すると，CMDあるいはENTRYPOINTに指定されたコマンドがコンテナ内でPID 1として起動します．これが何を意味するかと言うと，「CMDあるいはENTRYPOINTに指定されたコマンド」はそのコマンド自体の責務をまっとうするのと同時に，initプロセスとしての振る舞いも行わなければならないということになります (id:hayajo_77さんにこの辺を詳しく教えてもらいました，ありがとうございます)． つまりPID 1で動いているプロセスは「SIGCHLDをトラップすることで孤児プロセスを適切に回収し，waitpidをかける」という処理も適切に行う必要があります． さて，puppeteerを使ってChromeブラウザを起動するとどうな

Intro このサイトのフォントに Web Font を適用することにした。 フォントには Google と Adobe が協同で開発した Noto Sans CJK JP を採用した。 また、このサイトでは使用しないだろう文字を削除したサブセットを作ることで、フォントサイズを最適化した。 フォントサイズの最適化 Noto font は、そもそも豆腐(フォントがなかった場合に代替表示される四角)が出ないように(No-豆腐)することをコンセプトにしているため、フォントの網羅率は非常に高い。 そのため Web Font として利用する場合は、全体だとサイズが大きすぎるため、言語毎に提供されるフォントセットの中から、必要なフォントのみを適用することになる。 本サイトでは、 ASCII 、記号、日本語のフォントを用いる。 しかし、特に網羅された漢字の中には、日常では使わない文字が多々ある。 加えて

はい、遅れてしまいましたorz この記事はNext.js Advent Calendar 2018の 20 日目です。 きっかけ 知り合いからサイト構築してよー的な事を言われ、作るときのベースとなる環境欲しいなと思ったのがきっかけです。 HTML/CSS/JavaScriptを普通に書いていってもよかったんですが、普段使ってて手慣れたReactで作っていきたいなと思い、Next.jsのexport modet使えば良いんでね？という感じで作りました。 また、せっかくならlighthouseにもこだわりたいなと思い、workboxも導入しています。 作ったもの こちらになります。 作る際に参考にさせていただいたものとほぼ同じ（パクり）じゃんってツッコミは勘弁してくださいorz まとめ Github Pagesでホスティングしてみたところ、環境によっては下記のような結果が出ました。 （Hell

なぜやるか 普通にやってても満点は難しい。まずは無で100点を目指す。 Google が Mobile First Index やりだしたら多分 lighthouse のスコアも使うだろうという予想 next.js というある程度現実的なフレームワークを使うことで適度に YakShaving もこなせるだろうという予想 使ったもの next.js: export mode workbox 結果 コード https://github.com/mizchi/next-pwa-boilerplate デプロイ先(netlify) https://eloquent-spence-e8f2bb.netlify.com/ PWA 91点は、 netlify 使っている制限で、HTTP to HTTPS のリダイレクトを設定するにはカスタムドメインを設定する必要があり、金を払いたくないので諦めた。設定す