Menghindari Jebakan Kode yang Digarisbawahi Secara Otomatis

Inlining adalah proses memasukkan konten file secara langsung ke dalam dokumen HTML: File CSS dapat dimasukkan ke dalam elemen style , dan file JavaScript dapat dimasukkan ke dalam elemen script :

 <style> /* CSS contents here */ </style> <script> /* JS contents here */ </script>

Dengan mencetak kode yang sudah ada di output HTML, inlining menghindari permintaan pemblokiran render dan mengeksekusi kode sebelum halaman dirender. Dengan demikian, ini berguna untuk meningkatkan kinerja situs yang dirasakan (yaitu waktu yang diperlukan agar halaman dapat digunakan.) Misalnya, kita dapat menggunakan buffer data yang dikirimkan segera saat memuat situs (sekitar 14kb) ke inline gaya kritis, termasuk gaya konten paruh atas (seperti yang telah dilakukan di situs Smashing Magazine sebelumnya), dan ukuran font serta lebar dan tinggi tata letak untuk menghindari rendering ulang tata letak yang tidak stabil saat data lainnya dikirimkan .

Namun, ketika berlebihan, kode inlining juga dapat memiliki efek negatif pada kinerja situs: Karena kode tidak dapat di-cache, konten yang sama dikirim ke klien berulang kali, dan tidak dapat di-cache sebelumnya melalui Service Worker, atau di-cache dan diakses dari Jaringan Pengiriman Konten. Selain itu, skrip sebaris dianggap tidak aman saat menerapkan Kebijakan Keamanan Konten (CSP). Kemudian, itu membuat strategi yang masuk akal untuk menyelaraskan bagian-bagian penting dari CSS dan JS yang membuat situs memuat lebih cepat tetapi sebisa mungkin dihindari.

Dengan tujuan menghindari inlining, dalam artikel ini kita akan mengeksplorasi cara mengonversi kode sebaris menjadi aset statis: Alih-alih mencetak kode dalam output HTML, kita menyimpannya ke disk (secara efektif membuat file statis) dan menambahkan <script> yang sesuai <script> atau <link> untuk memuat file.

Mari kita mulai!

Bacaan yang disarankan : Keamanan WordPress Sebagai Proses

Kapan Harus Menghindari Inlining

Tidak ada resep ajaib untuk menentukan apakah beberapa kode harus disisipkan atau tidak, namun, ini bisa menjadi sangat jelas ketika beberapa kode tidak boleh digarisbawahi: ketika melibatkan sebagian besar kode, dan ketika tidak diperlukan segera.

Sebagai contoh, situs WordPress memasukkan template JavaScript untuk merender Media Manager (dapat diakses di halaman Perpustakaan Media di bawah /wp-admin/upload.php ), mencetak sejumlah besar kode:

Menempati 43kb penuh, ukuran potongan kode ini tidak dapat diabaikan, dan karena berada di bagian bawah halaman, kode ini tidak diperlukan segera. Oleh karena itu, masuk akal untuk menyajikan kode ini melalui aset statis atau mencetaknya di dalam output HTML.

Mari kita lihat selanjutnya bagaimana mengubah kode inline menjadi aset statis.

Memicu Pembuatan File Statis

Jika konten (yang akan disisipkan) berasal dari file statis, maka tidak banyak yang dapat dilakukan selain hanya meminta file statis tersebut alih-alih menyisipkan kode.

Namun, untuk kode dinamis, kita harus merencanakan bagaimana/kapan menghasilkan file statis dengan isinya. Misalnya, jika situs menawarkan opsi konfigurasi (seperti mengubah skema warna atau gambar latar belakang), kapan file yang berisi nilai baru harus dibuat? Kami memiliki peluang berikut untuk membuat file statis dari kode dinamis:

1. Dalam permintaan
   Saat pengguna mengakses konten untuk pertama kalinya.
