Δεν υπάρχει πιο γρήγορος τρόπος να επιβραδύνεις έναν ιστότοπο (λογοπαίγνιο) από το να χρησιμοποιήσεις ένα σωρό κώδικα JavaScript σε αυτόν. Όταν χρησιμοποιείτε JavaScript, πρέπει να πληρώσετε για αυτό με την απόδοση των έργων όχι λιγότερο από τέσσερις φορές. Δείτε πώς ο κώδικας JavaScript του ιστότοπου φορτώνει τα συστήματα των χρηστών:
- Λήψη αρχείου μέσω δικτύου.
- Ανάλυση και μεταγλώττιση μη συσκευασμένου πηγαίου κώδικα μετά τη λήψη.
- Εκτέλεση κώδικα JavaScript.
- Κατανάλωση μνήμης.
Αυτός ο συνδυασμός αποδεικνύεται .
Και συμπεριλαμβάνουμε όλο και περισσότερο κώδικα JS στα έργα μας. Καθώς οι οργανισμοί κινούνται προς ιστότοπους που τροφοδοτούνται από πλαίσια και βιβλιοθήκες όπως το React, το Vue και άλλες, εξαρτάμε πολύ τη βασική λειτουργικότητα των τοποθεσιών από τη JavaScript.
Έχω δει πολλούς πολύ βαρείς ιστότοπους που χρησιμοποιούν πλαίσια JavaScript. Αλλά το όραμά μου για το θέμα είναι πολύ προκατειλημμένο. Γεγονός είναι ότι οι εταιρείες με τις οποίες συνεργάζομαι στρέφονται σε εμένα ακριβώς επειδή αντιμετωπίζουν πολύπλοκα προβλήματα στον τομέα της απόδοσης του site. Ως αποτέλεσμα, έγινα περίεργος για το πόσο συχνό είναι αυτό το πρόβλημα και για το τι είδους "ποινές" πληρώνουμε όταν επιλέγουμε ένα ή άλλο πλαίσιο ως βάση για έναν συγκεκριμένο ιστότοπο.
Το έργο με βοήθησε να το καταλάβω. .
Δεδομένα
Το έργο HTTP Archive παρακολουθεί συνολικά 4308655 συνδέσμους προς κανονικούς ιστότοπους για επιτραπέζιους υπολογιστές και 5484239 συνδέσμους προς ιστότοπους για κινητές συσκευές. Μεταξύ των πολλών μετρήσεων που σχετίζονται με αυτούς τους συνδέσμους είναι μια λίστα τεχνολογιών που βρίσκονται στους αντίστοιχους ιστότοπους. Αυτό σημαίνει ότι μπορούμε να δειγματίσουμε χιλιάδες ιστότοπους που χρησιμοποιούν διάφορα πλαίσια και βιβλιοθήκες και να μάθουμε πόσο κώδικα στέλνουν στους πελάτες και πόσο φορτίο δημιουργεί αυτός ο κώδικας στα συστήματα των χρηστών.
Συνέλεξα δεδομένα Μαρτίου 2020, τα οποία ήταν τα πιο πρόσφατα δεδομένα στα οποία είχα πρόσβαση.
Αποφάσισα να συγκρίνω συγκεντρωτικά δεδομένα αρχείου HTTP σε όλους τους ιστότοπους με δεδομένα από ιστότοπους που βρέθηκαν χρησιμοποιώντας το React, το Vue και το Angular, αν και σκέφτηκα να χρησιμοποιήσω και άλλο υλικό πηγής.
Για να το κάνω πιο ενδιαφέρον, πρόσθεσα επίσης ιστότοπους που χρησιμοποιούν jQuery στο σύνολο δεδομένων προέλευσης. Αυτή η βιβλιοθήκη εξακολουθεί να είναι πολύ δημοφιλής. Επίσης, εισάγει μια διαφορετική προσέγγιση στην ανάπτυξη ιστού από το μοντέλο Εφαρμογής Μονής Σελίδας (SPA) που προσφέρεται από τα React, Vue και Angular.
Σύνδεσμοι στο Αρχείο HTTP που αντιπροσωπεύουν ιστότοπους που έχουν διαπιστωθεί ότι χρησιμοποιούν τεχνολογίες ενδιαφέροντος
Πλαίσιο ή βιβλιοθήκη
Σύνδεσμοι σε ιστότοπους για κινητές συσκευές
Σύνδεσμοι σε κανονικούς ιστότοπους
jQuery
4615474
3714643
Αντίδραση
489827
241023
Προβολή
85649
43691
Γωνιώδης
19423
18088
Ελπίδες και όνειρα
Πριν προχωρήσουμε στην ανάλυση δεδομένων, θέλω να μιλήσω για το τι θα ήθελα να ελπίζω.
Πιστεύω ότι σε έναν ιδανικό κόσμο, τα πλαίσια πρέπει να υπερβαίνουν τις ανάγκες των προγραμματιστών και να παρέχουν κάποιο συγκεκριμένο όφελος στον μέσο χρήστη που εργάζεται με τους ιστότοπούς μας. Η απόδοση είναι μόνο ένα από αυτά τα οφέλη. Εδώ παίζει ρόλο η προσβασιμότητα και η ασφάλεια. Αλλά αυτό είναι μόνο το πιο σημαντικό.
Έτσι, σε έναν ιδανικό κόσμο, κάποιου είδους πλαίσιο θα πρέπει να διευκολύνει τη δημιουργία ενός ιστότοπου υψηλής απόδοσης. Αυτό θα πρέπει να γίνει είτε λόγω του γεγονότος ότι το πλαίσιο δίνει στον προγραμματιστή μια αξιοπρεπή βάση για να χτίσει ένα έργο, είτε λόγω του γεγονότος ότι επιβάλλει περιορισμούς στην ανάπτυξη, θέτει απαιτήσεις για αυτό που περιπλέκουν την ανάπτυξη κάτι που στρέφεται να είναι αργός.
Τα καλύτερα πλαίσια πρέπει να κάνουν και τα δύο: να δίνουν μια καλή βάση και να επιβάλλουν περιορισμούς στην εργασία, επιτρέποντάς σας να επιτύχετε ένα αξιοπρεπές αποτέλεσμα.
Η ανάλυση των διάμεσων τιμών των δεδομένων δεν θα μας δώσει τις πληροφορίες που χρειαζόμαστε. Και, στην πραγματικότητα, αυτή η προσέγγιση αφήνει έξω από την προσοχή μας . Αντίθετα, άντλησα ποσοστά από τα δεδομένα που είχα. Αυτά είναι 10, 25, 50 (διάμεσος), 75, 90 εκατοστημόρια.
Με ενδιαφέρουν ιδιαίτερα το 10ο και το 90ο εκατοστημόριο. Το 10ο εκατοστημόριο αντιπροσωπεύει την καλύτερη απόδοση (ή τουλάχιστον περισσότερο ή λιγότερο κοντά στην καλύτερη) για ένα συγκεκριμένο πλαίσιο. Με άλλα λόγια, αυτό σημαίνει ότι μόνο το 10% των τοποθεσιών που χρησιμοποιούν ένα συγκεκριμένο πλαίσιο φτάνει σε αυτό το επίπεδο ή υψηλότερο. Το 90ο εκατοστημόριο, από την άλλη πλευρά, είναι η άλλη όψη του νομίσματος - μας δείχνει πόσο άσχημα μπορεί να γίνουν τα πράγματα. Το 90ο εκατοστημόριο είναι οι ιστότοποι που υστερούν—αυτές το κατώτατο 10% των ιστότοπων που έχουν τον περισσότερο κώδικα JS ή τον μεγαλύτερο χρόνο επεξεργασίας του κώδικά τους στο κύριο νήμα.
Τόμοι κώδικα JavaScript
Αρχικά, είναι λογικό να αναλύσουμε το μέγεθος του κώδικα JavaScript που μεταδίδεται από διαφορετικούς ιστότοπους μέσω του δικτύου.
Το ποσό του κώδικα JavaScript (Kb) που μεταφέρεται σε κινητές συσκευές
Εκατοστές
10
25
50
75
90
Όλοι οι ιστότοποι
93.4
196.6
413.5
746.8
1201.6
Ιστότοποι jQuery
110.3
219.8
430.4
748.6
1162.3
Τοποθεσίες Vue
244.7
409.3
692.1
1065.5
1570.7
Γωνιακές τοποθεσίες
445.1
675.6
1066.4
1761.5
2893.2
Τοποθεσίες React
345.8
441.6
690.3
1238.5
1893.6
Ποσότητα κώδικα JavaScript που αποστέλλεται σε κινητές συσκευές
Ποσότητα κώδικα JavaScript (Kb) που μεταφέρθηκε σε επιτραπέζιες συσκευές
Εκατοστές
10
25
50
75
90
Όλοι οι ιστότοποι
105.5
226.6
450.4
808.8
1267.3
Ιστότοποι jQuery
121.7
242.2
458.3
803.4
1235.3
Τοποθεσίες Vue
248.0
420.1
718.0
1122.5
1643.1
Γωνιακές τοποθεσίες
468.8
716.9
1144.2
1930.0
3283.1
Τοποθεσίες React
308.6
469.0
841.9
1472.2
2197.8
Ποσότητα κώδικα JavaScript που αποστέλλεται σε επιτραπέζιες συσκευές
Αν μιλάμε μόνο για το μέγεθος του κώδικα JS που στέλνουν οι ιστότοποι στις συσκευές, τότε όλα φαίνονται όπως θα περίμενε κανείς. Δηλαδή, εάν χρησιμοποιηθεί ένα από τα πλαίσια, αυτό σημαίνει ότι ακόμη και σε μια ιδανική κατάσταση, ο όγκος του κώδικα JavaScript του ιστότοπου θα αυξηθεί. Αυτό δεν προκαλεί έκπληξη - δεν μπορείτε να κάνετε ένα πλαίσιο JavaScript τη βάση ενός ιστότοπου και να περιμένετε ότι ο όγκος του κώδικα JS του έργου θα είναι πολύ χαμηλός.
Αυτό που είναι αξιοσημείωτο σε αυτά τα δεδομένα είναι ότι ορισμένα πλαίσια και βιβλιοθήκες μπορούν να θεωρηθούν καλύτερο σημείο εκκίνησης για ένα έργο από άλλα. Οι ιστότοποι με jQuery φαίνονται οι καλύτεροι. Στις εκδόσεις ιστοτόπων για επιτραπέζιους υπολογιστές, περιέχουν 15% περισσότερη JavaScript από όλους τους ιστότοπους και σε κινητά περιέχουν 18% περισσότερο. (Ομολογουμένως, υπάρχει κάποια καταστροφή δεδομένων εδώ. Το γεγονός είναι ότι το jQuery υπάρχει σε πολλούς ιστότοπους, επομένως είναι φυσικό ότι τέτοιοι ιστότοποι συνδέονται πιο στενά από άλλους με τον συνολικό αριθμό ιστότοπων. Ωστόσο, αυτό δεν επηρεάζει τον ακατέργαστο εξάγονται δεδομένα για κάθε πλαίσιο.)
Ενώ η αύξηση κατά 15-18% στον όγκο του κώδικα είναι ένα αξιοσημείωτο ποσοστό, συγκρίνοντας αυτό με άλλα πλαίσια και βιβλιοθήκες, μπορεί κανείς να συμπεράνει ότι ο «φόρος» που επιβάλλεται από το jQuery είναι πολύ χαμηλός. Οι γωνιακοί ιστότοποι στο 10ο εκατοστημόριο στέλνουν 344% περισσότερα δεδομένα σε επιτραπέζιους υπολογιστές από όλους τους ιστότοπους και 377% περισσότερα σε κινητά. Οι ιστότοποι React είναι οι επόμενοι βαρύτεροι, στέλνοντας 193% περισσότερο κώδικα σε επιτραπέζιους υπολογιστές από όλους τους ιστότοπους και 270% περισσότερο σε κινητά.
Νωρίτερα, ανέφερα ότι αν και η χρήση ενός πλαισίου σημαίνει ότι ένα συγκεκριμένο ποσό κώδικα θα συμπεριληφθεί στο έργο, στην αρχή της εργασίας σε αυτό, ελπίζω ότι το πλαίσιο θα είναι σε θέση να περιορίσει κατά κάποιο τρόπο τον προγραμματιστή. Συγκεκριμένα, μιλάμε για περιορισμό της μέγιστης ποσότητας κωδικού.
Είναι ενδιαφέρον ότι οι ιστότοποι jQuery ακολουθούν αυτήν την ιδέα. Ενώ είναι ελαφρώς βαρύτεροι από όλους τους ιστότοπους στο 10ο εκατοστημόριο (κατά 15-18%), είναι ελαφρώς ελαφρύτεροι στο 90ο εκατοστημόριο με περίπου 3% τόσο σε επιτραπέζιους υπολογιστές όσο και σε κινητά. Αυτό δεν σημαίνει ότι αυτό είναι ένα πολύ σημαντικό όφελος, αλλά μπορεί να ειπωθεί ότι οι ιστότοποι jQuery, τουλάχιστον, δεν έχουν τεράστια μεγέθη κώδικα JavaScript, ακόμη και στις μεγαλύτερες εκδόσεις τους.
Αλλά το ίδιο δεν μπορεί να ειπωθεί για άλλα πλαίσια.
Ακριβώς όπως στην περίπτωση του 10ου εκατοστημόριου, στο 90ο εκατοστημόριο οι τοποθεσίες στο Angular και το React διαφέρουν από άλλες τοποθεσίες, αλλά διαφέρουν, δυστυχώς, προς το χειρότερο.
Στο 90ο εκατοστημόριο, οι ιστότοποι Angular στέλνουν 141% περισσότερα δεδομένα σε κινητά από όλους τους ιστότοπους και 159% περισσότερα σε επιτραπέζιους υπολογιστές. Οι ιστότοποι React στέλνουν 73% περισσότερα σε επιτραπέζιους υπολογιστές από όλους τους ιστότοπους και 58% περισσότερα σε κινητά. Το μέγεθος κώδικα των τοποθεσιών React στο 90ο εκατοστημόριο είναι 2197.8 KB. Αυτό σημαίνει ότι τέτοιοι ιστότοποι στέλνουν 322.9 KB περισσότερα δεδομένα σε κινητές συσκευές από τους πλησιέστερους ανταγωνιστές τους με βάση το Vue. Το χάσμα μεταξύ των επιτραπέζιων τοποθεσιών που βασίζονται στο Angular και στο React και σε άλλους ιστότοπους είναι ακόμη μεγαλύτερο. Για παράδειγμα, οι ιστότοποι React για επιτραπέζιους υπολογιστές στέλνουν 554.7 KB περισσότερο κώδικα JS σε συσκευές από τους αντίστοιχους ιστότοπους Vue.
Χρόνος που απαιτείται για την επεξεργασία κώδικα JavaScript στο κύριο νήμα
Τα παραπάνω δεδομένα δείχνουν ξεκάθαρα ότι οι ιστότοποι που χρησιμοποιούν τα υπό μελέτη πλαίσια και βιβλιοθήκες περιέχουν μεγάλες ποσότητες κώδικα JavaScript. Αλλά φυσικά, αυτό είναι μόνο ένα μέρος της εξίσωσής μας.
Αφού φτάσει ο κώδικας JavaScript στο πρόγραμμα περιήγησης, πρέπει να τεθεί σε κατάσταση λειτουργίας. Ιδιαίτερα πολλά προβλήματα προκαλούνται από εκείνες τις ενέργειες που πρέπει να εκτελεστούν με τον κώδικα στο κύριο νήμα του προγράμματος περιήγησης. Το κύριο νήμα είναι υπεύθυνο για την επεξεργασία των ενεργειών του χρήστη, για τον υπολογισμό των στυλ, για τη δημιουργία και την εμφάνιση της διάταξης της σελίδας. Εάν κατακλύσετε το κύριο νήμα με εργασίες JavaScript, δεν θα έχει την ευκαιρία να ολοκληρώσει έγκαιρα τις υπόλοιπες εργασίες. Αυτό οδηγεί σε καθυστερήσεις και «φρένα» στη δουλειά των σελίδων.
Η βάση δεδομένων του HTTP Archive έχει πληροφορίες σχετικά με το χρόνο που χρειάζεται για την επεξεργασία κώδικα JavaScript στο κύριο νήμα της μηχανής V8. Αυτό σημαίνει ότι μπορούμε να συλλέξουμε αυτά τα δεδομένα και να μάθουμε πόσο χρόνο χρειάζεται το κύριο νήμα για την επεξεργασία του JavaScript διαφόρων τοποθεσιών.
Χρόνος επεξεργαστή (σε χιλιοστά του δευτερολέπτου) που σχετίζεται με την επεξεργασία σεναρίων σε κινητές συσκευές
Εκατοστές
10
25
50
75
90
Όλοι οι ιστότοποι
356.4
959.7
2372.1
5367.3
10485.8
Ιστότοποι jQuery
575.3
1147.4
2555.9
5511.0
10349.4
Τοποθεσίες Vue
1130.0
2087.9
4100.4
7676.1
12849.4
Γωνιακές τοποθεσίες
1471.3
2380.1
4118.6
7450.8
13296.4
Τοποθεσίες React
2700.1
5090.3
9287.6
14509.6
20813.3
Χρόνος επεξεργαστή που σχετίζεται με την επεξεργασία σεναρίων σε κινητές συσκευές
Χρόνος CPU (σε χιλιοστά του δευτερολέπτου) που σχετίζεται με την επεξεργασία σεναρίων σε επιτραπέζιες συσκευές
Εκατοστές
10
25
50
75
90
Όλοι οι ιστότοποι
146.0
351.8
831.0
1739.8
3236.8
Ιστότοποι jQuery
199.6
399.2
877.5
1779.9
3215.5
Τοποθεσίες Vue
350.4
650.8
1280.7
2388.5
4010.8
Γωνιακές τοποθεσίες
482.2
777.9
1365.5
2400.6
4171.8
Τοποθεσίες React
508.0
1045.6
2121.1
4235.1
7444.3
Χρόνος επεξεργαστή που σχετίζεται με την επεξεργασία σεναρίων σε επιτραπέζιες συσκευές
Εδώ μπορείτε να δείτε κάτι πολύ οικείο.
Για αρχή, οι ιστότοποι με jQuery ξοδεύουν σημαντικά λιγότερα σε επεξεργασία JavaScript στο κύριο νήμα από άλλους ιστότοπους. Στο 10ο εκατοστημόριο, σε σύγκριση με όλους τους ιστότοπους, οι ιστότοποι jQuery σε κινητά ξοδεύουν 61% περισσότερο χρόνο στην επεξεργασία του κώδικα JS στο κύριο νήμα. Στην περίπτωση των τοποθεσιών jQuery για επιτραπέζιους υπολογιστές, ο χρόνος επεξεργασίας αυξάνεται κατά 37%. Στο 90ο εκατοστημόριο, οι ιστότοποι jQuery βαθμολογούνται πολύ κοντά στις αθροιστικές βαθμολογίες. Συγκεκριμένα, οι ιστότοποι jQuery σε κινητές συσκευές ξοδεύουν 1.3% λιγότερο χρόνο στο κύριο νήμα από όλους τους ιστότοπους και 0.7% λιγότερο χρόνο σε επιτραπέζιους υπολογιστές.
Στην άλλη πλευρά της βαθμολογίας μας βρίσκονται τα πλαίσια που χαρακτηρίζονται από το υψηλότερο φορτίο στο κύριο νήμα. Αυτό είναι, πάλι, το Angular και το React. Η μόνη διαφορά μεταξύ των δύο είναι ότι ενώ οι ιστότοποι Angular στέλνουν περισσότερο κώδικα σε προγράμματα περιήγησης από τους ιστότοπους React, οι ιστότοποι Angular χρειάζονται λιγότερο χρόνο CPU για την επεξεργασία του κώδικα. Πολύ λιγότερο.
Στο 10ο εκατοστημόριο, οι ιστότοποι Angular για επιτραπέζιους υπολογιστές ξοδεύουν 230% περισσότερο χρόνο στο κύριο νήμα για την επεξεργασία του κώδικα JS από όλους τους ιστότοπους. Για ιστότοπους για κινητές συσκευές, αυτό το ποσοστό είναι 313%. Οι ιστότοποι React έχουν τη χειρότερη απόδοση. Σε επιτραπέζιους υπολογιστές, ξοδεύουν 248% περισσότερο χρόνο στην επεξεργασία κώδικα από όλους τους ιστότοπους και 658% περισσότερο σε κινητά. Το 658% δεν είναι τυπογραφικό λάθος. Στο 10ο εκατοστημόριο, οι ιστότοποι React ξοδεύουν 2.7 δευτερόλεπτα από το χρόνο του κύριου νήματος για την επεξεργασία του κώδικά τους.
Το 90ο εκατοστημόριο, σε σύγκριση με αυτούς τους τεράστιους αριθμούς, φαίνεται τουλάχιστον λίγο καλύτερο. Σε σύγκριση με όλους τους ιστότοπους, τα έργα Angular ξοδεύουν 29% περισσότερο χρόνο σε επιτραπέζιους υπολογιστές στο κύριο νήμα και 27% περισσότερο χρόνο σε κινητές συσκευές. Στην περίπτωση των τοποθεσιών React, τα ίδια ποσοστά μοιάζουν με 130% και 98%, αντίστοιχα.
Οι ποσοστιαίες αποκλίσεις για το 90ο εκατοστημόριο φαίνονται καλύτερες από παρόμοιες τιμές για το 10ο εκατοστημόριο. Αλλά εδώ αξίζει να θυμηθούμε ότι οι αριθμοί που δείχνουν την ώρα φαίνονται μάλλον τρομακτικοί. Ας πούμε 20.8 δευτερόλεπτα στο κύριο νήμα για κινητά για έναν ιστότοπο που δημιουργήθηκε με React. (Νομίζω ότι η ιστορία του τι πραγματικά συμβαίνει κατά τη διάρκεια αυτής της περιόδου αξίζει ένα ξεχωριστό άρθρο).
Υπάρχει μια πιθανή επιπλοκή εδώ (ευχαριστώ για να επιστήσω την προσοχή μου σε αυτό το χαρακτηριστικό και για την προσεκτική εξέταση των δεδομένων από αυτήν την άποψη). Το γεγονός είναι ότι πολλοί ιστότοποι χρησιμοποιούν πολλά εργαλεία front-end. Συγκεκριμένα, έχω δει πολλούς ιστότοπους που χρησιμοποιούν jQuery παράλληλα με το React ή το Vue, καθώς αυτοί οι ιστότοποι μεταφέρονται από το jQuery σε άλλα πλαίσια ή βιβλιοθήκες. Ως αποτέλεσμα, πάτησα ξανά τη βάση δεδομένων, επιλέγοντας αυτή τη φορά μόνο αυτούς τους συνδέσμους που αντιστοιχούν σε ιστότοπους που χρησιμοποιούν μόνο React, jQuery, Angular ή Vue, αλλά όχι οποιονδήποτε συνδυασμό τους. Να τι πήρα.
Χρόνος επεξεργαστή (σε χιλιοστά του δευτερολέπτου) που σχετίζεται με την επεξεργασία σεναρίων σε κινητές συσκευές σε μια κατάσταση όπου οι ιστότοποι χρησιμοποιούν μόνο ένα πλαίσιο ή μόνο μία βιβλιοθήκη
Εκατοστές
10
25
50
75
90
Ιστότοποι που χρησιμοποιούν μόνο jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Ιστότοποι που χρησιμοποιούν μόνο το Vue
944.0
1716.3
3194.7
5959.6
9843.8
Ιστότοποι που χρησιμοποιούν μόνο Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Ιστότοποι που χρησιμοποιούν μόνο το React
2443.2
4620.5
10061.4
17074.3
24956.3
Χρόνος επεξεργαστή που σχετίζεται με την επεξεργασία σεναρίων σε κινητές συσκευές σε μια κατάσταση όπου οι ιστότοποι χρησιμοποιούν μόνο ένα πλαίσιο ή μόνο μία βιβλιοθήκη
Πρώτον, κάτι που δεν προκαλεί έκπληξη: όταν ένας ιστότοπος χρησιμοποιεί μόνο ένα πλαίσιο ή μία βιβλιοθήκη, η απόδοση ενός τέτοιου ιστότοπου βελτιώνεται συχνότερα. Κάθε όργανο αποδίδει καλύτερα στο 10ο και το 25ο εκατοστημόριο. Είναι λογικό. Ένας ιστότοπος που δημιουργείται χρησιμοποιώντας ένα πλαίσιο θα πρέπει να έχει καλύτερη απόδοση από έναν ιστότοπο που έχει δημιουργηθεί χρησιμοποιώντας δύο ή περισσότερα πλαίσια ή βιβλιοθήκες.
Στην πραγματικότητα, η απόδοση κάθε εργαλείου front-end που μελετήθηκε φαίνεται καλύτερη σε όλες τις περιπτώσεις, εκτός από μια περίεργη εξαίρεση. Αυτό που με εξέπληξε ήταν ότι στο 50ο εκατοστημόριο και πάνω, οι ιστότοποι που χρησιμοποιούν React έχουν χειρότερη απόδοση όταν το React είναι η μόνη βιβλιοθήκη που χρησιμοποιούν. Αυτός, παρεμπιπτόντως, ήταν ο λόγος που παρουσιάζω αυτά τα δεδομένα εδώ.
Αυτό είναι λίγο περίεργο, αλλά θα προσπαθήσω ακόμα να ψάξω για μια εξήγηση για αυτό το παράξενο.
Εάν ένα έργο χρησιμοποιεί και React και jQuery, τότε αυτό το έργο είναι πιθανόν κάπου στα μισά της μετάβασης από το jQuery στο React. Ίσως έχει μια βάση κώδικα όπου αυτές οι βιβλιοθήκες αναμειγνύονται. Εφόσον έχουμε ήδη δει ότι οι ιστότοποι jQuery ξοδεύουν λιγότερο χρόνο στο κύριο νήμα από τους ιστότοπους React, αυτό μπορεί να μας πει ότι η εφαρμογή ορισμένων λειτουργιών στο jQuery βοηθά τον ιστότοπο να αποδίδει λίγο καλύτερα.
Αλλά καθώς το έργο μεταβαίνει από το jQuery στο React και βασίζεται περισσότερο στο React, τα πράγματα αλλάζουν. Εάν ο ιστότοπος είναι πραγματικά υψηλής ποιότητας και οι προγραμματιστές του ιστότοπου χρησιμοποιούν προσεκτικά το React, τότε όλα θα πάνε καλά με έναν τέτοιο ιστότοπο. Αλλά για τον μέσο ιστότοπο του React, η εκτεταμένη χρήση του React σημαίνει ότι το κύριο νήμα είναι υπό μεγάλο φορτίο.
Το χάσμα μεταξύ φορητών και επιτραπέζιων συσκευών
Μια άλλη οπτική γωνία από την οποία εξέτασα τα δεδομένα που ερευνήθηκαν ήταν να μελετήσω πόσο μεγάλο είναι το χάσμα μεταξύ της εργασίας με ιστότοπους σε κινητές συσκευές και επιτραπέζιους υπολογιστές. Αν μιλάμε για σύγκριση των όγκων κώδικα JavaScript, τότε μια τέτοια σύγκριση δεν αποκαλύπτει τίποτα τρομερό. Φυσικά, θα ήταν ωραίο να δούμε μικρότερες ποσότητες κώδικα με δυνατότητα λήψης, αλλά δεν υπάρχει μεγάλη διαφορά στην ποσότητα του κώδικα για κινητά και επιτραπέζιους υπολογιστές.
Αν όμως αναλύσουμε τον χρόνο που απαιτείται για την επεξεργασία του κώδικα, γίνεται αντιληπτό ένα πολύ μεγάλο κενό μεταξύ φορητών και επιτραπέζιων συσκευών.
Αύξηση χρόνου (ποσοστό) που σχετίζεται με την επεξεργασία σεναρίων σε κινητές συσκευές σε σύγκριση με επιτραπέζιους υπολογιστές
Εκατοστές
10
25
50
75
90
Όλοι οι ιστότοποι
144.1
172.8
185.5
208.5
224.0
Ιστότοποι jQuery
188.2
187.4
191.3
209.6
221.9
Τοποθεσίες Vue
222.5
220.8
220.2
221.4
220.4
Γωνιακές τοποθεσίες
205.1
206.0
201.6
210.4
218.7
Τοποθεσίες React
431.5
386.8
337.9
242.6
179.6
Αν και είναι αναμενόμενη κάποια διαφορά στην ταχύτητα επεξεργασίας κώδικα μεταξύ ενός τηλεφώνου και ενός φορητού υπολογιστή, τόσο μεγάλοι αριθμοί μου λένε ότι τα σύγχρονα πλαίσια δεν στοχεύουν επαρκώς σε συσκευές χαμηλής κατανάλωσης και ότι προσπαθούν να καλύψουν το κενό που έχουν ανακαλύψει. Ακόμη και στο 10ο εκατοστημόριο, οι ιστότοποι React ξοδεύουν 431.5% περισσότερο χρόνο στο κύριο νήμα για κινητά από ό,τι στο κύριο νήμα του επιτραπέζιου υπολογιστή. Το jQuery έχει το μικρότερο κενό, αλλά και εδώ το αντίστοιχο ποσοστό είναι 188.2%. Όταν οι προγραμματιστές ιστότοπων κάνουν τα έργα τους με τέτοιο τρόπο ώστε η επεξεργασία τους να απαιτεί περισσότερο χρόνο επεξεργαστή (και αυτό συμβαίνει, και χειροτερεύει μόνο με την πάροδο του χρόνου), οι κάτοχοι συσκευών χαμηλής κατανάλωσης πρέπει να πληρώσουν για αυτό.
Αποτελέσματα της
Τα καλά πλαίσια θα πρέπει να παρέχουν στους προγραμματιστές μια καλή βάση για τη δημιουργία έργων Ιστού (όσον αφορά την ασφάλεια, την προσβασιμότητα, την απόδοση) ή θα πρέπει να έχουν ενσωματωμένους περιορισμούς που καθιστούν δύσκολη τη δημιουργία κάτι που παραβιάζει αυτούς τους περιορισμούς.
Αυτό δεν φαίνεται να ισχύει για την απόδοση των έργων Ιστού (και πιθανώς όχι για τα έργα τους ).
Αξίζει να σημειωθεί ότι μόνο και μόνο επειδή οι ιστότοποι React ή Angular ξοδεύουν περισσότερο χρόνο CPU για την προετοιμασία κώδικα από άλλους, δεν σημαίνει απαραίτητα ότι οι ιστότοποι React έχουν μεγαλύτερη ένταση CPU από τους ιστότοπους Vue κατά την εκτέλεση. Στην πραγματικότητα, τα δεδομένα που εξετάσαμε λένε πολύ λίγα για τη λειτουργική απόδοση των πλαισίων και των βιβλιοθηκών. Μιλούν περισσότερο για τις προσεγγίσεις ανάπτυξης που, συνειδητά ή όχι, αυτά τα πλαίσια μπορούν να ωθήσουν τους προγραμματιστές. Μιλάμε για τεκμηρίωση για πλαίσια, για το οικοσύστημά τους, για κοινές τεχνικές ανάπτυξης.
Αξίζει επίσης να αναφέρουμε κάτι που δεν αναλύσαμε εδώ, δηλαδή πόσο χρόνο αφιερώνει η συσκευή για την εκτέλεση κώδικα JavaScript κατά την πλοήγηση μεταξύ σελίδων του ιστότοπου. Το επιχείρημα υπέρ του SPA είναι ότι μόλις η εφαρμογή μιας σελίδας φορτωθεί στο πρόγραμμα περιήγησης, ο χρήστης θα μπορεί θεωρητικά να ανοίξει τις σελίδες του ιστότοπου πιο γρήγορα. Η δική μου εμπειρία μου λέει ότι αυτό απέχει πολύ από το γεγονός. Όμως δεν έχουμε στοιχεία για να διευκρινίσουμε αυτό το ζήτημα.
Αυτό που είναι ξεκάθαρο είναι ότι εάν χρησιμοποιείτε ένα πλαίσιο ή βιβλιοθήκη για να δημιουργήσετε έναν ιστότοπο, κάνετε συμβιβασμό όσον αφορά την αρχική φόρτωση του έργου και την προετοιμασία του. Αυτό ισχύει ακόμη και για τα πιο θετικά σενάρια.
Είναι απολύτως δυνατό να κάνετε κάποιους συμβιβασμούς σε κατάλληλες καταστάσεις, αλλά είναι σημαντικό οι προγραμματιστές να κάνουν τέτοιους συμβιβασμούς συνειδητά.
Έχουμε όμως και λόγους αισιοδοξίας. Είμαι ενθουσιασμένος που βλέπω πόσο στενά συνεργάζονται οι προγραμματιστές του Chrome με τους προγραμματιστές ορισμένων από τα εργαλεία διεπαφής που έχουμε εξετάσει σε μια προσπάθεια να βοηθήσουμε στη βελτίωση της απόδοσης αυτών των εργαλείων.
Ωστόσο, είμαι πραγματιστής άνθρωπος. Οι νέες αρχιτεκτονικές δημιουργούν προβλήματα απόδοσης όσο συχνά τα λύνουν. Και χρειάζεται χρόνος για να διορθωθούν σφάλματα. Όπως ακριβώς δεν πρέπει να περιμένουμε θα λύσει όλα τα προβλήματα απόδοσης, δεν πρέπει να το περιμένετε από τις νέες εκδόσεις των αγαπημένων μας πλαισίων.
Εάν θέλετε να χρησιμοποιήσετε ένα από τα εργαλεία διεπαφής που συζητούνται σε αυτό το άρθρο, αυτό σημαίνει ότι θα πρέπει να καταβάλετε επιπλέον προσπάθεια για να μην βλάψετε την απόδοση του έργου σας στο μεταξύ. Ακολουθούν ορισμένα στοιχεία που πρέπει να λάβετε υπόψη πριν ξεκινήσετε ένα νέο πλαίσιο:
- Δοκιμάστε τον εαυτό σας με την κοινή λογική. Χρειάζεται πραγματικά να χρησιμοποιήσετε το επιλεγμένο πλαίσιο; Η καθαρή JavaScript σήμερα είναι ικανή για πολλά.
- Υπάρχει μια πιο ελαφριά εναλλακτική από το επιλεγμένο πλαίσιο (όπως το Preact, το Svelte ή κάτι άλλο) που μπορεί να σας δώσει το 90% των δυνατοτήτων αυτού του πλαισίου;
- Εάν χρησιμοποιείτε ήδη ένα πλαίσιο, σκεφτείτε εάν υπάρχει κάτι που προσφέρει καλύτερες, πιο συντηρητικές, τυπικές επιλογές (π.χ. Nuxt.js αντί για Vue, Next.js αντί για React κ.λπ.).
- Τι θα σου Απόδοση JavaScript;
- Πως μπορείς μια διαδικασία ανάπτυξης για να είναι πιο δύσκολη η εισαγωγή περισσότερου κώδικα JavaScript σε ένα έργο από ό,τι είναι απολύτως απαραίτητο;
- Εάν χρησιμοποιείτε ένα πλαίσιο για ευκολία ανάπτυξης, σκεφτείτε αποστολή κώδικα πλαισίου στους πελάτες. Ίσως μπορείτε να λύσετε όλα τα προβλήματα στον διακομιστή;
Συνήθως αυτές οι ιδέες αξίζει να τις εξετάσετε, ανεξάρτητα από το τι ακριβώς έχετε επιλέξει για την ανάπτυξη του front-end. Αλλά είναι ιδιαίτερα σημαντικά όταν εργάζεστε σε ένα έργο που στερείται απόδοσης από την αρχή.
Αγαπητοί αναγνώστες! Πώς βλέπετε το ιδανικό πλαίσιο JavaScript;
Πηγή: www.habr.com