News Site Next - Article Ids

[flashdesignory]

This is an alternate solution for: #426

The reason to keep creating unique ids, is that it'll allow us to potentially opt into a complexity param (#430), which could append content by cloning the sections in the data file. This is only possible, if we don't hard-code list ids in the data file (which was the previous solution).

Here, I am just creating the unique ids once, when the data gets assigned to the app, instead of the currently used version that had issues (#422).

note: feel free to ignore the dist folder - that's just the generated build files

Crossbench - 10 iterations:

this pr

browser			Safari                    Firefox                Google Chrome
NewsSite-Nuxt  		61.2 ± 2.7%               67.6 ± 2.0%            61.51 ± 1.2%
NewsSite-Next  		58.80 ± 1.3%              74.42 ± 1.1%           68.72 ± 1.3%
Score          		16.75 ± 1.8%              14.14 ± 1.1%           15.41 ± 1.1%

main

browser			Safari                    Firefox                Google Chrome
NewsSite-Nuxt  		62.2 ± 2.6%               67.4 ± 1.7%            61.45 ± 1.2%
NewsSite-Next  		59.86 ± 1.4%              78.81 ± 1.2%           75.7 ± 2.1%
Score          		16.46 ± 1.8%              13.76 ± 1.0%           14.69 ± 1.5%

[rniwa]

Seems sane to me.

[julienw]

Thanks, this looks good to me.

One question though: On my computer it looks like Chrome gets a higher boost than Firefox. Could that be because uuid was quite slower in Chrome? Is it interesting that we measure uuid computation? (maybe it's not interesting if it's not on the hot path for websites)

Thanks

[camillobruni]

I did some more profiling... looks like we're doing fewer layout (Element::RecaclStyle went down from sampled 7.2s to 6.9s)

Likely the brittle async measurements feeds into this diff as well.

[julienw]

I did some more profiling... looks like we're doing fewer layout (Element::RecaclStyle went down from sampled 7.2s to 6.9s)

Likely the brittle async measurements feeds into this diff as well.

From this diff, it looks like the changes come from a scrollTo call. The only scrollTo call is in a useEffect:

Speedometer/resources/newssite/news-next/src/partials/layout/layout.jsx

Line 27 in d6b5ffe

pageRef?.current?.scrollTo({ top: 0, left: 0, behavior: "instant" });

So not sure what's happening here.

Also I don't see the same thing when I profile chrome locally. So to me this is still a mystery.

That said because the change makes a lot of sense I'm gonna approve it.

[netlify]

✅ Deploy Preview for webkit-speedometer ready!

Name	Link
🔨 Latest commit	9e9dd02
🔍 Latest deploy log	https://app.netlify.com/sites/webkit-speedometer/deploys/678fceef3aaae1000947159e
😎 Deploy Preview	https://deploy-preview-447--webkit-speedometer.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.