Netlify Edge Functionsはネットワークエッジで実行されるサーバーレス関数で、ユーザーのリクエストにウェブサイトが応答する前にコンテンツをパーソナライズし、認証を処理し、ルーティングロジックを実装します。以前はこれらの関数はサードパーティがホストするプラットフォーム上でV8 JavaScriptアイソレートで動作しており、これによりNetlifyはランタイム環境とインフラストラクチャコストをコントロールする能力が制限されていました。2025年後半から、NetlifyはUnikraftプロジェクトと提携し、このアーキテクチャをUnikraft駆動のマイクロVM上で動作するEdge Functionsを含むNetlify自身のエッジコンピューティングインフラストラクチャ内の新しいシステムに置き換え始めました。
新しいリクエストフローはNetlifyのネットワーク内で完全に処理されます：エッジノードがリクエストを受信し、TLS接続を終了し、一致するルートをチェックし、外部サービスに送信する代わりに内部コンピューティングノードに転送します。各Edge Functionは隔離されたマイクロVM内で実行され、Unikraftの特殊なユニカーネルを利用して特定のワークロードに最適化された最小限のLinux環境を99パーセンタイルで2ms未満で起動します。パフォーマンスデータによると、中央値のウォームインボケーション時間は25-40ミリ秒から5-6ミリ秒に減少し、5倍の改善を達成しながら99.998%の可用性と5倍速いEdge Functionログ配信も実現しました。
この画像は記事で説明されているリクエストフローを示しており、エッジノードがリクエストを内部コンピューティングノードに転送し、そこにあるMicroVMでEdge Functionを実行します。
このグラフは記事で引用されている性能データを視覚化し、中央値レイテンシが25–40 msから5–6 msに減少したことを示しています。
記事の説明に一致し、エッジノードが一致するルートをチェックし、外部サービスではなく内部コンピューティングノードに転送する様子を示しています。
重要な点として、この変更では開発者側での修正は必要ありません。既存のEdge FunctionsはURLインポート、npmパッケージ、Node.js組み込み、netlify.toml宣言を変更せずにそのまま機能し続けます。この移行によりNetlifyはEdge Functionsランタイムへの完全な権限を獲得し、サードパーティの制約された環境では不可能だったネイティブnpmパッケージサポートやファイルシステムアクセスなどの機能を可能にします。ただし、以前未使用の地理的領域での関数の初期（コールド）インボケーションは、コンテナイメージのフェッチが必要なため平均して約9msかかり、リクエストの約1.2%に影響します。Netlifyはこのコールドスタート遅延を、大多数のEdge Functionトラフィックに対してもたらす大きな性能向上とのトレードオフとして受け入れ可能であると特徴づけています。
記事のコールドインボケーションでコンテナイメージのフェッチが必要となり、リクエストの約1.2%に影響する点に関連しています。