Forem: Filip Kudla

3 layers of nextjs prefetch

Filip Kudla — Mon, 17 Feb 2025 00:03:49 +0000

Introduction

This post is sponsored by next.js... but in a bit different way. After spending a few hours connecting the right dots right after shipping the middleware feature on production and quick rollback 😬

Don't know about most of the devs but for me, it was a "shocker". Our service throughput skyrocketed right after my initial merge. It was about a 2x or 3x increase. Simply caused by the middleware file.

There is a gotcha that I want to mention at the very beginning of this article. Such "issues" are available on production app build only. I mean link prefetch "feature" in the next v14 pages router. It's a bit cumbersome and good to know ahead.

just to visualize this for you - you don't need to thank

Layer 1 - Link prefetch

I will call it a beginner-level prefetch.

One of the Link properties is prefetch.

You can create a simple wrapper around the Link component, such as a CustomLink, and opt out of this behaviour. The whole logic is to set prefetch: false as the default value in your component and then replace all usage of default Link.

import Link from 'next/link'

export const CustomLink = ({prefetch = false, ...props}) => {
  return (
    <Link
      prefetch={prefetch}
      {...props}
    />
  )
}

That's not all! A different behaviour depends on whether you use the app or pages directory.

For pages routing prefetch has a true value by default in next v15. Setting to false will work fine but there is one more disclaimer. Prefetch behaviour on hover can't be disabled with next/link.

Note: Of course, you can use the native <a> tag to disable prefetching completely but this will work only for external links.

For app directory routing we have a null value by default.

Again, this might be outdated pretty fast so make sure to check the official docs

Layer 2 - Middleware

I have found another place where you can minimize the middleware prefetch requests to the server. In middleware configuration itself!

There is a great matcher feature where we can exclude requests with prefetch headers. Let's consider the code snippet below:

{
      source:
        '/((?!api|_next/static|_next/image|favicon.ico|sitemap.xml|robots.txt).*)',
      missing: [{ type: "header", key: "purpose", value: "prefetch" }],
},

Explanation step-by-step:

Note that Regexp is a negation
It will work for not listed potential routes such as our pages
Normally it would match both prefetch and non-prefetch requests but we have added a requirement to match only those without a "prefetch" header.

This would work just fine, except for one more case - prefetch on hover. If you are fine with it you can probably pause here.

Ultimate layer 3 - experimental `middlewarePrefetch` flag

You might wonder - why it's not just optional to prefetch, right? Well, you can but we need a closer look into the source code.

https://github.com/vercel/next.js/pull/42936

Middleware comes with 2 prefetch options - strict and flexible. The second one is set by default and it "always prefetches". While the first one prefetches only "when the href explicitly matches an SSG route" which should be fine to prefetch the static generated sites.

Note: You have completely disabled prefetches if you are still using getInitialProps.

Note: If you have just a few static sites, you probably don't need to configure 2nd option to exclude prefetches. It shouldn't generate a big load on your servers.

Why does it generate all the load on our server

The answer is simple, with the middleware file we were running additional operations for ALL our requests like images, prefetches and pages which are treated as additional load. This takes time and resources so our application will scale.

Big unknown

I couldn't understand why prefetch is not happening when you are not using nextjs middleware file. Without it, it's completely normal behaviour. Looks like middleware is directly connected with this feature and mentioned load from the previous point.

Summary

There it is. 3 layers to avoid prefetch while using middleware. I can say that you might live with the 2nd option without any issues but it's also good to know how to completely shut down "prefetch".

Also, I can see the 3rd layer as part of the docs. I need to think about some PR for that 👀

Thoughts on CSS-in-JS and Utility-First CSS (Tailwind)

Filip Kudla — Sun, 26 Jan 2025 00:23:29 +0000

Recently I have had a chance to create UI a little in my work due to assessments that we run in our company. I haven't done this for a long time and apparently missed a lot.

I admit that I don't touch UI often in my daily work (now you might wonder what do I do in my job then 🤫). Plus I don't get that excited about writing some CSS styles, it is not my cup of tea.

In such a case, that was a ride, and I thought my opinion would stay as close to neutral as it could be (seriously). After using both again, one after another, in the same application, I can definitely share my few thoughts on this topic. I will skip the part about what we have achieved in our working group and focus on styling experience and tooling for now.

Tailwind

Deciding on tailwind came a bit out of nowhere. We all were more or less familiar with it, more or less sceptical but we wanted to save our time on writing stuff.

