⌘K
Pauline P. Narvas Hi, @lior539! Currently, Speed Insights does not allow users to selectively collect only specific metrics like INP while ignoring others such as LCP, FID, etc. As far as I understand, when Speed Insights is enabled, it automatically collects data for a range of web vitals, and users are charged based on the total number of data points collected. Thank you for the feedback! I'll share this internally and report back in this thread with any updates.
system Hey @lior539! 👋 Just wanted to follow up here. If you've found a solution or still need help, let us know! We're happy to continue assisting.
Ryu Hi Den, TLS 1.3 and HTTP/3 are related, but they are not the same thing. TLS 1.3 means the HTTPS handshake can use the newer TLS version. HTTP/3 specifically means the site is being served over QUIC/UDP instead of HTTP/1.1 or HTTP/2 over TCP. A quick way to test what your site is actually negotiating is: curl -I --http2 yourdomain.com curl -I --http3 yourdomain.com or in Chrome DevTools: Network tab → right click columns → enable Protocol If you see h2, that is HTTP/2. If HTTP/3 is active, you’d usually see h3. From the current Vercel docs I can find, Vercel explicitly documents TLS 1.2 / TLS
Den.D Hi @ryux1 , thanks fro the reply. You hit the nail on the head. As I mentioned in my post, even though the two things aren't directly connected, I don't understand the logic of supporting only TLS 1.3 and not HTTP/3. This is especially true when even the cheapest shared hosting providers ($10–$20/month) offer HTTP/3 by default. Of course, there's no personal setting for that, being a platform lack... My post was just a rant, hoping that someone in Vercel reads it and acts to solve the gap 🙂
Ryu Hi Den, Yep, fair point. I mostly replied to clarify the TLS 1.3 vs HTTP/3 difference for anyone else reading the thread. I agree there probably isn’t anything to configure at the project level right now. It would be nice to have HTTP/3 support on Vercel too, or at least a clear note in the docs about the current status. Thanks for raising it.
Pauline P. Narvas Hey, @suheb! Feel free to share more details about your project, it'd help us tailor our suggestions, but some ideas to get you started: Bundle Size Optimization Use <@next> /bundle-analyzer to identify large dependencies: ANALYZE=true npm run build Enable optimizePackageImports in next.config.js for icon/utility libraries Implement code splitting and lazy loading for non-critical components Tree-shake unused code and remove unnecessary dependencies Image Optimization Use Next.js <Image> component for automatic optimization Images are served in modern formats (WebP/AVIF) reducing size by 25-35
Ryu A good way to approach this is to separate build/deployment size from runtime loading performance. For deployment/build size: Remove unused dependencies. Check for large assets accidentally included in the repo. Avoid bundling server-only packages into client components. Use dynamic imports for heavy UI/client-only code. Keep generated files, uploads, and local cache folders out of the deployment. For page performance: Use next/image for images. Compress large images before uploading them. Lazy-load below-the-fold components where it makes sense. Check bundle size with a bundle analyzer. Use V
