跳转到主要内容

标签(标签)

资源精选(342) Go开发(108) Go语言(103) Go(99) angular(82) LLM(78) 大语言模型(63) 人工智能(53) 前端开发(50) LangChain(43) golang(43) 机器学习(39) Go工程师(38) Go程序员(38) Go开发者(36) React(33) Go基础(29) Python(24) Vue(22) Web开发(20) Web技术(19) 精选资源(19) 深度学习(19) Java(18) ChatGTP(17) Cookie(16) android(16) 前端框架(13) JavaScript(13) Next.js(12) 安卓(11) 聊天机器人(10) typescript(10) 资料精选(10) NLP(10) 第三方Cookie(9) Redwoodjs(9) ChatGPT(9) LLMOps(9) Go语言中级开发(9) 自然语言处理(9) PostgreSQL(9) 区块链(9) mlops(9) 安全(9) 全栈开发(8) OpenAI(8) Linux(8) AI(8) GraphQL(8) iOS(8) 软件架构(7) RAG(7) Go语言高级开发(7) AWS(7) C++(7) 数据科学(7) whisper(6) Prisma(6) 隐私保护(6) JSON(6) DevOps(6) 数据可视化(6) wasm(6) 计算机视觉(6) 算法(6) Rust(6) 微服务(6) 隐私沙盒(5) FedCM(5) 智能体(5) 语音识别(5) Angular开发(5) 快速应用开发(5) 提示工程(5) Agent(5) LLaMA(5) 低代码开发(5) Go测试(5) gorm(5) REST API(5) kafka(5) 推荐系统(5) WebAssembly(5) GameDev(5) CMS(5) CSS(5) machine-learning(5) 机器人(5) 游戏开发(5) Blockchain(5) Web安全(5) Kotlin(5) 低代码平台(5) 机器学习资源(5) Go资源(5) Nodejs(5) PHP(5) Swift(5) devin(4) Blitz(4) javascript框架(4) Redwood(4) GDPR(4) 生成式人工智能(4) Angular16(4) Alpaca(4) 编程语言(4) SAML(4) JWT(4) JSON处理(4) Go并发(4) 移动开发(4) 移动应用(4) security(4) 隐私(4) spring-boot(4) 物联网(4) nextjs(4) 网络安全(4) API(4) Ruby(4) 信息安全(4) flutter(4) RAG架构(3) 专家智能体(3) Chrome(3) CHIPS(3) 3PC(3) SSE(3) 人工智能软件工程师(3) LLM Agent(3) Remix(3) Ubuntu(3) GPT4All(3) 软件开发(3) 问答系统(3) 开发工具(3) 最佳实践(3) RxJS(3) SSR(3) Node.js(3) Dolly(3) 移动应用开发(3) 低代码(3) IAM(3) Web框架(3) CORS(3) 基准测试(3) Go语言数据库开发(3) Oauth2(3) 并发(3) 主题(3) Theme(3) earth(3) nginx(3) 软件工程(3) azure(3) keycloak(3) 生产力工具(3) gpt3(3) 工作流(3) C(3) jupyter(3) 认证(3) prometheus(3) GAN(3) Spring(3) 逆向工程(3) 应用安全(3) Docker(3) Django(3) R(3) .NET(3) 大数据(3) Hacking(3) 渗透测试(3) C++资源(3) Mac(3) 微信小程序(3) Python资源(3) JHipster(3) 语言模型(2) 可穿戴设备(2) JDK(2) SQL(2) Apache(2) Hashicorp Vault(2) Spring Cloud Vault(2) Go语言Web开发(2) Go测试工程师(2) WebSocket(2) 容器化(2) AES(2) 加密(2) 输入验证(2) ORM(2) Fiber(2) Postgres(2) Gorilla Mux(2) Go数据库开发(2) 模块(2) 泛型(2) 指针(2) HTTP(2) PostgreSQL开发(2) Vault(2) K8s(2) Spring boot(2) R语言(2) 深度学习资源(2) 半监督学习(2) semi-supervised-learning(2) architecture(2) 普罗米修斯(2) 嵌入模型(2) productivity(2) 编码(2) Qt(2) 前端(2) Rust语言(2) NeRF(2) 神经辐射场(2) 元宇宙(2) CPP(2) 数据分析(2) spark(2) 流处理(2) Ionic(2) 人体姿势估计(2) human-pose-estimation(2) 视频处理(2) deep-learning(2) kotlin语言(2) kotlin开发(2) burp(2) Chatbot(2) npm(2) quantum(2) OCR(2) 游戏(2) game(2) 内容管理系统(2) MySQL(2) python-books(2) pentest(2) opengl(2) IDE(2) 漏洞赏金(2) Web(2) 知识图谱(2) PyTorch(2) 数据库(2) reverse-engineering(2) 数据工程(2) swift开发(2) rest(2) robotics(2) ios-animation(2) 知识蒸馏(2) 安卓开发(2) nestjs(2) solidity(2) 爬虫(2) 面试(2) 容器(2) C++精选(2) 人工智能资源(2) Machine Learning(2) 备忘单(2) 编程书籍(2) angular资源(2) 速查表(2) cheatsheets(2) SecOps(2) mlops资源(2) R资源(2) DDD(2) 架构设计模式(2) 量化(2) Hacking资源(2) 强化学习(2) flask(2) 设计(2) 性能(2) Sysadmin(2) 系统管理员(2) Java资源(2) 机器学习精选(2) android资源(2) android-UI(2) Mac资源(2) iOS资源(2) Vue资源(2) flutter资源(2) JavaScript精选(2) JavaScript资源(2) Rust开发(2) deeplearning(2) RAD(2)

