How a render-blocking resource works
A browser reads a page from the top. When it meets a stylesheet it stops painting until that file has arrived and been understood, because drawing first would mean showing unstyled text and then rearranging it. When it meets an ordinary script in the head it stops reading the document altogether, since that script might change what comes next.
Both behaviours are deliberate, and neither is a fault. The problem is quantity and placement. A theme that loads a stack of stylesheets, several font files, a slider library and a tag script before the first paragraph is drawn has put a queue in front of the visitor, and every item in that queue is paid for again on a slow connection.
Why it matters
It is the main reason a page sits blank. First Contentful Paint cannot happen until the blocking work is finished, and Largest Contentful Paint follows along behind it, so the blocking path sets the ceiling for both.
The cost is heavier on a phone than the file sizes suggest, because a mobile processor takes noticeably longer to parse the same styles and scripts than a laptop does. Add a slower round trip to fetch each file and a handful of blocking requests becomes a visible wait. That combination — modest phone, mobile network — describes most browsing in Nepal.
Where it goes wrong
Third-party tags in the head cause the worst cases, because the first paint is being handed to somebody else’s server. A chat widget or a testing script loaded the blocking way will hold your page hostage on any day that provider is slow.
The other habit is bundling everything into a single file served on every page. It is convenient, and it means each visitor downloads and parses the styles for the checkout, the blog and the contact form in order to read one article. Combining files was sensible advice under older connection limits; today it mostly hides how much unused code is being shipped.
How to act on it
Deal with styles by separating what the top of the page needs from everything else: inline that small part, load the rest without blocking, and give stylesheets that only apply in certain conditions a media attribute so the browser deprioritises them. Chrome’s coverage tool shows how much of each file went unused, which is usually a surprise.
Deal with scripts by moving them out of the critical path. Anything not required to draw the page should be deferred, and anything only needed after an interaction should load at that point. Self-host and preload the fonts you genuinely use, and drop the ones you do not. Where the blocking is built into a page builder or theme, removing it becomes a page speed optimisation job rather than a configuration tweak, and critical CSS is usually where it starts.