DEV Community: Matheus Raduan

Sometimes the Fix Is in the Concept, Not the Code

Matheus Raduan — Wed, 12 Aug 2026 20:44:18 +0000

A few years ago, working with a client I found myself inside one of the most performance-critical codebases I had ever touched. As part of the Frontend and Performance team, our responsibility went beyond build and maintain features, we owned the SEO metrics and Web Vitals numbers for a product receiving 11 million monthly visits, ranked among the top 1,000 most accessed domains in the world. It was there that I truly understood the impact a developer can have on CRO (Conversion Rate Optimization) through performance work.

The Usual Suspects

One of our ongoing challenges was improving LCP (Largest Contentful Paint). For those unfamiliar, LCP is one of the Core Web Vitals metrics that measures perceived load speed by tracking how long it takes for the largest visible content element on a page to render. In other words, it approximates the load time of the most important element a user sees. At the time, our rendering strategy was hybrid: part of the content was server-side rendered (SSR), and part was loaded on the client side (CSR). In the diagram below, you can see a rough sketch of the app's main page, the content below the red stroke line was loaded client-side, while everything above it came fully rendered from the server.

The team's challenge was clear: LCP had started drifting between the yellow and red zones, and our goal was always to stay in the green. So, what could we do? We had several options on the table:

Reduce the load time of the current primary LCP element by optimizing requests and their order
Reduce the size of the main image to improve loading (lazy-load, prefetch, fetchpriority, modern formats, etc.)
Remove potential render-blocking processes (e.g., @import in CSS)
Improve TTFB (Time to First Byte) through better CDN caching strategies

All of these are valid and valuable, they can and should be applied. But given how far our metric was from where we needed it to be, the team had a gut feeling that none of them alone would close the gap. So we started testing all of them to improve our numbers.

After exhausting several scenarios and following every recommendation in the Web Vitals documentation on LCP, something caught my eye, not a technique, but an example. A classic walkthrough of the old Instagram loading screen, where the LCP element is identified before the full page finishes loading. The reason: during the loading process, the LCP candidate isn't fixed. It shifts, gets replaced by larger elements, and only stabilizes once the page settles. What the documentation was quietly showing was: the LCP element is not a given, it's a moving target, and if it's a moving target, it can be aimed. That's when an idea hit me.

Rethinking the Problem: What If We Chose Our LCP?

What if, instead of just trying to load our elements faster, we deliberately changed which element became the LCP? What if we intentionally steered what we wanted our LCP to be? Sure, it sounds obvious when you say it out loud, but stop for a moment and think: when was the last time you saw engineering and product team sit down and discuss how to structure a page so that the web vitals metrics lands exactly where they want it? In most projects, performance is treated as something you bolt on later: "we'll apply the optimizations once the feature is done and the numbers will follow." But that's not always how it works, and in high-traffic, high-stakes environments, that assumption can cost you more than you'd expect: leaving money out on the table.

Running the Tests

I ran some tests. First, I tried shifting the LCP focus by improving the load performance of the main image and changing the focus. It worked, but the gain wasn't significant enough.

Then I tried something different: I increased the font size and visual weight of the main page title (which, fortunately, used very well-optimized fonts loading techniques), while reducing the font size property of the title inside the CSR-loaded content block.

.ssr_main_title {
  font-size: 72px; /* previously 56px */
}

.csr_secondary_title {
  font-size: 48px; /* previously 62px */
}

73% Improvement. Two Lines of CSS.

After a few rounds of testing, the LCP element shifted to the page's main title. The result: a 73% improvement in our LCP metric compared to previous values, and we were back in the green zone. Two lines of CSS achieved what none of the conventional optimization alternatives had managed to deliver.

The only remaining challenge was negotiating this with the rest of the team (and designers). Once they saw the numbers and understood the impact, they were on board, and we shipped the layout change to the product's home page. A design layout decision suggested by a developer.

What I want you to take away from all of this: be intentional with your metrics.

Intention Over Automation

With AI tooling and an abundance of performance resources available today, performance optimizations need to be part of the conversation from the very first wireframe and architectural decisions, not an afterthought. But here's a quiet irony worth naming: the same AI-assisted workflow that makes us more productive can also flood us with techniques, checklists, and optimization patterns all at once, and that volume of "correct answers" can actually pull our focus away from simpler, more creative insights that don't come from a checklist at all. They come from rethinking how the solution was conceived in the first place.

Plan ahead for what you want to achieve and how you'll get there, but leave room for that kind of thinking too. In my case, after reading through the documentation and following every recommended optimization path, the solution came from the simplest example in the docs: one where the technique isn't even explicitly named, just quietly implied. It was there all along just waiting to be used with intention.

4 ways to use Material UI Select with React Hook Form

Matheus Raduan — Wed, 21 Oct 2020 13:46:38 +0000

Are you confused in how to make the Select of MaterialUI works fine with React Hooks Form?

