Eliminate Layout Shift on Statusbox when Rendering Issues and MR's

This MR solves: #325180 (closed)

Under some preconditions when loading a Merge Request or an Issue on GitLab, the status box had some unfortunate layout shifts while rendering the page. This MR removes those Layout shifts.

Example Screenshot of Statusbox:

What's the Issue and the Update?

mobile

before	after
before-mobile	after_mobile

desktop

before	after
before-desktop	after_desktop

How to reproduce?

Load any Issue or Merge-request on GitLab, make sure to have a clear cache, you also may have to throttle your connection to see the layout shift.

What was the Issue and the fix?

The Issue was that the mechanism to toggle between the mobile and the desktop variant of the status box is toggled using two CSS Classes gl-display-none and gl-sm-display-block. Which in theory is absolutely fine, but has it's tweaks in practice.

gl-display-none and gl-sm-display-block get loaded pretty late in our waterfall.

Screen of Styles:

Network Waterfall of GitLab Issue

This causes the edge-case that on slower Network Connections or empty caches, the Markup get's rendered before the corresponding CSS is loaded, which than gets added to the page at a later point. CSS then gets applied -> layout shifts.

The fix in this MR is to substitute gl-display-none and gl-sm-display-block with classes that apply the same styles but are already available in our startup CSS which is inlined before the statusbox. Styles are parsed before the statusbox -> Layout doesn't shift anymore.

Whats the cost of this optimization?

Every Most performance optimizations come with a price. Since we have to prioritize things other things might be delayed. So what's the cost of this optimization?

One Selector had to be added to the startup CSS it's highly generic and probably handy for future optimization. Additions to startup CSS should be handled with caution since we are adding to our render-blocking path on every GitLab page. Keeping in mind that Issues and MR's are an important part of GitLab and we're only adding one Selector to the startup CSS this is IMO a pretty good deal.

Does this MR meet the acceptance criteria?

Conformity

• 📋 Does this MR need a changelog?
  • I have included a changelog entry.
  • [-] I have not included a changelog entry because _____.
• [-] Documentation (if required)
• [-] Code review guidelines
• [-] Merge request performance guidelines
• [-] Style guides
• [-] Database guides
• [-] Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team