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 https://yourdomain.com curl -I --http3 https://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 1.3 support, but I don’t see HTTP/3 listed as a supported CDN protocol yet: https://vercel.com/docs/cdn-security/encryption So I would not assume HTTP/3 is available just because TLS 1.3 is enabled. This looks more like a platform feature request / roadmap question than something you can enable per project with `next.config.js` or DNS settings.
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% - Enable lazy loading and use `sizes` prop for responsive images - Consider using a CDN for very large image libraries **Build & Deployment Speed** - Leverage Vercel's build cache (enabled by default) - Use Turborepo for monorepos to cache and parallelize builds - Consider enhanced build machines for large projects (up to 70% faster) - Enable Turbopack for faster local development Let us know how you get on!
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 Vercel Speed Insights or Web Vitals to see what is actually slow. The most useful first step is usually to identify the biggest files/dependencies instead of guessing. Once you know whether the problem is large assets, heavy JS, or slow server/data fetching, the fix is much clearer.
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.