Guess.js: Using Google Analytics Navigation Data to Prefetch Pages Before Users Click

The Problem: Static Prefetch Decisions Do Not Age Well

The standard mechanism for hinting that the browser should prefetch a resource is the `<link rel=prefetch>` tag. It instructs the browser to download a resource in the background so that when the user navigates to it, the resource is already in cache.

The README identifies the practical problem with this approach: 'Developers using <link rel=prefetch> for future navigations heavily rely on manually reading descriptive analytics to inform their decisions for what to prefetch.' These decisions 'are often made at a point in time and (1) are often not revisited as data trends change (2) are very limited in how they are used.'

A homepage that once led visitors predominantly to a pricing page might see that pattern shift as a product evolves. A manually placed prefetch hint that reflects six-month-old analytics data is no longer optimally targeted. The developer must remember to revisit it, and most do not.

The README also notes a confidence problem: 'Require some amount of confidence about the data being used to drive decisions around using prefetching means that developers may not be adopting it out of worry they will waste bandwidth.'

Guess.js addresses this by automating the analysis. Instead of a developer manually reading Google Analytics, the library reads the Analytics API, computes per-page navigation probabilities, and configures prefetching accordingly. When navigation patterns change, regenerating the configuration with fresh Analytics data produces updated prefetch decisions without manual intervention.

How Guess.js Computes Navigation Probabilities

Guess.js uses the Google Analytics Reporting API to fetch historical navigation data for a site. This data shows which pages users visited immediately after each given page, and how often. From these transition counts, the library computes a probability: given that a user is currently on page A, what is the probability they will navigate to page B next?

The README describes the application at multiple granularities. At the page level: 'Prerender/Prefetch the page which is most likely to be visited next.' At the bundle level: 'Prefetch the bundles associated with the top N pages. On each page navigation, at all the neighbors of the current page, sorted in descending order by the probability to be visited. Fetch assets (JavaScript chunks) for the top N pages, depending on the current connection effective type.'

The connection effective type reference is significant. Rather than prefetching aggressively on slow connections, Guess.js adjusts the number of pages to prefetch based on network conditions. On a fast connection it can prefetch more aggressively; on a slow connection it reduces the prefetch count to avoid wasting the user's bandwidth.

The data source is historical. Guess.js cannot predict the behavior of a new user on a page that has never been visited, and it cannot react in real time to session-specific context. It applies population-level statistics from past sessions to the current user's present session.

The Three Packages and Repository Layout

The repository is a monorepo managed with Lerna. The packages/ directory contains three packages: guess-ga, guess-parser, and guess-webpack.

guess-ga fetches structured data from the Google Analytics API. It handles authentication and the query structure needed to extract page transition data. This package is the data layer.

guess-parser provides JavaScript framework parsing. It powers the route-parsing capability in the webpack plugin, identifying the routes defined in a JavaScript application so they can be matched to Analytics data.

guess-webpack is the primary integration point for most users. The README describes it as 'a webpack plugin for setting up predictive fetching in your application. It consumes the ga and parser modules and offers a large number of options for configuring how predictive fetching should work.'

For non-webpack users, the README points to experiments/guess-static-sites. The experiments/ directory is separate from packages/ and represents less polished workflows. A static site without a webpack build pipeline must follow a more manual integration path through this directory.

The infra/ directory contains tooling for end-to-end testing and build automation. The jest-puppeteer.config.js and jest.config.js at the root suggest that E2E tests run with Puppeteer. The renovate.json at the root enables automated dependency update pull requests.

The lerna.json and the root package.json bootstrap command (npm i && lerna bootstrap) reflect the monorepo structure. Each package in packages/ has its own build output and can be used independently of the others.

Setting Up Guess.js with GuessPlugin

The README describes GuessPlugin as the integration path for webpack users and refers to it as automating 'as much of the setup process for you as possible.' The GuessPlugin is in the packages/guess-webpack directory.

Setup requires a Google Analytics account with data for the site being optimized. The ga module handles the API authentication step. Without historical navigation data in Google Analytics, there is no probability model to generate, and the prefetching will not have meaningful targets.

The README does not include step-by-step code in the visible portion of the documentation. It links to the GuessPlugin directory in the packages/ folder and to the experiments/guess-static-sites directory for non-webpack sites. The detailed configuration options are documented within those packages rather than in the top-level README.