Small things matter

The integration part, along with creating custom variables and themes, was fast enough. Extending or building a new theme is very intuitive.

@import "tailwindcss";
@theme {  
  --font-script: Comic-sans; // extending theme
  --color-*: initial;  // overwriting defaults
  --color-white: #fff;
  ...
}

Also, I love it when tools have some base styles defined. Even simply disabling native margins and padding is huge. It just saves precious time and we have one problem less!

Feeling intuitive in our own stylesheets assures our flow and pushes us to keep progressing. Tailwind wants to be intuitive. It works sometimes... and sometimes not really. Take class namings.

p for padding and mb for margin-bottom - great!

For display values I would prefer display-flex, display-block etc. instead just flex and block. It's probably connected to other flexbox and grid properties.

rounded for border-radius 🤨... If you can't remember it as me. We can create a small theme twig in our theme.

@theme { 
  --border-radius: var(--rounded);
  --border-radius-none: var(--rounded-none);
  --border-radius-full: var(--rounded-full);
  // ...and so on
  --rounded*: initial;
}

Personal feelings

Readability is not as problematic as many people think. The same applies to maintainability and scalability. However, it required some time to get used to the syntax, and VsCode IntelliSense was a little too slow for me to hint proper class 😅. The code itself grows pretty well. Stays readable even with a few lines of classes for small piece of code. It's pretty easy to find what I want and edit it.

Important note: Don't think about using @apply too fast. You can end up with Tailwind-in-CSS 😐

Server side

By the way, no issues during my entire experience for our testing phase for SSR. Important factor! You can just start using it and it just works. I don't even have anything more to say there 🎉

CSS-in-JS (emotion)

Let's agree it's rather a twilight of such solutions in 2024 and 2025. Of course, this is connected with the react trend for using server components and all that.

See this link: https://nextjs.org/docs/app/building-your-application/styling/css-in-js

Underlying issue

It's probably the biggest issue nowadays, even though those were very popular tools. Most developers are looking for other solutions to avoid creating tech debt and move forward.

As CSS-in-JS relies heavily on React Context API and now your react app might have a mix of server components inside "client components" it simply loses its data and possibility to modify styles on rerender correctly. It is impossible to achieve with the same library 😞

Don't worry, there are compatible CSS-in-JS alternative libraries!

To understand the full context behind this problem, I recommend checking this article from Joshua Comeau. It is always worth checking his blog posts.

Looking back

Not sure if it deserved that amount of attention after I look back. After all, I regret shifting everything to JS in my apps.