2. Dalam perubahan
   Ketika sumber untuk kode dinamis (misalnya nilai konfigurasi) telah berubah.

Mari kita pertimbangkan berdasarkan permintaan terlebih dahulu. Pertama kali pengguna mengakses situs, misalkan melalui /index.html , file statis (misalnya header-colors.css ) belum ada, jadi harus dibuat dulu. Urutan acaranya adalah sebagai berikut:

1. Pengguna meminta /index.html ;
2. Saat memproses permintaan, server memeriksa apakah file header-colors.css ada. Karena tidak, ia memperoleh kode sumber dan menghasilkan file pada disk;
3. Ini mengembalikan respons ke klien, termasuk tag <link rel="stylesheet" type="text/css" href="/staticfiles/header-colors.css">
4. Peramban mengambil semua sumber daya yang disertakan dalam laman, termasuk header-colors.css ;
5. Pada saat itu file ini ada, jadi disajikan.

Namun, urutan peristiwa juga bisa berbeda, yang mengarah ke hasil yang tidak memuaskan. Contohnya:

1. Pengguna meminta /index.html ;
2. File ini sudah di-cache oleh browser (atau proxy lain, atau melalui Service Worker), sehingga permintaan tidak pernah dikirim ke server;
3. Peramban mengambil semua sumber daya yang disertakan dalam laman, termasuk header-colors.css . Gambar ini, bagaimanapun, tidak di-cache di browser, sehingga permintaan dikirim ke server;
4. Server belum membuat header-colors.css (misalnya baru saja dimulai ulang);
5. Ini akan mengembalikan 404.

Atau, kita dapat membuat header-colors.css bukan saat meminta /index.html , tetapi saat meminta /header-colors.css itu sendiri. Namun, karena file ini awalnya tidak ada, permintaan sudah diperlakukan sebagai 404. Meskipun kami dapat meretasnya, mengubah header untuk mengubah kode status menjadi 200, dan mengembalikan konten gambar, ini adalah cara yang buruk dalam melakukan sesuatu, jadi kami tidak akan menerima kemungkinan ini (kami jauh lebih baik dari ini!)

Itu hanya menyisakan satu pilihan: menghasilkan file statis setelah sumbernya berubah.

Membuat File Statis Saat Sumber Berubah

Harap perhatikan bahwa kami dapat membuat kode dinamis dari sumber yang bergantung pada pengguna dan bergantung pada situs. Misalnya, jika tema memungkinkan untuk mengubah gambar latar belakang situs dan opsi tersebut dikonfigurasi oleh admin situs, maka file statis dapat dibuat sebagai bagian dari proses penerapan. Di sisi lain, jika situs mengizinkan penggunanya untuk mengubah gambar latar belakang untuk profil mereka, maka file statis harus dibuat saat runtime.

Singkatnya, kami memiliki dua kasus ini:

1. Konfigurasi Pengguna
   Proses harus dipicu ketika pengguna memperbarui konfigurasi.
2. Konfigurasi Situs
   Proses harus dipicu saat admin memperbarui konfigurasi untuk situs, atau sebelum menyebarkan situs.

Jika kami mempertimbangkan dua kasus secara independen, untuk #2 kami dapat merancang proses pada tumpukan teknologi apa pun yang kami inginkan. Namun, kami tidak ingin menerapkan dua solusi yang berbeda, tetapi solusi unik yang dapat menangani kedua kasus tersebut. Dan karena dari #1 proses untuk menghasilkan file statis harus dipicu di situs yang sedang berjalan, maka sangat penting untuk merancang proses ini di sekitar tumpukan teknologi yang sama dengan yang dijalankan situs.

Saat merancang proses, kode kita perlu menangani keadaan spesifik dari #1 dan #2:

• Versi
  File statis harus diakses dengan parameter "versi", untuk membatalkan file sebelumnya saat membuat file statis baru. Sementara #2 hanya dapat memiliki versi yang sama dengan situs, #1 perlu menggunakan versi dinamis untuk setiap pengguna, mungkin disimpan dalam database.
