A lot of the web game questions that land on here come down to picking a library before working out what kind of problem you actually have. This one catches people often enough that it is worth writing down for anyone about to start a browser game.
PixiJS does exactly one job: it draws 2D to a canvas, through WebGL, WebGPU, or Canvas 2D as a fallback, and it does that faster than almost anything else on the web. It manages a scene graph of display objects, sprites, text, graphics primitives and containers in a parent and child hierarchy, and renders that whole tree every frame.
What it does not ship is everything a framework bundles around a renderer. No physics engine, no scene manager in the game sense, no input abstraction, no audio system, no asset pipeline past texture loading, no editor. Those are not gaps. They are the reason it is fast.
The v8 trap
v8 was a rewrite rather than a version bump. The renderer was restructured, WebGPU became a first class backend alongside WebGL, and a fair amount of the older API surface moved. The practical effect is that much of the PixiJS material online is now quietly wrong. Guides written against v6 or v7 read correct and then fail in ways that look like your mistake rather than a version mismatch. Check the target version on anything you follow, before you follow it.
Optimization in Pixi almost always reduces to two things: how many draw calls you are issuing, and whether your textures live in atlases so they can batch. Objects sharing a texture batch into a single call. The library is fast by default and the ways to make it slow are specific and learnable.
The actual decision
Reach for PixiJS when rendering is the hard part and structure is not. A card game, a board game, a large 2D map, a data heavy interactive. Reach for a full framework like Phaser when you need physics, scenes, input and audio and would rather not assemble them yourself. Phaser used Pixi internally for years, so this is less a rivalry than a question of where you want the boundary between what you are handed and what you build.
The longer version is in this full guide to PixiJS game development, which covers the v8 architecture, the scene graph, animation and input, filters and shaders, the optimization work, and the comparison against full frameworks.
If you can describe your game as a rendering problem, use the renderer. If you cannot, use the framework.