DEV Community: Eugene Chekan

Unusual render-blocking CSS case within International phone number input clonable

Eugene Chekan — Sun, 06 Apr 2025 22:20:11 +0000

If you are using a "International phone number input clonable" (or one of handful of similar ones) on your Webflow site, this might be a story for you. We reported the issue to the Webflow and to the component author, not sure how long will it take to fix it.

Recently I was working with my new client that has a website on the Webflow, usual stuff: speeding up metrics on Google pagespeed, that kind of things. All went smooth, except for one thing: for some reason, the render time on google pagespeed was slower than expected. Sometimes firt render took like 5-10 seconds more. On my browser it was closer to 1-2s range. So I recorded a profile in Chrome's DevTools and saw a loooong element render delay.

There was no network data transfer, no Javascript running, no styles calculations. It was just hanging in there for some reason and I could not pin it down. I then zoomed in even more and noticed a thin microsecond-sized task that mentioned some demo.css. Okay at least that's something, CSS will block page from rendering, let's go and find it, I thought. There it was.

Notice the domain name there. That's an expired domain that was owned by the library author on github. The thing is, domain has expired and someone bought it, and it now redirects to some sketchy page.

Now, I'm not sure what different browsers do when they get a sketchy webpage instead of a CSS file: most likely they will fail parsing that file right away and discard it. What I do know is that new domain that we're being redirected to is slow to respond, and that's what blocks the render.

When I blocked the CSS in my devtools, the Element render delay went down to just 200ms!

After we updated the Webflow website code to not include that component, the pagespeed score for mobile skyrocketed from 50-ish into 80+!

So yeah, if you use that international phone number component, you might wanna check if you have that demo.css stuff pointing to a sketchy domain and disable it while WF and component author are fixing that.

Shameless plug time: if you want me to help you out with improving website performance then get in touch, I'm available!

Need startup/pet project idea? You can have dozen of them daily

Eugene Chekan — Tue, 23 Oct 2018 10:02:57 +0000

Many people find it hard to actually come up with the idea for a startup or a pet project. Some time ago it was the same for me, but now it’s not: I can generate dozens of ideas daily, thanks to the method I’ve come up with through all these years. Here’s the transcript of a small talk I did on the matter of generating and validating ideas.

Why?

First of all, it is important to answer this question:

“Do you want do it because of fun or to make money?”

Fun or money, either is great, but settle on that as early as possible. “Fun” doesn’t imply that it will be something easy to do, it implies that you’ll do something you can relate to or something you will enjoy doing. “Fun” is fun for you.

Now, some may think it is too early to make this decision, and why can’t I get both? This “fun or money” choice will be a rule of thumb for the decisions throughout the project: marketing, goals, priorities, everything.

Asking right questions

Now let’s find the idea. To do this, we need to ask questions to people (you didn’t think you’ll do well without going out and talking to people, did you?). And obviously you need to listen to their answers. I will give you three questions to ask, but you can easily work out more. One thing you shouldn’t ask: “Do you have any idea for a possible project?”. Just don’t ask this one, believe me.

What do you hate doing?

This may relate to work, daily life, pets, anything. This may be something happening once a month or on a daily basis. What you should look for is The Pain Point. Remembering and typing in passwords, trying new (and bad tasting) beers, choosing route in heavily trafficked city. We hate that. That’s why there’s LastPass, Untappd and Google Maps. Solve The Pain Point for people and you’ll have the fame.

What steals your time?

Here you should find out what takes away from people some fair amount of their time. Again, this can be related to work, personal life, etc. The big difference with previous questions is that “steals your time” doesn’t imply people hate it. You may (should) love talking to your clients, plan your budget, and organize your tasks. That’s why there’s Mailchimp, YNAB and Trello. Actually, that’s exactly how Downosaur was born: we love to stay updated on status of things we use (GitHub outage, anyone?), but it takes a lot of time for a newly onboarded person in a company/freelance gig/startup to subscribe to status updates of all services we use.

What doesn’t work well enough?

Last but not least question, and it can actually give you surprisingly lot of insights. This one looks like the reverse of “what do you hate?” coin, and it is. If there’s something people lack in existing product, they will adore the product where those features are present. Sketch to Figma, Blogger to Medium, hosting provider DNS to Cloudlfare’s one.

Formulate

Now you need to refine your idea, be it The Pain Point elimination, something to save people time or fixing what is broken. Try to say it in a single, short sentence. “Status updates for small teams” is great, “The website where you put your emails to receive messages when GitHub or something else goes down” is not. Reduce as much as possible, this will help you throughout next steps (not only in the context of this article).

Validate

Now when you have your idea idea, don’t rush to implement it. Don’t start a MVP. You need to validate the idea first, and not waste any time implementing something that will not take off. So here’re two things you should do.

We’re in beta, leave your email

That’s it: simple landing page capturing subscriptions. Mailchimp has those, as well as tons of others. Now share the link across some Reddit/Twitter and across your own network. You may also go and chip in a $50 into Google Ads and get some traffic from Google’s search. Keep in mind that ad clicks are validations too, it’s not about subscriptions themselves.

We’re in beta, here’s your email

Alternative way of validating your idea [cheap and quickly] is to find your potential customers and ask them, if they want it. And optionally, if they are willing to pay for it. It often takes more than 10 emails before you get any reply, but it totally worth it. A friend of mine was to develop a Shopify plugin and just went and contacted a bunch of Shopify-driven shops via contact form on their site. The feedback he’s got saved him a couple of months of implementing the app nobody was going to use because they have already had an app for that.

