Yes, if rendering pixels is the bottleneck. A canvas rendered at pixel ratio 3 contains nine times as many pixels as the same CSS-sized canvas at ratio 1. Lowering the drawing-buffer resolution can reduce that work. It will not directly fix slow JavaScript, excessive draw calls or large downloads. The Three.js responsive rendering guide explains why native phone resolution can be expensive.
Try a controlled comparison
For a simple WebGLRenderer scene with a perspective camera, compare the same camera and scene on the same phone using a lower ratio. This example uses 1.5 as an experimental ceiling; it is not a universal quality setting. Call the function after the canvas receives its layout size and when that size changes.
function resize() {
const canvas = renderer.domElement
const width = canvas.clientWidth
const height = canvas.clientHeight
if (!width || !height) return
renderer.setPixelRatio(Math.min(window.devicePixelRatio || 1, 1.5))
renderer.setSize(width, height, false)
camera.aspect = width / height
camera.updateProjectionMatrix()
}
The canvas needs an explicit CSS display size. setSize(..., false) changes its drawing buffer without overwriting that CSS size; the renderer applies its pixel ratio internally. Keep the camera aspect tied to the displayed dimensions. See the WebGLRenderer API. If you use a postprocessing composer or custom render targets, update their sizes through their own APIs too. For exact control of shader and picking coordinates, the manual’s explicit drawing-buffer sizing approach is preferable.
Decide from measurements
Compare steady frame times after loading and shader compilation, then inspect text and edges for lost clarity. Keep other settings unchanged. If lowering resolution barely helps, investigate CPU work, scene complexity and loading separately. Test on an actual phone; a desktop viewport alone does not reproduce its GPU or heat limits.
Read how this portfolio budgets rendering work, or explore 3D and WebGL development for a project that needs a measured mobile experience.