"If we really want to make our website faster, we should just rewrite it in Next.js."

I think you'd be hard pressed to find a tech startup anywhere without at least one developer who is constantly saying this.

But is it actually true?

I certainly had no reason to doubt it.

As someone who had just done the big upgrade from AngularJS to Angular, I was happy that all those months of work had resulted in a massively improved PageSpeed Insights performance score for both our landing page and our content pages. Before the upgrade the scores for these pages were typically in the mid 20s, whereas now the scores for the content pages are often into the low 90s, and the logged out landing page is even faster.[1]

At the same time, I was wondering if maybe I shouldn't be having some buyers remorse; after all, how much faster could our site have been had I rewritten it using Next.js instead?

Had you asked me, my guess at the time, based on purely circumstantial evidence, would have been 30 - 40%.

Why?

I know of multiple teams who have switched from Angular to Next.js, specifically citing the performance benefits. And clearly it wouldn't be worth doing so if the advantage were only 5 or 10%. Further, the First Contentful Paint of our own site on mobile is currently around 2.0 seconds, and be in the green you're supposed to be under 1.2 seconds. So surely SSR must be the best way to actually get there, right?

Right?

Not to mention that if you Google for angular performance, most of the top results are articles about how React is faster.

Either way it was kind of a moot point because I'd already done the work, and we weren't going to be rewriting the site anytime soon. But I was still curious. So I did the logical thing: I went to the Next.js website, looked at some of the logos of the companies using the framework, and started typing their domains into PageSpeed Insights.

TikTok got a 23. IGNHulu, and Netflix were in the upper teens. And the fastest site I tried that day was Twitch, which got in the mid 50s.

These results were... surprising.

Were these sites slow because they were big commercial sites with lots of marketing and analytics scripts, or was there something else going on? And, similarly, how did this compare with Angular?

After a few weeks of mulling over these questions, I suddenly remembered that PageSpeed Insights had an API. And in addition to the Next.js showcase, there was also the Made With Angular site. So I scraped a list of every site on each of these pages, and wrote a script.

Here were the results:

Framework Average Performance Score Average First Contentful Paint (s) Average Time To Interactive (s)
Angular w/o SSR 37.4 4.7 13.5
Angular w/ SSR 37.5 3.1 17.1
Next.js 34.8 3.7 19.3

See also: full data and code.

If I were purely a frontend developer then maybe this data wouldn't have been as surprising, but as a fullstack developer, it was somewhat shocking.

Some observations:

  • The average and median performance scores for both frameworks were very similar. Angular had a slight edge in both cases, but not enough to be meaningful.
  • There is a huge range of performance scores within each framework. For Next.js, the range was 1 - 87. For Angular, the range was 3 - 95.

It's very clear from this data that choice of framework is not the primary driver of site performance; just manually looking at the source code for some of these sites, it's clear that it's things like unnecessary dependencies, outdated dependencies, sites running development mode in production, etc. (Several of these sites were still running Angular v4 or v5 in production!)

This observation is also reflected in my own migration path. For context, migrating from AngularJS to Angular has four main phases:

  1. Replacing Bower with NPM, and replacing Grunt with Webpack.
  2. Converting AngularJS controllers and directives into AngularJS components. And replacing template code injected via ng-include with components.
  3. Porting AngularJS components to Angular components, and going from running AngularJS to running Angular.
  4. Making additional optimizations that are now possible thanks to Angular, like deferring JS and CSS that isn't needed in the initial bundle.

Of these four steps, the only one that did not result in a substantial improvement in performance was step 3, actually replacing AngularJS with Angular.

That said, when it comes to performance, even though the average and median performance scores are very similar, the edge here goes to Angular.

Why?

If we buy into the idea that the framework itself isn't the primary factor behind the average performance score for each framework, which the data supports, then really it makes the most sense to consider only the fastest sites. The reason is that in either framework it's likely possible to get up to a 95 or so on a real-world, medium- or large-sized site. So the question then is how difficult is it to actually get there? And the best way to answer this, at least that I can think of, is just by looking at what percentage of sites do actually get there, or at least close.