• Lokasi file yang dihasilkan
  #2 menghasilkan file statis unik untuk seluruh situs (mis /staticfiles/header-colors.css ), sedangkan #1 membuat file statis untuk setiap pengguna (mis. /staticfiles/users/leo/header-colors.css ).
• Peristiwa pemicu
  Sementara untuk #1 file statis harus dieksekusi pada saat runtime, untuk #2 juga dapat dieksekusi sebagai bagian dari proses build di lingkungan staging kami.
• Penyebaran dan distribusi
  File statis di #2 dapat diintegrasikan dengan mulus di dalam bundel penerapan situs, tanpa menghadirkan tantangan; file statis di # 1, bagaimanapun, tidak bisa, jadi proses harus menangani masalah tambahan, seperti beberapa server di belakang penyeimbang beban (akankah file statis dibuat hanya di 1 server, atau di semua server, dan bagaimana caranya?).

Mari kita merancang dan mengimplementasikan proses selanjutnya. Untuk setiap file statis yang akan dihasilkan, kita harus membuat objek yang berisi metadata file, menghitung kontennya dari sumber dinamis, dan akhirnya menyimpan file statis ke disk. Sebagai kasus penggunaan untuk memandu penjelasan di bawah ini, kami akan membuat file statis berikut:

1. header-colors.css , dengan beberapa gaya dari nilai yang disimpan dalam database
2. welcomeuser-data.js , berisi objek JSON dengan data pengguna di bawah beberapa variabel: window.welcomeUserData = {name: "Leo"}; .

Di bawah ini, saya akan menjelaskan proses untuk menghasilkan file statis untuk WordPress, di mana kita harus mendasarkan tumpukan pada fungsi PHP dan WordPress. Fungsi untuk menghasilkan file statis sebelum penerapan dapat dipicu dengan memuat halaman khusus yang mengeksekusi kode pendek [create_static_files] seperti yang telah saya jelaskan di artikel sebelumnya.

Bacaan yang direkomendasikan lebih lanjut : Menjadikan Service Worker: Studi Kasus

Mewakili File Sebagai Objek

Kita harus memodelkan file sebagai objek PHP dengan semua properti yang sesuai, sehingga kita dapat menyimpan file pada disk di lokasi tertentu (misalnya di bawah /staticfiles/ atau /staticfiles/users/leo/ ), dan mengetahui cara meminta file akibatnya. Untuk ini, kami membuat antarmuka Resource yang mengembalikan metadata file (nama file, dir, ketik: “css” atau “js”, versi, dan dependensi pada sumber daya lain) dan kontennya.

 interface Resource { function get_filename(); function get_dir(); function get_type(); function get_version(); function get_dependencies(); function get_content(); }