KISS

If you decide to go with implementing your new idea, then keep it simple. Don’t give up too soon, yet don’t try to make something unmanageable work. Ideas are free, your time isn’t. And now when you can generate a bunch of ideas you shouldn’t care too much when one of them looks like a possible failure. Throw it away, come up with 10 new ones, and 🚀

If you want me to help you improve your website performance then get in touch, I'm available!

"Performance marks: the missing manual, Part 1"

Eugene Chekan — Mon, 01 Jan 2018 23:45:44 +0000

Image by Viktoriiaa

performance.mark() is a part of User Timing API. Arguably, it is the most useful performance-related method we have in browsers now because its application possibilities are far beyond just “mark this timestamp for me”, especially when combined with deep understanding of how browsers actually work.

Basic Usage

To use it, just call performance.mark() and pass mark name as a parameter within any JavaScript code:

performance.mark("fontsLoaded");

This will add a PerformanceMark to the performance timeline.
To delete a mark, make a call to the performance.clearMarks() method:

performance.clearMarks("fontsLoaded");

JS one-liners inlined directly into HTML will do as well:

<p>What a beautiful text</p>
<script>
  performance.mark("afterText");
</script>

I know what you're thinking: “Hey JS is mostly single-threaded, can I mark the moment when browser reaches exact line in the document?”. For the most part, yes, you can. Let's try this out!

Mark all the things

First, a bit of theory 🤓. Most of the time, document parsing and JS execution is done in a single thread, with respect for document structure from a first line to the last one. When browser meets, say, a <link> to the stylesheet or a script, it pauses execution, downloads the resource it stumbled on, parses and executes it, and only then continues with parsing and executing stuff below. This concept — render-blocking resources — is crucial for achieving fast rendering timings and brilliantly covered by Ilya Grigorik in his talks and free online course.

Now, optimizations aside, you may want to know how much time do you lose due to render being blocked by resources. Take a look at this snippet:

<html>
  <head>
  <title>Performance marks demo #1</title>
  <script>performance.mark('parsing:css:start');</script>
  <link rel="stylesheet" href="shiny-style.css">
  <script>performance.mark('parsing:css:end');</script>
  </head>
  <body>
    <p>What a beautiful text</p>
  </body>
</html>

Opening this in browser will mark two events: the one before stylesheet link, and one after. Check'em out:

Whoa 😱! It took browser near 80 ms to download, parse and apply our shiny stylesheet, faster than a blink of an eye. Not so fast for one CSS selector we have there, though.

On the bright side, you now know how to measure for how long rendering is blocked by resources. Wait, did I say measure?

Measures

We all ❤️ math, don't we? But when it comes to actual calculations, we like to make computers do it. Performance marks are no exception and we have handy performance.measure() method which, well, measures distance between two marks. Let's add it to our HTML snippet:

<html>
  <head>
  <title>Performance marks demo #2: measures</title>
  <script>performance.mark('parsing:css:start');</script>
  <link rel="stylesheet" href="shiny-style.css">
  <script>
    performance.mark('parsing:css:end');
    performance.measure('blocking-styles', 'parsing:css:start', 'parsing:css:end');
  </script>
  </head>
  <body>
    <p>What a beautiful text</p>
  </body>
</html>

Now let's see how this measure thing looks in browser:

Cool, we can now just look at measure's duration instead of doing math. Yay computers!

Mark-fu

Me myself as well as some other developers prefer to use some kind of namespacing when setting up marks to organize taxonomy across different mark and event types:

performance.mark("fonts:roboto:load");
performance.mark("parsing.head.start");

That is, you just separate namespaces with colon or dot and your marks are getting nice structure. Of course you can use anything (🐰, anyone?) to separate namespaces, not just dots and colons. There is no solid standard about performance marks namespacing and you are welcome to use whatever separator you want to use, pretty much like CSV format.

Retrieve your marks

During development

Getting performance marks with your browser is easy:

Go to the developer tools of your browser
Switch to JavaScript Console tab
Put down performance.getEntriesByType('mark') and here they are!

From real users

Now, the hardest part is to retrieve these marks from your real users, and we're at Taki care about marks a lot. We are currently developing Marks'n'Measures Dashboard, although marks are already visible in our Waterfall view.

Webpagetest, as well as WPT-based MachMetrics & SpeedCurve, do support performance marks to some extent and you can get a glance at marks in Performance Timeline with these tools. If you haven't heard about WPT, go check it out: it is one of the best #webperf tools out there, it's completely free yet carries a whole lot of features. I literally use it on a daily basis and do love it.

Who use it?

There's a couple of examples of performance marks in wild I know of: Google Maps and Optimizely. They set up marks throughout their client-side JS, so if you have GMaps embeded, or do run some Optimizely experiments, check out performance entries with your devtools on those pages!

What next?

In coming articles I will show a lot more of advanced level mark-fu and tell you about differences across different browsers in marks handling (you didn't even thought everything will work the same across all the browserzoo we're developing to, do you?😉).

If you know some other examples of marks in the wild other than Google Maps and Optimizely, please do share them in comments below. And of course I encourage you to share your experience with marks, would love to take a look at other devs approach to marks.

If you want me to help you out with improving website performance then get in touch, I'm available!

And remember, #perfmatters!