Guess.js: Analytics-driven prefetching for webpack builds

The manual prefetch list Guess.js replaces

The README frames the problem in terms of developer habit. Teams that use <link rel=prefetch> for future navigations, it says, "heavily rely on manually reading descriptive analytics to inform their decisions for what to prefetch." That list is written once and rarely revisited as traffic patterns move. It also tends to cover only a homepage or a small set of hero pages, which leaves the other entry points on a site with no prefetching at all. The third concern the README raises is confidence: developers avoid prefetching because they are not sure the bandwidth is well spent. Guess.js is for the team that already accepts prefetching as a technique but does not want to maintain the URL list by hand, and is willing to let Google Analytics session data decide. It assumes a webpack build and a GA property with enough traffic to produce stable page-to-page transition counts. The repository labels itself alpha, and no releases were retrieved, so the intended audience is early adopters rather than teams looking for a frozen API.

Three packages and the data path between them

The repository splits into three packages under packages/. guess-ga fetches structured data from the Google Analytics API to learn user navigation patterns. guess-parser provides JavaScript framework parsing and powers the route-parsing capabilities used by the webpack plugin. guess-webpack consumes both and exposes options for configuring predictive fetching. The data flow implied by that split is: parse the application's route definitions to learn which URLs exist, pull transition data from GA to learn which page pairs are common, then have the plugin emit prefetch instructions for the highest-probability neighbours of the current page. The README describes the bundle-level behaviour precisely: on each navigation, look at all neighbours of the current page sorted in descending order by probability of being visited, and fetch JavaScript chunks for the top N pages, where N depends on the current connection effective type. That last clause is the interesting design decision. The number of chunks fetched is not a fixed constant but a function of the network the visitor is on, which is the mechanism that answers the wasted-bandwidth objection. For non-webpack users there is a separate path: a client-side script sends a request to a server, receives the URL it should fetch, and prefetches that resource.

Installing GuessPlugin and what the GA side requires

For webpack users the README points to GuessPlugin in packages/guess-webpack as the entry point, described as automating as much of the setup process as possible. The plugin is what you add to your webpack configuration; it pulls in ga and parser rather than requiring you to wire them yourself. The README does not print a full configuration block, so the exact option names are not recoverable from the material here. What is stated is that the plugin "offers a large number of options for configuring how predictive fetching should work in your application," which is a warning as much as a feature: expect to read the package README rather than copy a snippet. The non-webpack workflow lives in experiments/guess-static-sites and is described as a set of steps to follow, with a client-side script you add to your application that requests a URL from your server and prefetches it. Both paths depend on the same upstream input, the Google Analytics Reporting API. The README notes that most developers are unfamiliar with using that API to determine the probability a page will be visited next, which is the gap guess-ga exists to close. Authentication against the GA API is therefore a prerequisite you should confirm before evaluating anything else.

Where the prediction is only as good as the route parser

guess-parser is the component most likely to decide whether Guess.js works for you, and the README gives it one sentence: it provides JavaScript framework parsing and powers route parsing in the webpack plugin. That is thin. Route definitions in real applications are frequently assembled from generated files, computed strings, or configuration loaded at runtime, and a parser that reads source statically will miss those. If it misses a route, that page never appears as a neighbour in the prediction graph, so it never gets prefetched no matter how much traffic it receives. The failure is silent: the build succeeds, the plugin runs, and some pages simply are not covered. The second dependency is data volume. Page-to-page probabilities come from Google Analytics, so low-traffic routes produce noisy or empty transition counts, and a site with most of its sessions concentrated on a handful of landing pages will get predictions for those pages and little else. The README itself lists the assumption that developers have confidence in the data being used to drive prefetch decisions. If your traffic does not support that confidence, the plugin is generating prefetches from noise. Guess.js is the wrong tool here, and a static prefetch list for your five most common navigation pairs would be cheaper and more predictable.

How this differs from a hand-written prefetch or a service worker

The obvious alternative is the manual approach the README describes as the status quo: inspect your analytics dashboard, pick the page pairs that matter, and write <link rel=prefetch> tags or a small client-side script. The difference is where the decision lives. A hand-written list is a snapshot taken at one point in time, and the README calls out that such decisions are "often not revisited as data trends change." Guess.js moves the decision into the build, where it is recomputed from fresh GA data each time the plugin runs, and into runtime, where the number of chunks fetched adapts to the visitor's connection. The trade is control for automation. With a manual list you know exactly which bytes are requested and when; with Guess.js you are trusting an API response and a route parser. A service worker with a fixed precache manifest is a third approach that shares none of these properties: it is deterministic, works offline, and makes no predictions at all. If your goal is offline capability rather than faster next-navigation, Guess.js does not address it. The README also points at Google Tag Manager as a way to decouple tracking code from page content and deploy intelligent prefetching without site downtime, which is a deployment argument rather than a modelling one.

Licence, maintenance and the alpha label

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive default and imposes no copyleft obligation on your application. It says nothing about the Google Analytics API terms you accept separately by pulling data through guess-ga, and nothing about what happens to predicted prefetch behaviour if GA sampling or quota limits reduce the data volume the plugin sees. On maintenance: no releases were retrieved for this repository, the README carries an alpha marker in its own heading, and the last push recorded is 2026-09-09. The build status badge points at Travis CI. Treat the API surface as unstable until you have checked the package READMEs at the commit you intend to use. The upgrade cost is concentrated in guess-webpack's option set, which the README describes as large; a change to those options is a change to your webpack config. Because the plugin's inputs are a live GA property and your route definitions, a rebuild after a routing refactor is not a no-op. Expect to re-verify coverage whenever routes change shape.

Editorial conclusion

Adopt Guess.js if you ship a webpack app with meaningful traffic in Google Analytics and a route structure the parser already supports; skip it if you have no GA property, no webpack build, or a site whose routes are generated at runtime in ways the parser cannot read. Before committing, verify three things: that the parser can resolve your framework's route definitions, that the GA Reporting API returns enough sessions per page pair for the probabilities to mean anything, and that GuessPlugin's prefetch behaviour on your slowest connection profile does not compete with the assets the current page still needs.

Official sources

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