Rozumiem, że mniejsza ilość pobieranych danych poprawia komfort użytkownika końcowego, ale moje pytanie dotyczy rzeczywistej wydajności serwera, czy odpowiedź byłaby szybsza?

Czy dodałbym _fields[]=id&_pola[]=title itp. do powyższego adresu URL poprawić wydajność serwera?

Nie, nie byłoby, i z kilku powodów.

Kiedy prosisz o post, pobiera cały wiersz postu z bazy danych, a także pobiera wszelkie meta posty i terminy, dzięki czemu są one pobierane zbiorczo na raz, a nie mnóstwem nieefektywnych mniejszych zapytań. Przyspiesza to kolejne zapytania, które proszą o posty, nawet jeśli nie korzystają z tych samych pól, a nawet może z wyprzedzeniem przygotować pamięć podręczną na przyszłe żądania.

Jeśli więc poprosisz o tylko podzbiór tych pól, nie oszczędzasz czasu ani pamięci bazy danych, a jedynie dodajesz niewielką ilość przetwarzania, aby przefiltrować je tylko do żądanych części.

Co więcej, prosisz o jedyną w swoim rodzaju odpowiedź dostosowaną specjalnie do Ciebie. Oznacza to, że nie możemy łatwo zapisać wyniku w pamięci podręcznej i użyć go ponownie setki lub tysiące razy. W rezultacie można znacznie zmniejszyć naszą skalowalność, a także potencjalne nowe zapytania w celu pobrania danych, które odfiltrowaliśmy, ponieważ są one teraz potrzebne po stronie klienta.

Po stronie serwera można uzyskać oszczędności w przepustowości, ale serwer będzie znajdował się w centrum danych z grubą rurą sieciową, więc ta zaleta jest znikoma w porównaniu z oszczędnościami procesora. Czasami można także zaoszczędzić czas programisty. Możesz zapłacić cenę za wydajność i skalowalność, aby zaoszczędzić czas podczas wpisywania kodu, korzystając z interfejsów API, takich jak GraphQL, które radykalnie upraszczają proces wysyłania zapytań o dane z punktu widzenia kodu.

Można podjąć kroki, aby temu zaradzić, na przykład upewniając się, że klient może żądać tylko niewielkiej liczby unikalnych zapytań, aby możliwe było buforowanie.

W przeciwnym razie istnieje bardzo realne ryzyko, że oszczędność czasu/prędkości w przypadku mniejszego transferu sieciowego do klienta zostanie zniwelowana w porównaniu z dodatkowym czasem potrzebnym serwerowi na wygenerowanie odpowiedzi. Przesyłanie większej odpowiedzi z pamięci podręcznej może zająć więcej czasu, ale przesyłanie może rozpocząć się natychmiast, a przeglądarka może ją przetworzyć podczas pobierania.

Istnieje również ryzyko, że będziesz musiał zadać dodatkowe zapytania, ponieważ potrzebujesz dodatkowych pól, o które nie prosiłeś w pierwszym żądaniu.

Wykonaj więc pomiary w rzeczywistych warunkach i porównaj. Jeśli rozmiar odpowiedzi jest duży i ma świat rzeczywisty wymierny wpływ na wydajność w Twoim przypadku użycia, który można poprawić poprzez uzyskanie mniejszych odpowiedzi, może to mieć sens.

Ale co, jeśli zbuduję niestandardowe punkty końcowe, które będą wykonywać zoptymalizowane wywołania bazy danych?

Nadal nie, nawet jeśli zakodujesz odpowiedź na stałe, tak aby nie odbywały się żadne zapytania do bazy danych, serwer nadal musi ładować WordPress. Nigdy nie może konkurować z dedykowaną pamięcią podręczną, taką jak Varnish, ani opcjami buforowania, które ładują się wcześniej i kończą, zanim WP będzie mógł w pełni się załadować, takimi jak Batcache.

Podobnie stracisz wszystkie zalety buforowania obiektów. Kiedy WP pobiera posty, terminy i meta, są one umieszczane WP_Cache aby nie były pobierane wielokrotnie w tym samym żądaniu. Jeśli dostępna jest pamięć podręczna obiektów, pamięć ta jest zachowywana podczas wielu żądań w pamięci głównej, co jeszcze bardziej przyspiesza. Witryna posiadająca taką pamięć podręczną może nie wykonywać żadnych wywołań do bazy danych, ponieważ dane zostały już pobrane.