What does not work: use directly the Select component ☹️

The most advantage of use React Hook Form is to get all the benefits of work with uncontrolled components in forms like skip re-rendering and faster mount. But there are some limitations in use some components that are created to work internally like a controlled, this is the case of component Select of Material UI. In this scenario the documentation o React Hook Form indicate to use the Controller component, but there's some other ways to do the Select component work correctly without Controller component.

Lets get started with a simple Select of persons of trinity: Father, Son and Holy Spirit.

const trinityPersons = [
    { value: "father", text: "Father" },
    { value: "son", text: "Son" },
    { value: "spirit", text: "Holy Spirit" },
];

Let's import some things

import { FormControl, TextField, MenuItem } from "material-ui/core";
import { useForm } from "react-hooks-form";

First way: with Textfield component

In this first way is we can save some lines of code only working directly with the TextField component and add the select prop to made our input work like an select. Now through the prop inputProps that Material UI provide to us we can add prop directly to the select input component. Magic!

The next step is check if the ref already exist to prevent error and then create our register provided by React Hook Form. This is the more shortest way because we prevent to use the Controller and Select component directly.

return(
    <FormControl>
        <TextField
          select
          label="Choose one Person of trinity"
          id="trinity"
          inputProps={{
            inputRef: (ref) => {
              if (!ref) return;
              register({
                name: "trinityPerson",
                value: ref.value,
              });
            },
          }}
        >
         {trinityPersons.map((person) => (
              <MenuItem key={person.value} value={person.value}>
                    {person.text}
                </MenuItem>
            )}
        </TextField>
    </FormControl>
);

Second way: with Select component

This way is the same of the first way, the difference here is that we create using a more explicit syntax provided by Material UI. Now is necessary to import the Select and InputLabel component.

import { InputLabel, Select } from "@material-ui/core";

Now we create our FormControl using the Select component:

return(
    <FormControl>
        <InputLabel htmlFor="trinity-select">
            Choose one Person of trinity
        </InputLabel>
        <Select
          id="trinity-select"
          inputProps={{
            inputRef: (ref) => {
              if (!ref) return;
              register({
                name: "trinityPerson",
                value: ref.value,
              });
            },
          }}
        >
         {trinityPersons.map((person) => (
              <MenuItem key={person.value} value={person.value}>
                    {person.text}
                </MenuItem>
            )}
        </Select>
    </FormControl>
);

Even using the the explicit Select component we suffer with the way that this component was created, as I said before.

there are some limitations in use some components that are created to work internally like a controlled

Third way: with Controller component

This is the way that React Hook Form recommend us. Is the best approach and work like a magic, the Controller component do all the work.

One more thing to import:

import { Controller } from "react-hook-form";

And do not forget do use the control of useForm hook

const { register, handleSubmit, control } = useForm();

The function of Controller component is to wrapper the controlled component and make it easier for work with them. It was created to work with Material UI 💖

And now we create our Select component inside the Controller.

return(
<FormControl>
    <InputLabel htmlFor="trinity-select">
        Choose one Person of trinity
    </InputLabel>
    <Controller
    control={control}
    name="trinityPerson"
    as={
      <Select id="trinity-select">
          {trinityPersons.map((person) => (
                  <MenuItem key={person.value} value={person.value}>
                        {person.text}
                    </MenuItem>
                )}
      </Select>
    }
  />
</FormControl>
);

Last way: creating a reusable component

And even exist the component way.

We create an wrapper component that abstract all the boilerplate and expose the use just like an simple Select component.

import FormControl from "@material-ui/core/FormControl";
import InputLabel from "@material-ui/core/InputLabel";
import Select from "@material-ui/core/Select";
import { Controller } from "react-hook-form";

const ReactHookFormSelect = ({
  name,
  label,
  control,
  defaultValue,
  children,
  ...props
}) => {
  const labelId = `${name}-label`;
  return (
    <FormControl {...props}>
      <InputLabel id={labelId}>{label}</InputLabel>
      <Controller
        as={
          <Select labelId={labelId} label={label}>
            {children}
          </Select>
        }
        name={name}
        control={control}
        defaultValue={defaultValue}
      />
    </FormControl>
  );
};
export default ReactHookFormSelect;

Now you can use it in your app like this:

<ReactHookFormSelect
  id="trinity-select"
  name="trinityPerson"
  label="Choose one Person of trinity"
  control={control}
>
   {trinityPersons.map((person) => (
          <MenuItem key={person.value} value={person.value}>
                {person.text}
          </MenuItem>
    )}
</ReactHookFormSelect>

Useful links

https://github.com/react-hook-form/react-hook-form/issues/497

https://github.com/react-hook-form/react-hook-form/issues/380

https://stackoverflow.com/questions/63236951/how-to-use-material-ui-select-with-react-hook-form

https://react-hook-form.com/api#Controller

https://material-ui.com/components/text-fields/#textfield