Use moment-timezone-data-webpack-plugin to optimize timezones shipped in wp/date #51519
Conversation
jsnajdr
added
[Type] Performance
|
Size Change: -22.7 kB (-2%) Total Size: 1.42 MB
ℹ️ View Unchanged
|
|
The bot reports gzipped sizes, there the improvement is not 10x, but merely 57%. The big TZ data compress well. |
|
Performance tests also show improvement when it comes to loading the editor: Too bad we don't report the ± variances and can't estimate how significant and non-random the changes are. |
There was a problem hiding this comment.
This is such a great optimization, nice one @jsnajdr 👍
Could you please add some testing instructions to the PR?
From the perspective of the user interface, what compromise are we making when limiting the timezone data? Would be worth evaluating where it's actually utilized and how it would affect the end users.
tools/webpack/packages.js
Outdated
| new MomentTimezoneDataPlugin( { | ||
| startYear: 2000, | ||
| endYear: 2030, | ||
| } ), |
There was a problem hiding this comment.
This will require us to maintain the years every now and then. Does it perhaps make sense to make these dynamic?
const currentYear = new Date().getFullYear();
and then something like:
| new MomentTimezoneDataPlugin( { | |
| startYear: 2000, | |
| endYear: 2030, | |
| } ), | |
| startYear: currentYear - 20, | |
| endYear: currentYear + 10, |
There was a problem hiding this comment.
I'd rather keep it dumb instead of dynamic. We need to start at least in 2003, the year of WordPress first release, and in 2030, we surely won't use moment.js any more 😉
There was a problem hiding this comment.
What you're saying is true, but how does it relate to the timezone config? Yes, WordPress started in 2003, but you can have a post written earlier (in 1997 for example) and that's fine. You can also schedule a post for 2040, that's perfectly fine. Perhaps we can keep the end-year dynamic at least? Otherwise, we may easily forget to update it as we get closer to it, and as much as we should remove moment.js by then, WordPress is known to maintain backwards compatibility forever. This might mean that the @wordpress/date package will remain forever, albeit unused in Gutenberg, and that would mean that this config will also remain for the time being.
There was a problem hiding this comment.
I was also curious about other CPTs which may not adhere to when they were posted. For example, someone could create a historical timeline using CPTs where each event is a post and has a historical date. (Though does that even matter in the context of this webpack plugin?)
There was a problem hiding this comment.
Yes, if you're creating a history site and want a post to have an exact time of a historical event, e.g., November 22, 1963, at 12:30 p.m. CST, you might run into trouble if we ship a TZ range that doesn't include year 1963. But I'm not sure what exactly will happen. For this particular date probably nothing, because it's safely outside the DST range. But if you choose a date which would be DST in 1963 but not today, or vice versa, the editor might show you a time that's off by one hour.
I definitely agree; insufficient analysis can sometimes suggest the wrong thing. That being said, the numbers shown here don't raise much suspicion to me. A massive reduction in JS to be parsed and compiled (and what matters there is uncompressed size, not gzipped size, so we're talking 1/10th) is bound to have a measurable impact on interactivity metrics. Since this JS loads as part of the critical path, I would expect that to reflect in first paint and every subsequent time-based metric. Assuming that the existing functionality is preserved, this is an excellent interim improvement as we hopefully move towards a solution that doesn't involve shipping timezone data down the wire at all, but instead relies on the system's. Fantastic work, @jsnajdr! 🙌 |
All places that use 
But it seems to me that post publish dates behave differently -- it shows as published at 5:48 am, no matter which timezone I choose. Even without this PR. So maybe that date has a different meaning, TZ-agnostic. |
Yeah, that was my understanding as well, but I tried both with and without the timezones and nothing changed for my tests. It would be nice to confirm that there's an area that actually is directly affected by this, and to reflect this in testing instructions so we can ensure we understand the consequences of the PR. WDYT? |
Yes, I also have some open questions like this -- it's possible that Gutenberg itself doesn't use the bundled timezones at all. Because the 
And uses that as the default timezone when formatting dates. But that's bad because this timezone definition is incomplete, the
Then it will probably use the 2003 rules which is not entirely bad. The typical rules change between 1997 and 2003 is that the DST switching times have shifted to be a week later or earlier. |
|
Perhaps @youknowriad could be able to help? He worked on #841 back in the day. |
If I remember correctly, we do this indeed for i18n reasons. These labels come translated from the backend. |
Would be great if someone can provide more info about this if they have it at the top of their head. We'll most definitely be digging into understanding all the impact that |
|
@tyxla WordPress allows you to tweak your timezone settings, date format and time format from the "settings -> general" wp-admin page. and these changes need to be reflected in the UI and I think that's what this timezone is about. |
Thanks for confirming, but since I knew that already and I've been tweaking those settings, the dates always appeared in Bulgarian properly for me, regardless of whether I'm loading timezone data or not. Hope that makes more sense as to where the confusion comes from. |
|
If by time zone data you mean moment-timezone, than yeah maybe that is useless since we always define on in WordPress but there are questions about third-party cases that don't rely on the "WP" timezone. (I hope I'm understanding this properly) |
That's what I mean, yes. Thanks for confirming - it's worth knowing that we can explore NOT loading the huge moment timezones blob at all. @jsnajdr is this something you'd like to try out?
I'd love to understand more about these cases - do you happen to have an example? We could benefit a lot from making the moment timezone data optional or opt-in. |
Not much to be honest, I just have very vague memories that at some point we attempted changes about how "moment" locales were handled and it broke some plugins (it was something about locales being define globally in the moment singleton or something), but to be honest, that's very far in the past. Not sure it should stop any explorations. |
Sounds great! @jsnajdr - in that case how do you feel about keeping the span minimal - like for this year only for example? Hopefully, that may keep the 3rd party plugin use case working while getting us a very solid file size improvement. |
It seems indeed that the timezone data are not used, at least for post dates. And it leads to wrong results. The Core REST API ( Here's how my testing post looks like in the wp-admin post list: 
but in Gutenberg, the 
That's because Ideally, we shouldn't use the |
Seems like this is work for another PR. This one can be merged separately IMHO. The only thing that gets me anxious is the And then for the future, I'd love us to explore getting rid of |
jsnajdr
force-pushed
the
optimize/date-moment-tz
branch
from
d46d09c
to
bb62463
Compare
I changed the limit to 2040, 10 years more. I don't like the idea to calculate the year dynamically based on the current year. That makes the builds non-reproducible. On the same commit, you get different output on different dates. Also, the build machine's date can be completely wrong, like 01-01-1970. |
|
Flaky tests detected in bb62463. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5419716524
|
Makes the
@wordpress/datescript 10x smaller (from 750k to 75k) by shipping timezone data only for the 2000-2030 year range, instead of the full dataset that starts somewhere in antiquity and ends in 2400.Calypso has already been doing for a long time. This PR has a discussion about the most recent updates we did there just a few months ago.