First, measure the cost
Before changing anything, look at how the app currently performs. The sample application uses Firebase's Realtime Database to track kitten votes in real time, and Moment.js to calculate each kitten's age. Open DevTools, go to the Network panel, enable Disable cache, and reload.

The app is shipping nearly 1 MB of JavaScript. A closer look at the Console tab reveals a warning from Firebase itself:

The library is telling us not to import its entire package, only the services actually used. That is the first clear target. But before editing anything, use a bundle analyzer to see exactly where the weight comes from.
See the bundle with an analyzer
The project already includes webpack-bundle-analyzer as a devDependency. Import BundleAnalyzerPlugin at the top of webpack.config.js and add it as the last entry in the plugins array:
const path = require("path");
//...
const BundleAnalyzerPlugin = require("webpack-bundle-analyzer")
.BundleAnalyzerPlugin;
module.exports = {
//...
plugins: [
//...
new BundleAnalyzerPlugin()
]
};
On reload, you get a visual breakdown of every package in the bundle.

Two libraries—Firebase and Moment.js—account for almost all of the payload. But that does not mean both are needed at full size.
Drop unused Firebase services
The analyzer shows that the firebase package drags in firestore, auth, storage, messaging, and functions. None of those services are used here; the app only talks to the Realtime Database.
Revert the analyzer changes in webpack.config.js, then edit the imports in src/index.js to pull in only the database service:
import firebase from 'firebase';
import firebase from 'firebase/app';
import 'firebase/database';
After reloading, the warning is gone and the network payload is much smaller:

Cutting unused services removed more than half of the original bundle. The firebase/app import stays—it sets up the shared API surface—but each service can now be imported on its own. Many other libraries, such as lodash, offer the same selective-import pattern.
Remove Moment.js entirely
With Firebase trimmed, the remaining large dependency is Moment.js. Unlike Firebase, Moment.js does not support granular imports. The question becomes whether it is needed at all.
Each kitten's birth date is stored as a Unix timestamp in milliseconds. To compute age in weeks, the difference between now and that timestamp simply needs to be divided by the number of milliseconds in a week. First, remove moment from the imports in src/index.js:
import firebase from 'firebase/app';
import 'firebase/database';
import * as moment from 'moment';
Then add a small helper above the Firebase event listener that handles value changes:
const ageInWeeks = birthDate => {
const WEEK_IN_MILLISECONDS = 1000 * 60 * 60 * 24 * 7;
const diff = Math.abs((new Date).getTime() - birthDate);
return Math.floor(diff / WEEK_IN_MILLISECONDS);
}
Finally, replace every moment call in the event listener with this function:
favoritesRef.on("value", (snapshot) => {
const { kitties, favorites, names, birthDates } = snapshot.val();
favoritesScores = favorites;
kittiesList.innerHTML = kitties.map((kittiePic, index) => {
const birthday = moment(birthDates[index]);
return `
<li>
<img src=${kittiePic} onclick="favKittie(${index})">
<div class="extra">
<div class="details">
<p class="name">${names[index]}</p>
<p class="age">${moment().diff(birthday, 'weeks')} weeks old</p>
<p class="age">${ageInWeeks(birthDates[index])} weeks old</p>
</div>
<p class="score">${favorites[index]} ❤</p>
</div>
</li>
`})
});
The app's behavior is unchanged, but the payload shrinks again. The second network panel shows the result:

Know the tradeoff
Removing unused libraries can be done almost mechanically: find what the analyzer says is in the bundle, check what top-level dependencies actually need it, and prune the rest. Removing unneeded libraries is a design decision. Replacing Moment.js with a hand-rolled date calculation works here because the app only needs weeks since a fixed timestamp. Real-world date handling with time zones, locales, and irregular calendar rules is exactly the kind of problem where a dedicated library earns its place. Weigh whether the complexity of a custom solution is worth the bytes saved against the risk of subtle date bugs.