Untuk membuat kode dapat dipelihara dan dapat digunakan kembali, kami mengikuti prinsip SOLID, di mana kami menetapkan skema pewarisan objek untuk sumber daya untuk menambahkan properti secara bertahap, mulai dari kelas abstrak ResourceBase dari mana semua implementasi Sumber Daya kami akan mewarisi:

 abstract class ResourceBase implements Resource { function get_dependencies() { // By default, a file has no dependencies return array(); } }

Mengikuti SOLID, kami membuat subclass setiap kali properti berbeda. Seperti yang dinyatakan sebelumnya, lokasi file statis yang dihasilkan, dan versi untuk memintanya akan berbeda tergantung pada file tentang pengguna atau konfigurasi situs:

 abstract class UserResourceBase extends ResourceBase { function get_dir() { // A different file and folder for each user $user = wp_get_current_user(); return "/staticfiles/users/{$user->user_login}/"; } function get_version() { // Save the resource version for the user under her meta data. // When the file is regenerated, must execute `update_user_meta` to increase the version number $user_id = get_current_user_id(); $meta_key = "resource_version_".$this->get_filename(); return get_user_meta($user_id, $meta_key, true); } } abstract class SiteResourceBase extends ResourceBase { function get_dir() { // All files are placed in the same folder return "/staticfiles/"; } function get_version() { // Same versioning as the site, assumed defined under a constant return SITE_VERSION; } }

Terakhir, pada level terakhir, kita mengimplementasikan objek untuk file yang ingin kita buat, menambahkan nama file, jenis file, dan kode dinamis melalui fungsi get_content :

 class HeaderColorsSiteResource extends SiteResourceBase { function get_filename() { return "header-colors"; } function get_type() { return "css"; } function get_content() { return sprintf( " .site-title a { color: #%s; } ", esc_attr(get_header_textcolor()) ); } } class WelcomeUserDataUserResource extends UserResourceBase { function get_filename() { return "welcomeuser-data"; } function get_type() { return "js"; } function get_content() { $user = wp_get_current_user(); return sprintf( "window.welcomeUserData = %s;", json_encode( array( "name" => $user->display_name ) ) ); } }

Dengan ini, kami telah memodelkan file sebagai objek PHP. Selanjutnya, kita perlu menyimpannya ke disk.

Menyimpan File Statis Ke Disk

Menyimpan file ke disk dapat dengan mudah dilakukan melalui fungsi asli yang disediakan oleh bahasa tersebut. Dalam kasus PHP, ini dicapai melalui fungsi fwrite . Selain itu, kami membuat kelas utilitas ResourceUtils dengan fungsi yang menyediakan jalur absolut ke file di disk, dan juga jalurnya relatif ke root situs:

 class ResourceUtils { protected static function get_file_relative_path($fileObject) { return $fileObject->get_dir().$fileObject->get_filename().".".$fileObject->get_type(); } static function get_file_path($fileObject) { // Notice that we must add constant WP_CONTENT_DIR to make the path absolute when saving the file return WP_CONTENT_DIR.self::get_file_relative_path($fileObject); } } class ResourceGenerator { static function save($fileObject) { $file_path = ResourceUtils::get_file_path($fileObject); $handle = fopen($file_path, "wb"); $numbytes = fwrite($handle, $fileObject->get_content()); fclose($handle); } }

Kemudian, setiap kali sumber berubah dan file statis perlu dibuat ulang, kita mengeksekusi ResourceGenerator::save dengan meneruskan objek yang mewakili file sebagai parameter. Kode di bawah ini membuat ulang, dan menyimpan pada disk, file "header-colors.css" dan "welcomeuser-data.js":

 // When need to regenerate header-colors.css, execute: ResourceGenerator::save(new HeaderColorsSiteResource()); // When need to regenerate welcomeuser-data.js, execute: ResourceGenerator::save(new WelcomeUserDataUserResource());

Setelah ada, kita dapat mengantrekan file untuk dimuat melalui <script> dan <link> .

Mengantrekan File Statis

Mengantrekan file statis tidak berbeda dengan mengantrekan sumber daya apa pun di WordPress: melalui fungsi wp_enqueue_script dan wp_enqueue_style . Kemudian, kami hanya mengulangi semua instance objek dan menggunakan satu kait atau yang lain tergantung pada nilai get_type() mereka menjadi "js" atau "css" .

Kami pertama-tama menambahkan fungsi utilitas untuk menyediakan URL file, dan untuk memberi tahu jenisnya apakah JS atau CSS:

 class ResourceUtils { // Continued from above... static function get_file_url($fileObject) { // Add the site URL before the file path return get_site_url().self::get_file_relative_path($fileObject); } static function is_css($fileObject) { return $fileObject->get_type() == "css"; } static function is_js($fileObject) { return $fileObject->get_type() == "js"; } }

Sebuah instance dari kelas ResourceEnqueuer akan berisi semua file yang harus dimuat; ketika dipanggil, fungsinya enqueue_scripts dan enqueue_styles akan melakukan enqueuing, dengan menjalankan fungsi WordPress yang sesuai ( wp_enqueue_script dan wp_enqueue_style masing-masing):

 class ResourceEnqueuer { protected $fileObjects; function __construct($fileObjects) { $this->fileObjects = $fileObjects; } protected function get_file_properties($fileObject) { $handle = $fileObject->get_filename(); $url = ResourceUtils::get_file_url($fileObject); $dependencies = $fileObject->get_dependencies(); $version = $fileObject->get_version(); return array($handle, $url, $dependencies, $version); } function enqueue_scripts() { $jsFileObjects = array_map(array(ResourceUtils::class, 'is_js'), $this->fileObjects); foreach ($jsFileObjects as $fileObject) { list($handle, $url, $dependencies, $version) = $this->get_file_properties($fileObject); wp_register_script($handle, $url, $dependencies, $version); wp_enqueue_script($handle); } } function enqueue_styles() { $cssFileObjects = array_map(array(ResourceUtils::class, 'is_css'), $this->fileObjects); foreach ($cssFileObjects as $fileObject) { list($handle, $url, $dependencies, $version) = $this->get_file_properties($fileObject); wp_register_style($handle, $url, $dependencies, $version); wp_enqueue_style($handle); } } }

Terakhir, kita membuat instance objek kelas ResourceEnqueuer dengan daftar objek PHP yang mewakili setiap file, dan menambahkan hook WordPress untuk menjalankan enqueuing:

 // Initialize with the corresponding object instances for each file to enqueue $fileEnqueuer = new ResourceEnqueuer( array( new HeaderColorsSiteResource(), new WelcomeUserDataUserResource() ) ); // Add the WordPress hooks to enqueue the resources add_action('wp_enqueue_scripts', array($fileEnqueuer, 'enqueue_scripts')); add_action('wp_print_styles', array($fileEnqueuer, 'enqueue_styles'));

Itu saja: Menjadi enqueued, file statis akan diminta saat memuat situs di klien. Kami telah berhasil menghindari pencetakan kode sebaris dan sebagai gantinya memuat sumber daya statis.

Selanjutnya, kita dapat menerapkan beberapa peningkatan untuk peningkatan kinerja tambahan.

Bacaan yang disarankan : Pengantar Pengujian Otomatis Plugin WordPress Dengan PHPUnit

Bundel File Bersama

Meskipun HTTP/2 telah mengurangi kebutuhan untuk bundling file, itu masih membuat situs lebih cepat, karena kompresi file (misalnya melalui GZip) akan lebih efektif, dan karena browser (seperti Chrome) memiliki overhead yang lebih besar untuk memproses banyak sumber daya .

Sekarang, kami telah memodelkan file sebagai objek PHP, yang memungkinkan kami untuk memperlakukan objek ini sebagai input ke proses lain. Secara khusus, kami dapat mengulangi proses yang sama di atas untuk menggabungkan semua file dari jenis yang sama bersama-sama dan menyajikan versi yang dibundel alih-alih semua file independen. Untuk ini, kami membuat fungsi get_content yang hanya mengekstrak konten dari setiap sumber daya di bawah $fileObjects , dan mencetaknya lagi, menghasilkan agregasi semua konten dari semua sumber daya:

 abstract class SiteBundleBase extends SiteResourceBase { protected $fileObjects; function __construct($fileObjects) { $this->fileObjects = $fileObjects; } function get_content() { $content = ""; foreach ($this->fileObjects as $fileObject) { $content .= $fileObject->get_content().PHP_EOL; } return $content; } }

Kita dapat menggabungkan semua file menjadi file bundled-styles.css dengan membuat kelas untuk file ini:

 class StylesSiteBundle extends SiteBundleBase { function get_filename() { return "bundled-styles"; } function get_type() { return "css"; } }

Akhirnya, kami hanya mengantrekan file yang dibundel ini, seperti sebelumnya, alih-alih semua sumber daya independen. Untuk CSS, kita membuat bundel yang berisi file header-colors.css , background-image.css dan font-sizes.css , yang dengannya kita cukup membuat instance StylesSiteBundle dengan objek PHP untuk masing-masing file ini (dan juga kita dapat membuat JS berkas berkas):

 $fileObjects = array( // CSS new HeaderColorsSiteResource(), new BackgroundImageSiteResource(), new FontSizesSiteResource(), // JS new WelcomeUserDataUserResource(), new UserShoppingItemsUserResource() ); $cssFileObjects = array_map(array(ResourceUtils::class, 'is_css'), $fileObjects); $jsFileObjects = array_map(array(ResourceUtils::class, 'is_js'), $fileObjects); // Use this definition of $fileEnqueuer instead of the previous one $fileEnqueuer = new ResourceEnqueuer( array( new StylesSiteBundle($cssFileObjects), new ScriptsSiteBundle($jsFileObjects) ) );

Itu dia. Sekarang kita hanya akan meminta satu file JS dan satu file CSS, bukan banyak.

Perbaikan terakhir untuk kinerja yang dirasakan melibatkan memprioritaskan aset, dengan menunda pemuatan aset-aset yang tidak diperlukan segera. Mari kita atasi ini selanjutnya.

async / defer Atribut Untuk Sumber Daya JS

Kita dapat menambahkan atribut async dan defer ke tag <script> , untuk mengubah kapan file JavaScript diunduh, diuraikan, dan dieksekusi, untuk memprioritaskan JavaScript penting dan mendorong semua yang tidak penting selambat mungkin, sehingga mengurangi pemuatan situs yang nyata waktu.

Untuk mengimplementasikan fitur ini, mengikuti prinsip SOLID, kita harus membuat antarmuka baru JSResource (yang mewarisi dari Resource ) yang berisi fungsi is_async dan is_defer . Namun, ini akan menutup pintu ke <style> yang pada akhirnya mendukung atribut ini juga. Jadi, dengan mempertimbangkan kemampuan beradaptasi, kami mengambil pendekatan yang lebih terbuka: kami cukup menambahkan metode generik get_attributes ke antarmuka Resource agar tetap fleksibel untuk ditambahkan ke atribut apa pun (baik yang sudah ada atau belum ditemukan) untuk keduanya <script> tag <script> dan <link> :

 interface Resource { // Continued from above... function get_attributes(); } abstract class ResourceBase implements Resource { // Continued from above... function get_attributes() { // By default, no extra attributes return ''; } }

WordPress tidak menawarkan cara mudah untuk menambahkan atribut tambahan ke sumber daya yang diantrekan, jadi kami melakukannya dengan cara yang agak rumit, menambahkan kait yang menggantikan string di dalam tag melalui fungsi add_script_tag_attributes :

 class ResourceEnqueuerUtils { protected static tag_attributes = array(); static function add_tag_attributes($handle, $attributes) { self::tag_attributes[$handle] = $attributes; } static function add_script_tag_attributes($tag, $handle, $src) { if ($attributes = self::tag_attributes[$handle]) { $tag = str_replace( " src='${src}'>", " src='${src}' ".$attributes.">", $tag ); } return $tag; } } // Initize by connecting to the WordPress hook add_filter( 'script_loader_tag', array(ResourceEnqueuerUtils::class, 'add_script_tag_attributes'), PHP_INT_MAX, 3 );

Kami menambahkan atribut untuk sumber daya saat membuat instance objek yang sesuai:

 abstract class ResourceBase implements Resource { // Continued from above... function __construct() { ResourceEnqueuerUtils::add_tag_attributes($this->get_filename(), $this->get_attributes()); } }

Terakhir, jika resource welcomeuser-data.js tidak perlu segera dieksekusi, kita dapat menyetelnya sebagai defer :

 class WelcomeUserDataUserResource extends UserResourceBase { // Continued from above... function get_attributes() { return "defer='defer'"; } }

Karena dimuat sebagai ditangguhkan, skrip akan dimuat nanti, mengedepankan titik waktu di mana pengguna dapat berinteraksi dengan situs. Mengenai peningkatan kinerja, kita sudah siap sekarang!

Ada satu masalah yang tersisa untuk diselesaikan sebelum kita dapat bersantai: apa yang terjadi ketika situs dihosting di beberapa server?

Berurusan Dengan Banyak Server Di Balik Load Balancer

Jika situs kami dihosting di beberapa situs di belakang penyeimbang beban, dan file yang bergantung pada konfigurasi pengguna dibuat ulang, server yang menangani permintaan harus, entah bagaimana, mengunggah file statis yang dibuat ulang ke semua server lain; jika tidak, server lain akan menyajikan versi lama dari file tersebut mulai saat itu. Bagaimana kita melakukan ini? Memiliki server yang berkomunikasi satu sama lain tidak hanya rumit, tetapi pada akhirnya terbukti tidak layak: Apa yang terjadi jika situs berjalan pada ratusan server, dari wilayah yang berbeda? Jelas, ini bukan pilihan.

Solusi yang saya temukan adalah menambahkan tingkat tipuan: alih-alih meminta file statis dari URL situs, mereka diminta dari lokasi di cloud, seperti dari ember AWS S3. Kemudian, setelah membuat ulang file, server akan segera mengunggah file baru ke S3 dan menyajikannya dari sana. Implementasi solusi ini dijelaskan dalam artikel saya sebelumnya Berbagi Data Di Antara Beberapa Server Melalui AWS S3.

Kesimpulan

Dalam artikel ini, kami telah mempertimbangkan bahwa menyisipkan kode JS dan CSS tidak selalu ideal, karena kode tersebut harus dikirim berulang kali ke klien, yang dapat berdampak buruk pada kinerja jika jumlah kodenya signifikan. Kami melihat, sebagai contoh, bagaimana WordPress memuat 43kb skrip untuk mencetak Manajer Media, yang merupakan templat JavaScript murni dan dapat dimuat dengan sempurna sebagai sumber daya statis.

Oleh karena itu, kami telah menemukan cara untuk membuat situs web lebih cepat dengan mengubah kode inline JS dan CSS dinamis menjadi sumber daya statis, yang dapat meningkatkan caching di beberapa tingkat (di klien, Service Worker, CDN), memungkinkan untuk lebih lanjut menggabungkan semua file bersama-sama menjadi hanya satu sumber daya JS/CSS untuk meningkatkan rasio saat mengompresi output (seperti melalui GZip) dan untuk menghindari overhead di browser dari memproses beberapa sumber daya secara bersamaan (seperti di Chrome), dan juga memungkinkan untuk menambahkan atribut async atau defer ke tag <script> untuk mempercepat interaktivitas pengguna, sehingga meningkatkan waktu pemuatan situs yang nyata.

Sebagai efek samping yang menguntungkan, pemecahan kode menjadi sumber daya statis juga memungkinkan kode menjadi lebih terbaca, berurusan dengan unit kode alih-alih gumpalan besar HTML, yang dapat mengarah pada pemeliharaan proyek yang lebih baik.

Solusi yang kami kembangkan dilakukan di PHP dan menyertakan beberapa bit kode khusus untuk WordPress, namun, kode itu sendiri sangat sederhana, hampir tidak ada beberapa antarmuka yang mendefinisikan properti dan objek yang mengimplementasikan properti tersebut mengikuti prinsip SOLID, dan fungsi untuk menyimpan file ke disk. Itu cukup banyak. Hasil akhirnya bersih dan ringkas, mudah dibuat ulang untuk bahasa dan platform lain, dan tidak sulit untuk diperkenalkan ke proyek yang sudah ada — memberikan peningkatan kinerja yang mudah.