We can agree on at least one thing there - they gave a decent developer experience (aka a lazy developer's experience) as we don't need to switch context that much. Everything can stay even within one file (I'm looking at you tailwind 👀). We loved that concept and that concept lost us.

Experience and long-term vision

It turns out that you have to do a lot of typing with that solution! And it comes together with configuration effort (btw. not only during project bootstrap). It felt way less grateful compared to Tailwind.

I still very much like the possibility of passing conditional props and all the power related to it.

const Button = styled.button<{ variant?: 'primary' | 'secondary'; }>`
  background: ${props => props.variant === 'primary' ? "#ddd" : "#fff"};
`;

render(
  <div>
    <Button variant="primary">Primary</Button>
  </div>
);

Side note it probably complicates more than helps for example in understanding the final syntax and potential refactor tho.

Speaking about refactoring it must be a real curse when you have used style overwriting too much. Plus it might be a sign for you and your designer. Example syntax below:

import { Button } from 'your-design-system-lib'

const MyFunnyButton = styled(Button)`
  margin-bottom: 3px; // 3px, really?! don't do that :')
`

Something to revisit and fix at the source. Design systems should be consistent and overwrites shouldn't be needed for atom components.

If I had to bootstrap a new project now, honestly I would pass this solution.

Variables and theming

CSS variables are probably one of the greatest things available to me. Defining a palette once and reusing it across all components is almost like selecting a predefined component variant by prop. Import one file with a project theme variables and I'm ready to go (with a small cheatsheet at the beginning ofc.)

:root {
  --main-bg-color: #ddd;
  --secondary-bg-color: #000;
  --alternative-bg-color: #fff;
}

Hussle with postprocessors and additional configs

Note: Postprocessors are plugins that run after generating your CSS file with a bundler and help optimise it. A good example could be the PostCSS tool.

Have you run your project without adding any CSS postprocessors or configs? Just a barebone CSS file? You did? You must be crazy or lazy 😒

Well, I wasn't able to run anything without them. It unlocks a lot of benefits. We can name a few now from PostCSS tool:

cssnano which deletes unused code,
nested plugin to allow using nesting similar to sass project,
stylelint... self-explanatory one
autoprefixer so you don't need to worry about it (not that relevant nowadays but still worth using)
import which allows to use @import rule like the one known from JS files

If I got your interest, the full list is available here: https://postcss.org/docs/postcss-plugins

Of course, I'm considering it as a slowdown to the project and baggage to maintain. We are making a trade with ourselves to invest some time now and get better developer experience together with good stylesheet performance.

Imagine having all those autoprefixes, dead code elimination and modification out of the box without adding a single line.

Lightning CSS

The feeling I have mentioned is potentially the goal of another tool. Lightning CSS. Yes, it's in Rust 🙄 but more about that trend in another blog post.

Anyway, if you are looking for a well-packed alternative to PostCSS with improved build times, you should take a look at this tool.

Most necessary tools are included and configurable like vendor prefixes, nesting, source maps, modifications, browser targets and modern CSS syntax.

Summary

It's great to see changes happening in CSS tools and an even more bright future with CSS tools with RSC support (at least for some of them). My overall experience with these tools was more or less accurate. I haven't completely lost touch with them and it was very easy to come back which is positive!

If you think about it. This new approach makes a big impact. We needed to consider this even in CSS-related blog posts. This will impact our future toolset for projects as well. Is it a bad thing? There is only one way to figure this out 😌

Observability (o11y) purpose

Filip Kudla — Wed, 25 Dec 2024 00:39:15 +0000

Warmup

Introduction

Imagine you set a goal in your life to be at the Olympics. You are not yet sure why but let’s see how it goes. Of course, you also have prepared a plan B to just show up at your local gym at least once a week.

Remember what managers repeat - Goals should be ambitious and realistic. We take the second part seriously 😇

Anyway, you have started training regularly. Over time you are introducing little tweaks into your life here and there. You think it should improve or at least help in your initial goal. After some time, you have got that weird feeling. Something is wrong. Even if you are doing workouts regularly. What did we miss?

Step back

Context

It appears that we forgot about almost, well… everything 😅

Speaking in programming language for a moment - our app is live… but that’s it.

Let me show you a few areas that we have missed.

We didn’t track anything. As youngsters say - pics or didn't happen.

We don’t know if we can do more repeats over time or if we can increase the weights (metrics and monitoring - this post focus by the way).
We don’t track our progress with some note or gym app (logs and perf budgets)
We don’t know about our potential mistakes during workouts. We are doing exercises as we see them. Yes, we have a big imagination (error monitoring/tracking).

Also a few more but I’m out of analogies for now.

Basically, you just go there. I’m not even sure if you were training or just staring at your phone the whole time. Did you? 🤨

marathon

historical data

If we want to survive, we have to analyze. This knowledge can be crucial if we want to head into the right direction. Historical data for the rescue!

How are you going to validate your training plan?

I would start with workout notes (there are apps for that already, you don’t need another side project 😒). Eventually “flex” image from the gym can work as well. Regular weight checks are a must-have.

This unlocks better observations. It works the same way with our application. We can compare metrics, set milestones and make long-term predictions, plans and analyses.

It’s a common concept to set alert conditions when some part is crucial for you. Like setting a clock to avoid sleeping through. On the other hand, you can observe your heartbeat during a workout same as you would set up some dashboards with base metrics.

Usually, you have some industry standards set up that are represented by metrics. You want to follow them and keep them within your scope of interests. Web vitals metrics are a good example there. The same goes for the gym world with different techniques available and just a few of them might interest you depending on what is your goal.

In the end, you build good habits around the workout. It’s healthier, motivating and productive. Over time you can introduce your custom metrics if we build strong ground level.

our pace

metrics

I have mentioned metrics. I meant that we can develop our tailored area of interest. We can depend on delivered statistics to define our condition and crossbar level.

After first failures and regrets, we can also define our border lines that we shouldn't cross. We can agree with ourselves that we will go to the gym at least twice a week (our SLA - Service Level Agreement here). Usually, it's also a good habit to define a penalty for crossing this line and tell somebody about it so we can convince ourselves to respect it. In job, it’s usually our stakeholder or customer.

In general, we can agree on some error degree per month for our application. Otherwise, you have to reconsider the problem and follow it to the root. This should be defined clearly for everyone. SLOs (service-level objectives) come in handy for that.

For example, we expect to train for at least 1 hour per visit 80% of the time during the last month. In other words, we agree that some of our training can be short due to unknown circumstances.

Or we declare to do a full body workout once a month and focus on different body parts (up to 2) every other workout.

Improvement plans

Based on the historical data that you were able to collect you should rethink if it's worth going there in your case. I mean you really rock this Candy Crush saga game between exercises but after a few months, you should be able to do more than 5 push-ups 😒

Jokes aside you should probably consider defining some budget for your app. For example, you want to keep (or reach) your app on the green zone score for CLS value based on webvital report.

With such information, you can plan to improve that value in the next quarter. This can include investigation, planning&consultation and implementation part. After introducing improvements you can revisit your stats again and verify the results. By the way - great OKR example!

source: https://web.dev/articles/cls

Is profiling and performance measurements still an observability part?

I would say it's the same area of interest with a different scope. Usually, we want to observe some metrics constantly. This allows us to compare results from the past. Profiling is usually used to find other kinds of problems with application tasks or registered processes/tasks.

Usually, running perf profiling on production is expensive in terms of resources used. The impact on our app might be noticeable, so make sure you run it only on a small subset of your production. One or a few application pods should be enough data for you.

On the other hand performance measurements can probably be partially automated and collect metrics periodically.

To know which one to choose we need to know how low-level our problem is. Performance tests should address some more generic purpose while profiling can help investigate certain problems and find root causes instead. The most generic example would be increased memory usage over time. Most of the time it's caused by a bug on our end.

It's good to think about the perf layer after your app has other more common observability data already available. Not a first line of debugging problems.

How does observability help in the team's work?

Of course, we need to assume that the data we collect is valuable for us. Universal example - collecting production errors.

After we release our code on production we should be promptly informed that something is wrong. With data in hand, the team can take action. For example, rollback and prepare a fix, notify others about problems or both 😃

The same goes for any other data and applies to various angles of help. Based on that, we can plan, make decisions and build the next iterations. It is like building a foundation.

It took me a while to make a decent analogy for that. I came up with this one for now.

It can be understood as another good habit for a healthier life. At the same time, a healthy life is built from many small chunks. One is our diet another is workout consistency, our routine, nature and even motivation. We can get the best and fastest results when we put everything together. We can notice very quickly if something gets off-track.

shared responsibility

Allowing others to check what's up with our app can be very beneficial. This can enable us to delegate stuff outside instead of making every improvement ourselves. With such an approach, we maintain a clear and healthy responsibility split. Everybody can gain from it. Let's try with analogy to this part.

Certain exercises will target selected muscles or one part of the body. Also, we can't do only one exercise for a whole training and expect different results. It's good to plan what we will do in the gym and use the proper tools/exercises to target our goal. We could do everything alone but a coach can introduce us way faster.

Coach can be understood in two ways. One is a dedicated observability team that can support you when you need anything. Second, is a custom dashboard which can keep team-scoped queries in one place.

If you have an observability team in your organization, it can work way better. They should provide the feedback you need for the things you want. Cooperation with such teams can lead only to good outcomes. Sharing knowledge with them is paying back in the long term as more people will learn and observe the app.

There is another side of the coin tho. Don't try to store too much data in your dashboards. Otherwise, you can lose your service visibility and don't know what is going on when you observe "too much".

Of course, "too much" is a very generic term. Dashboards should suggest which part is worth debugging and be informative instead scream at you that something is on fire.

Finish… or just a beginning

We have briefly touched on the observability topic. A bit unusual way. At least I hope it was original.

Quick recap! I have tried to present the main observability topics there. Those can be treated as our signs of discovery. We should know where to head next.

I hope I will describe some topics more and better in future posts. Especially the part about shared responsibility, example data to track/not track and how to avoid noise in the dashboards.
Who knows, maybe even with extended technical coverage and fewer analogies. It depends on my creativity 🤞 For now, let me know if such a format is readable.

SVG hacks for you

Filip Kudla — Sun, 22 Dec 2024 00:26:19 +0000

I got motivated by Bytes #293 main thing about HTML. Their motivation came from State of HTML 2023 survey (and money... but let's leave the sponsored section from mailing).

It appears that <svg> elements are notable pain points in their daily work. It was brought in the "Content section"

Entry point

If you are not familiar with this stuff at all, I can help with a bunch of links for the start. After that, nothing will change but you will know something more about svg
¯\_(ツ)_/¯

Tl;DR

SVG elements are vector graphic elements. This can be understood as a bunch of geometric figures represented in characters. You can create one for example with Adobe Illustrator or Inkscape as a free alternative.

Starting point

From people's answers, we can see a few patterns. I won't pick any specific one but I will try to share some knowledge around those topics so you can find here some tips&tricks, sharing experience and other common knowledge around this topic.

I will skip the SVG sprites topic like this example. It's a separate topic and is not very connected to the svg tag. I can just agree that you could still find a few rare use cases for them.

File syntax

A proper SVG file should be a representation of the mentioned geometric figures. It's very easy to check if our icon is prepared in the right format by the designer or website where you are taking it.

Wrong example:

<svg ...><image link:href="data:image/png;base64 .../>

Expected syntax:

<svg><g><path r=""/><circle /></g></svg>

During my career, I stepped into this a few times. It's worth to remember that. It happens when you take raster graphics, import them to a vector graphic program and try to export them in .svg extension. It does not magically convert your image to a vector graphic.

Notable SVG tags

I can present you a cheat sheet for most generic svg elements.

Tag	Description	Animated attributes
`<g>`	used for grouping elements	-
`<path />`	main tag for your actual icon. Avoid modifying the `d=""` attribute on your own 😬 It is possible but be careful with that. Grab a link with an explanation for each character group. To animate your path use animateMotion tag	-
`<rect />`	Basic rectangle shape in SVG. Simple as that	✅
`<line />`	Simple as that. The line between two points. Don't mistake with the `stroke` attribute! It can also be used on the line tag.	✅
`<defs />`	You can think about it as an enhancement version of the `g` tag but it keeps the elements inside invisible for later use with, let's guess it... `use` tag	-
`<circle />`	Next basic shape. Be careful as the size is defined by radius and you position your circle with `cx` and `cy` attributes.	✅
`<polygon />`	Let's call it a custom shape. They are connected straight lines where the last point connects to the first point.	✅
`<polyline />`	Very similar to the previous one but with a notable difference. The last point doesn't need to be connected to the first point.	✅

Please note those are only a few selected SVG elements. I have just described the most common ones. There are a lot more available for you to use. A full list can be found here.

Sizing and positioning

As we are now familiar with some of the common svg tags we can go into the next paragraph of modifying the base parameters of our icon.

Let's say we work with a young designer. He/She doesn't fully know how to prepare things for the web yet as you do. As a result, you sometimes get slightly different sizes of an icon with missing cut padding on the sides.

good one	wrong one

Classic case. I know we should have a quick call with a designer and clarify this but we want to learn some svg here. We are not doing that in this scenario. We can fix it ourselves.

From the code perspective, it's all about attributes. The original SVG cross file looks like this:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->

<svg
   width="93.582886"
   height="93.582893"
   viewBox="0 0 24.760471 24.760474"
   version="1.1"
   id="svg1"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:svg="http://www.w3.org/2000/svg">
  <defs
     id="defs1" />
  <g
     id="layer1"
     transform="translate(-13.964461,-14.49055)">
    <rect
       style="display:inline;fill:#000000;stroke-width:0.257843"
       id="rect2"
       width="31.409456"
       height="3.175"
       x="-16.658115"
       y="36.031288"
       transform="rotate(-45.885349)" />
    <rect
       style="display:inline;fill:#000000;stroke-width:0.257843"
       id="rect3"
       width="31.409456"
       height="3.175"
       x="21.914061"
       y="-0.63411272"
       transform="rotate(44.114651)" />
  </g>
</svg>

This is our raw svg exported from Inkscape. There are a few other things to fix, bear with me so we can fix them.

We know that 200px image is our goal. Here we have some ugly width/height values on the main svg tag.

Simply:

<svg
-   width="93.582886"
+   width="200"
-   height="93.582893"
+   height="200"

Results in:

Almost what we want! Let's dig further into how we can preserve padding as in the first icon.

We have 2 options. We can keep the same viewBox value or we can adjust each width, height, x and y value on every nested tag.

The first option seems simple and it works for us quite well but there might be a catch. In my case, I had this weird transform attribute on my group tag.

<g id="layer1" transform="translate(-13.964461,-14.49055)">

After removing it the result is pretty good now:

step1 - add `viewBox`	step2 - remove `transform`

Universal width/height

We don't need to define width and height upfront to our icon. We can avoid overwriting it each time from 200px to 32px - let's treat it as an implementation detail. In that case, we can update our icon as follows:

<svg
-   width="200"
-   height="200"
    viewBox="0 0 50 50"

Now our icon size is adjustable. Please note that it's vector graphics so we don't lose icon quality after resizing.

So why is viewBox so important?

It's the key when we want to correctly scale or set a certain position to our icon. It has 4 arguments viewBox="min-x min-y width height".

For example, viewBox="0 0 100 100" means the top-left corner is at (0, 0) and the viewBox is 100 units wide and 100 units high.

That means you have to adjust your icon x and y attributes after changing viewBox as they are set according to their value.

Managing colors and fill

Different icons allow different fill. Of course, it can be as easy as adding a color style but that's a rookie-level type of code.

Real developers are adding fill-rule="evenodd" to the main element and deleting all other manual fill attributes from tags 😎

You may wonder why.

I will provide the shortest possible answer to this. To freely customize our icon colours with one line of code straight from our IDE.

How is that possible you might ask.

If you are dealing with a simple icon from your company's design system you should be able to import only one icon. Modifiers or duplications in size or colour are not necessary.

From a code perspective, you just have to add fill on the svg element like you would normally do with for example colour attribute.

svg#close {
  fill: #ddd;
}

There is a catch for evenodd value which applies when you are drawing polygons or paths. It will fill only the inside of crossing path segments.

Consider analyzing this example in case you struggle with it.

So in the case of our cross icon, it will result in something like this:

Optimizing

Before we publish our icon to the web (or right after we download it from Figma) we should ensure it's properly optimized. This one is very important. I have caught and been caught way too many times during code review on this last mile.

SVGO (or SVGR for react) is making it a very easy process. Behind the scenes, it mostly deletes all unnecessary stuff for us.

In general, it is a go-to tool. Either you want to integrate it with your bundler or use it from CLI. It's ready to use right after installation as we get default preset configured out of the box.

Note: You can overwrite the default preset if you really want to. Check configuration in the project README and plugin list in docs

Result

The final icon code looks like this:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 50 50"><g fill-rule="evenodd"><path d="M9 24h32v3H9z" style="display:inline;stroke-width:.25" transform="rotate(135)" transform-origin="center"/><path d="M8 24h32v3H8z" style="display:inline;stroke-width:.25" transform="rotate(45)" transform-origin="center"/></g></svg>

We have reduced the size from 871 bytes with raw icon exported from inkspace to only 322 bytes.

Pain with animations

The last topic that is bitter-sweet for me. It was brought in the survey answers a couple of times as well. I don't know better ways to do it except using Lottie or manually animating elements of SVG in CSS. The second option is absolute torture when you have more than 5 elements to animate.

Of course, it is possible and we can do it but being honest, there are more interesting things to do 🙈

Suppose you are still curious about how to do it. I'm leaving a link to a great article here. It should convince you that it requires patience and takes more than 5 minutes. I wonder if an AI bot can help you with that! If yes, maybe it's a bit less painful.

That's it for now.
Hopefully, you took something from this post and have a nice day 🍀

Forem: Filip Kudla

3 layers of nextjs prefetch

Introduction

Layer 1 - Link prefetch

Layer 2 - Middleware

Ultimate layer 3 - experimental middlewarePrefetch flag

Why does it generate all the load on our server

Big unknown

Summary

Thoughts on CSS-in-JS and Utility-First CSS (Tailwind)

Tailwind

Small things matter

Personal feelings

Server side

CSS-in-JS (emotion)

Underlying issue

Looking back

Experience and long-term vision

Variables and theming

Hussle with postprocessors and additional configs

Lightning CSS

Summary

Observability (o11y) purpose

Warmup

Step back

marathon

our pace

Improvement plans

Is profiling and performance measurements still an observability part?

How does observability help in the team's work?

shared responsibility

Finish… or just a beginning

SVG hacks for you

Entry point

Starting point

File syntax

Notable SVG tags

Sizing and positioning

Universal width/height

Managing colors and fill

Optimizing

Result

Pain with animations

Ultimate layer 3 - experimental `middlewarePrefetch` flag