The results here are super interesting:

This graph was generated by taking the raw scores for each framework, and then calculating their respective performance scores at each percentile. So e.g. for Angular, the fastest site gets a 95, the 95th percentile site gets a 77.75, the 90th percentile site gets a 71, etc. What you can see is that the scores at each percentile are basically identical for sites at the 70th perentile and slower. But above the 70th percentile, Angular sites have a clear advantage.[2][3]

Another way to think about the same trend is that, in this data set, 12% of Angular sites had performance scores over 70, as compared with only 5% of Next.js sites. It's not clear why this is, and it may well be that a different data set would yield a different distribution curve.

If I were seriously considering spending eighteen months to rewrite our frontend then maybe I'd pay for a list of the 100k sites with the most traffic to see if the trend is still the same, but as it stands I'm more than happy to let anyone else who is interested see how tweaking the methodology changes (or doesn't change!) the outcome.

But based on the current data, I see no reason to think that migrating from Angular to Next.js will deliver any performance benefits, let alone benefits substantial enough to justify such a massive project. In fact, it may be worth taking seriously the idea that even if it's possible for apps built with either Angular or Next.js to achieve top performance scores, it may actually be more time consuming (read: expensive) to do this with Next.js. At the very least it's an idea worthy of future exploration.

Of course there's more to performance than just the overall performance score:

  • Angular had almost the identical performance scores with and without SSR.
  • Angular with SSR and Next.js both had significantly faster FCP scores than Angular without SSR, but significantly slower TTI scores.

What the data really shows here is that pre-rendering is a lateral move — you're gaining FCP at the expense of TTI.

That said, most major social platforms, like Twitter and Facebook, currently require sites to be pre-rendered in order to generate dynamic preview cards, so if Next.js makes this easier then that would be an advantage for Next.js.

The absurd thing here is that FWD:Everyone is apparently faster than every site in both the Angular and Next.js showcases. And it really is absurd, given that:

  • FWD:Everyone isn't a small site: it's a social network with 26 routes and a dozen or so modals, each of which is fully styled for desktop, tablet, and mobile.
  • While I like to think of myself as generally competent at writing frontend code, it's far from an area of expertise, so there are likely more optimizations that could be done if I had a more specialized skill set.
  • There are several more possible performance improvements that I know of and that are within my skill set to execute, but that I just haven't gotten around to doing yet.

Obviously the fact that I haven't junked up our pages with tons of marketing trackers like many of the larger and more commercial sites is a huge advantage, but still, you'd think there would be at least some other sites with better overall scores. After all these aren't just any Angular or Next.js sites, they're the ones that the proponents of those frameworks have specifically chosen because they ostensibly reflect well on those technologies.

Even though the average performance of websites using each of these frameworks is similar, overall this is a win for Angular; over the last couple years countless people have been promoting the idea that the way to fix slow Angular sites is to rewrite them in Next.js, and the data very clearly does not support this. In our own case, improving our speed by switching to Next.js would require us to be significantly faster than every site in the Next.js showcase. Maybe this is possible, but absent further information this doesn't seem like a great bet.

And if I did have to bet, my best guess is that I'd get more mileage out of spending three months getting rid of bootstrap than I would by spending eighteen months rewriting our site in React.

What's more, the upcoming performance improvements on the Angular roadmap actually look pretty good. Angular without Zone.js and with RxJS 8 should mean substantially smaller production bundle sizes. And upcoming improvements to Angular Universal should make implementing SSR even easier.

For me personally, I see a solid roadmap for getting our site to go from often being in the low 90s to consistently being in the mid 90s, should that become worth doing. But then again, phones are getting faster every year, so today's 93 might already be tomorrow's 100 anyway.

Regardless, on the basis of performance both frameworks are likely good enough. Startups should instead be choosing their frontend framework based on total cost of ownership, development speed, and ease of hiring. And once you've made your decision, don't second-guess yourself; the framework is not your limiting factor.

[1] During this process I also made other performance improvements like replacing Moment.js with Day.js, upgrading from Bootstrap 4 to Bootstrap 5, dropping jQuery, making the JS and CSS more DRY, and deleting tons of unused JS and CSS. Some of these required first upgrading from AngularJS to Angular, others did not.
[2] Even if you discount the fastest Angular site in this dataset, which is little more than a Hello World app.
[3] The Angular series on this graph includes both sites using and not using SSR, since SSR seems to have no affect on performance scores. And in fact if you make the same graph, but excluding Angular sites using SSR, the graph looks nearly identical — if anything, the gap between Angular and Next.js at and above the 70th percentile is even more pronounced.