The development setup for contributors involves running the bootstrap script (the root package.json shows 'bootstrap': 'npm i && lerna bootstrap'), followed by the build step ('build': 'lerna run build'). End-to-end tests run through the ts-node infra/e2e.ts script. The repository uses TypeScript throughout, with a tsconfig.json at the root and tslint.json for style enforcement.

The package.json lists googleapis version 67.x as a direct dependency, which is the client library for the Google Analytics API. The flat-cache package is used for caching Analytics responses between builds so repeated prefetch configuration generation does not re-query the Analytics API each time.

Alpha Status and Real Limitations

The README labels Guess.js as alpha: 'Guess.js (alpha).' The repository has no GitHub releases. The last push was on 2026-09-15. The combination of no releases and an explicit alpha label means teams should treat this as experimental infrastructure, not a dependency with a stable API contract.

The approach has inherent limitations. It requires Google Analytics data, which means it does not work for new sites without traffic history. It also does not work for sites that have switched analytics platforms away from Google Analytics, or for sites with privacy settings that block analytics collection in significant user segments.

Predictive prefetching based on population-level statistics optimizes for the average visitor's behavior. It does not adapt to individual session context, such as a user who is browsing a particular category of content and is more likely to navigate within that category. The population-level model will still predict based on all visitors' aggregate behavior.

Bandwidth usage is also a genuine concern for heavy prefetching. Prefetching pages that a user never visits wastes their data, which is particularly problematic on metered mobile connections. The connection effective type adjustment mitigates this, but the probability threshold for what counts as 'likely enough to prefetch' is a configuration decision the developer must make carefully.

The webpack plugin integration also means Guess.js is not suitable for sites that do not use webpack. The experiments/guess-static-sites path exists but the README describes it as a 'set of steps you can follow' rather than a polished automated workflow.

Comparison with Manual Link Prefetching and Related Tools

The most direct alternative to Guess.js is the `<link rel=prefetch>` tag placed manually in page templates based on human judgment. This requires no Google Analytics dependency, no build tool plugin, and no JavaScript library. The limitation is exactly what Guess.js targets: the decisions are static, manually maintained, and reflect stale data.

A middle-ground approach is to generate the prefetch hints programmatically from a custom script that reads Google Analytics and inserts `<link rel=prefetch>` tags at build time, without using the Guess.js packages. This gives similar optimization without taking on a dependency on an alpha library.

The README references work by IIH Nordic as an example of intelligent prefetching through Google Tag Manager, demonstrating that the general approach predates Guess.js as a library. That example shows the same principle implemented through a different toolchain, which is relevant context when evaluating whether to take on the Guess.js dependency specifically.

For teams already using a CDN with prefetch or preload capabilities at the network layer, or a server-side framework that supports speculative loading based on server-side analytics, Guess.js's client-side webpack approach may duplicate what already exists in the infrastructure layer.

Repository Maintenance and MIT License

The last push to the guess-js/guess repository was on 2026-09-15. There are no GitHub releases. The version number in the root package.json is 0.0.0, which is typical for Lerna monorepo roots where individual package versions are maintained in their own package.json files within packages/.

The TypeScript devDependencies in the root package.json pin a range of versions: typescript at 4.5.4, ts-node at 8.8.2, jest at 26.6.3, webpack at 4.46.0. The webpack 4 dependency is notable: webpack 4 has been succeeded by webpack 5. Teams using webpack 5 may encounter compatibility issues with the current package, though the repository activity on 2026-09-15 suggests the maintainers are still active.

The .travis.yml at the root indicates CI was historically run through Travis CI. The renovate.json at the root enables automated dependency update pull requests.

The license is MIT. Use in commercial projects, modification, and redistribution are permitted. No contributor license agreement is documented in the repository.

For teams considering adoption: the alpha label and zero-dot version number are accurate signals of stability. The approach is sound and the webpack integration is the most complete path, but anyone adopting it should be prepared to pin a specific commit and manage upstream changes manually.

Editorial conclusion

Frontend teams using webpack who have Google Analytics data and want to reduce perceived navigation latency should try GuessPlugin. Teams without a Google Analytics account, or those not using webpack, have limited integration paths since the non-webpack path requires following a manual workflow in the experiments/ directory. The alpha label in the README is not decorative: the repository has no tagged releases, and teams adopting it should treat it as experimental infrastructure rather than production-grade tooling.

Frequently asked questions

Official sources

1. guess-js/guess on GitHub
2. Issues
3. License: MIT
4. Project website
5. README