remix-use-spa-metrics
v0.2.0
Published
Custom hook for tracking client-side navigation performance in Remix/React-Router applications
Downloads
5
Maintainers
Readme
remix-use-spa-metrics
Custom hook for tracking client-side navigation performance in Remix/React-Router applications
Motivation
The current performance landscape focuses primarily on SSR metrics, but largely ignores any standardized set of metrics for subsequent SPA navigations. This is understandable since the approach used for SPA navigations varies so much from app to tpp that it would likely be incredibly hard to come up with a on-size-fits-all set of metrics.
However, if you're building a universal app that SSR's and then hydrates into a SPA - that SSR page load may only account for a small percentage of your users page load sin their session. shouldn't we be looking at the stats for pages 2 through N?
This custom hook aims to facilitate your own standardized set of measurements for your Remix/React-Router (>=6.4.0) by leveraging the useNavigation
(useTransition
in Remix) hook which tells you when your application is performing a SPA navigation between pages.
You can then send the data off to whatever performance tracking setup you use. In a former life, I did this through Blue Tringle Custom Timers.
Installation
npm install remix-use-spa-metrics
# or
yarn add remix-use-spa-metrics
Usage
The best way to leverage this is to put a single root layout wrapper around your entire application, and then wire up the hook a single time in the root:
import { useSpaMetrics } from "remix-use-spa-metrics";
function RootLayout() {
let location = useLocation();
let navigation = useNavigation();
let callback = React.useCallback((data) => {
// This function is called once at the end of each navigation
}, []);
useSpaMetrics(location, navigation, callback);
...
}
Then, you can use the callback function to send the data off to your
performance tracking service. The data
parameter is of the following shape:
interface CallbackData {
type: "submitting" | "loading";
fromLocation: Location;
toLocation: Location;
finalLocation: Location;
submissionDuration?: number;
loadingDuration: number;
totalDuration: number;
}
On standard <Link>
loading navigations, you'll get an approximately equal loadingDuration
and totalDuration
. Non-GET <Form>
submissions will provide a submissionDuration
and a loadingDuration
that will sum up to totalDuration
fromLocation
and toLocation
provide the useLocation()
and useNavigation().location
values from the start of the navigation. finalLocation
reflects the final useLocation()
whn we returned to an idle
state since we may have redirected a few times while in the loading
state.
Eventually, this hook may provide more granular detail about encountered redirects and subsequent load times but for now we view "navigations" from the user's eyes - as a single duration from the moment they click a Link or submit a Form until they are viewing the resulting page.
window.performance.mark
and window.performance.measure
Under the hood, this is all implemented using the window.performance.mark
and window.performance.measure
APIs, so you automatically get the built-in dev tools functionality there, such as showing the measurements in the Profiler and access to your individual marks via window.performance.getEntries*
: