アプリケーションソリューショングループの古川です。リクルートの各サイトで実際に運用されているサービスの Core Web Vitals を改善する活動をしていました。 今回はリクルート社内であったいくつかのサービスで Core Web Vitals の改善活動を行ったので、それの結果についていくつか報告します。基本的に改善活動をやってきて見えたこと、それぞれの改善ポイントを紹介できると幸いです。 リクルート内には有名なアプリケーションもこれから作られるような新規のサービスもあわせて、数百個のサービスが存在し、それの一つ一つを問い合わせをベースにパフォーマンス改善をしつつ、個々のサービスのどの場所で指摘がされたのかについて解説します。 ホットペッパービューティーコスメ ホットペッパービューティー TOWNWORK 個人がやったのはアセスメントと方針を打ち出したところで、基本的には、各部署のメ
こんにちは、@kaa_a_zu です。私は、今までいくつかの組織でフロントエンドのパフォーマンス改善に取り組んできました。パフォーマンスが劇的に改善したこともあれば、改善点の洗い出しで終わったこともありました。この記事では、それらの経験に基づいて、どのようにしたらチームがパフォーマンスに意識を向けることができるのか、改善を習慣化できるのかについて基本的なことを紹介させていただきます。少しでも参考になったらありがたいです。また、ご指摘や感想も随時お待ちしております。 ※この記事はWebフロントエンド領域を対象にしています。 なぜパフォーマンス改善をするのか パフォーマンスを改善する目的には、大きく３つあると考えています。 ユーザー体験の質を向上させるため(追記: この動画はパフォーマンスの重要性を説いています) SEO対策のため 将来的にリッチな機能を導入するため(既にTWA化の基準にはパフ
この記事は、現在開催中のイベント「フロントエンド強化月間 - 開発する上で知っておくべき知見を共有しよう」の記事です。 はじめに QiitaではService Workerを使い、リソースをクライアントにキャッシュさせることにより、パフォーマンスの向上、リクエスト数の軽減をしている。 Service Workerでキャッシュを扱うにあたって、いくつかのキャッシュ戦略があるため、それを紹介する。 Service Workerについて Workbox Qiitaでは、Service Workerファイルの生成にWorkboxを使っている。 Workboxは、gatsby-plugin-offline、next-offlineとかにも使われているライブラリで、Googleが開発している。 Service Workerを簡単に書くことができるのがウリ。 プリキャッシュ（事前キャッシュ） Servi
こんにちは。 一休.comの開発基盤を担当しています、akasakas です。 今回は、画像最適化配信サービスであるimgixを宿泊・ レストランサイトに導入して、 画像最適化・サイトスピード改善につなげたお話をしたいと思います。 ここでお話しする内容 サイトスピードという観点での一休が抱えていた課題(の一部) imgixの特徴とそこでできる解決策 imgix導入の効果 imgix導入をする上で大変だったこと これから画像最適化を考える人たちへ まとめと感想 おまけ(与太話) 諸注意 imgixを導入して、画像最適化という面でサイトスピード改善につながりましたが、 サイトスピードという観点で一休が抱えている課題はまだまだあります。 imgixを導入すれば、サイトスピードは万事解決！！！という話ではありませんので、悪しからず。 サイトスピードという観点での一休が抱えていた課題(の一部) 画像
@potato4d が @spring_raining に、 LINE公式アカウントの管理画面開発で行っている webpack のチューニングについて話を聞いてみました。 チューニングの経緯 7月末ごろから久々にLINE公式アカウントの管理画面開発を行っている 開発環境を久しぶりに立ち上げたところ、尋常ではない重さになっていた dev serverの立ち上げに6〜8分ほど ちょうど急ぎではないタイミングだったので、ビルド速度改善を試みた build/dev serverの高速化のためにやったこと esbuild-loaderの導入 https://github.com/privatenumber/esbuild-loader 体感1分ほど短縮。大きな差とは言えなかった thread-loaderの導入 https://webpack.js.org/loaders/thread-loader
原文(投稿日：2020/01/09)へのリンク CSS-in-JSは、コンポーネントロジックをスタイリングにリンクする方法として、一部のコンテキストで人気になった。Aggelos Arvanitakis氏はCSS-in-JSのコストがもはや無視できない場合について開発者に注意を促し、緩和戦略を提供した。 Arvanitakis氏は記事において、CSS-in-JSがもたらす利点があるものの、一部のアプリケーションでパフォーマンス問題を引き起こす可能性があると主張した。Reactに注目すると、2つの人気のあるCSS-in-JSライブラリ(styled-componentsとemotion)があり、Arvanitakis氏は、CSS-in-JSスタイルだけの差のコードを比較した。以下はスタイルなしバージョンである: import React from 'react'; const NormalD
Aggelos Arvanitakis (@AggArvanitakis) is a front-end dev that likes huskies and is afraid of bees. Interested in all things perf... CSS-in-JS is becoming a popular choice for any new front-end app out there, due to the fact that it offers a better API for developers to work with. Don’t get me wrong, I love CSS, but creating a proper CSS architecture is not an easy task. Unfortunately though, besid
この記事ではReactで巨大なリストを効率よく表示するためのライブラリ react-window をご紹介します。 似たようなライブラリに react-virtualized というものがありますが、react-window は同じ作者による新しいライブラリです。 はじめに ナイーブな方法では、長大なリストを表示するにはその長さに比例するだけのレンダリングコストがかかります。ナイーブな方法とは下記のようにコンポーネントのリストを作って表示するだけの方法です。 import React from "react"; import styled from "styled-components"; const Container = styled.section` display: flex; flex-direction: column; `; const RowContainer = styl
こんにちは。フィナンシャル開発センターの鈴木です。LINE証券のフロントエンドを担当しています。この記事は【LINE証券 FrontEnd】シリーズの4番目の記事です。 最近のWeb Vitalsの隆盛を受けて、LINE証券のフロントエンドでもパフォーマンスの改善に取り組み始めました。およそ2週間ほど改善に取り組んだ結果として、開発環境での計測ではLighthouseのperformanceスコアが従来より30点ほど上昇しました。 パフォーマンス改善のためにさまざまな施策を行いましたが、この記事ではその中でも興味深かったものとして、requestIdleCallbackを活用してLazy Loadingされるコンポーネントの読み込みを遅延し、その結果初期レンダリングにかかる時間を約14%削減できた事例をご紹介します。 環境 以前の記事でご紹介したとおり、LINE証券のフロントエンドはTyp
In this post I'll outline 8 image loading optimization techniques to minimize both the bandwidth used for loading images on the web and the CPU usage for image display. I'll present them in the form of an annotated HTML example to make it easy for folks to reproduce the results. Some of these techniques are more established, while others are somewhat novel. Ideally, your favorite mechanism for pub
この記事のソースコード: https://github.com/knjname/2020-09-03_growingtsd TypeScriptプロジェクトのコンパイルが終わらない！ こんにちは型に弱いマンです。 CIでTypeScriptプロジェクトのコンパイルが1時間たっても終わらなかったことはありませんか？ 私は何度かあります。 TypeScript的に行儀の良い(?)フレームワークを使っている方は、おそらくそういう現象に遭うことは少ないと思います。 行儀の悪い(?)フレームワークをハードに使っている方は、こういうことに遭う確率が高いと思います。 具体的にどういうフレームワークかというと、下記のようにコードで動的に型を紡ぎ出す系のフレームワークですね。 （mobx-state-tree なんかが該当します。） export type ItemDefinitions<D = {}> =
const puppeteer = require('puppeteer') async function getPerformanceMetrics(page) { const { metrics } = await page._client.send('Performance.getMetrics') return metrics.reduce((acc, i) => ({ ...acc, [i.name]: i.value }), {}) } async function waitForFMP(page) { let doneMet = null while (true) { const data = await getPerformanceMetrics(page) if (data.FirstMeaningfulPaint !== 0) { doneMet = data brea
Ben Schwarz November 28, 2017 (Updated: October 27, 2020) React was one of the first major front-end frameworks to not only name, but tout its rendering performance. React’s virtual dom is famous for efficiently rendering components—but what happens when those components suddenly don’t feel fast anymore? Where do you look? How do you fix it? In this walk-through, we’ll show how to find and fix slo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
